Add-on summary

FWIW this is used in the main card on an add-on detail page, and I think it makes sense to have a "raw" string there, otherwise that might change how detail pages look.

Also, what markup are we talking about? We do support some html tags in some other fields but "straight HTML tags should no longer be allowed in any add-on fields" makes me think that we're more thinking about markdown than markup? Or is this a new thing?

Also, what markup are we talking about? We do support some html tags in some other fields but "straight HTML tags should no longer be allowed in any add-on fields" makes me think that we're more thinking about markdown than markup? Or is this a new thing?

@willdurand, Markdown support more frequently than not includes support for a significant subset of HTML5. That is part of its popularity – it is in most situations to HTML as YAML is to JSON.

Consequently, I would say that there is no need to prevent an author using basic HTML5 tags, like <i>, <s>, or <b>. It may be useful when duplicating markup between the extension page to a webpage, as is common for extensions listed in multiple places.

I definitely meant mark_down,_ not mark_up_. I'll edit the ticket.

Notes:

• html to markdown compatibility
• how do we do validation on markdown, is it different to how we do it currently

@abyrne-moz When you say 'summary', do you mean the add-on description? The fields that expect HTML on the Addon model are: description, developer_comments, eula, and privacy_policy. Summary is not included (though, FE still allows HTML included in the summary to render).

Should eula be excluded as well?

Excellent spot, it should be the Description, not the Summary - my mistake! the eula should be in scope for markdown as well, as it currently supports HTML.

I'll update the description with the correct field too.