[Task]: Support markup.

[RokeJulianLockhart]

Description

I want (ideally CommonMark, or at least HTML5) markup to render in reviews and add-on descriptions. An example of when fenced code blocks would have been useful to me is noting issues with code to the developer, and an example of when inline code would have been useful is semantically referring to a subdomain in RegEx form.

Of course, italics are also necessary when highlighting something in a paragraph.

Acceptance Criteria

  ### Milestones/checkpoints
  1. [ ] Render markup in the frontend.
  1. [ ] Sanitise outputs to prevent `iframe`s (etc) being rendered. I can't imagine that disallowing them being entered is necessary, because it might be useful to the user when duplicating reviews across multiple locations without modifications for each location.

Checks

• [X] If I have identified that the work is specific to a repository, I have removed "repository:addons-server" or "repository:addons-frontend"

┆Issue is synchronized with this Jira Task

[RokeJulianLockhart]

https://github.com/mozilla/addons/issues/15129#issue-2627166301

I reported this at https://github.com/mozilla/addons/issues/new/choose because https://bugzilla.mozilla.org/show_bug.cgi?id=1256293#c3:~:text=2016%2D03%2D14%2014:19%20UTC-,New%20issues%20should%20be%20filed%20at%20https://github.com/mozilla/addons%2Dserver/issues,-If%20you%20have instructs to me to report it at https://github.com/mozilla/addons-server, which instructs me to report it here.

If I have identified that the work is specific to a repository, I have removed "repository:addons-server" or "repository:addons-frontend"

I am unable to remove https://github.com/mozilla/addons/labels/repository%3Aaddons-server.

[abyrne-moz]

Thank you for your suggestion! I agree that markup would be valuable to support on our add-ons listing pages. I have created a new issue for the team to capture these requirements in more detail.

Add-on ratings are designed for users rate the quality of the extension, and provide some words to explain why they chose that rating. It is not designed for bug reports, and we encourage developers to link to a separate external support site for that.

Providing markup support in the ratings increases the risk that these fields become used for spam or other nefarious reasons.

[RokeJulianLockhart]

Thank you for your suggestion! I agree that markup would be valuable to support on our add-ons listing pages. I have created a https://github.com/mozilla/addons/issues/15145 for the team to capture these requirements in more detail.

@abyrne-moz, thanks, lots! I'm always glad to see an issue broken into smaller, trackable issues.

Providing markup support in the ratings increases the risk that these fields become used for spam or other nefarious reasons.

The input form is labelled as a review form. Additionally, it appears to accept an unlimited amount of text. These are both significant benefits, because it means that users can provide higher quality reviews. However, without basic italicisation and table support, it can become tedious to write them.

Would not a subset of the already fairly restrictive CommonMark be acceptable? Currently, tables, italicisations, bolding, and hyperlink URIs are rendered in plain text from. They can remain so with users familiar with Markdown markup understanding them, but to regular users, it must appear strange – especially URIs being unsanitised yet not encapsulated within a hyperlink.

If what you state about your team's intention for the review field is true, then I suggest that you limit its length to a word count and relabel the form to "comment" (or similar), else it shall continue to be used for full reviews, rather than mere comments. However, it would be a significant shame.

[abyrne-moz]

Thank you, I appreciate the feedback. We aim to strike the right balance between enabling add-on users to provide detailed reviews that will be useful for others to decide if they should install the add-on, whilst not encouraging it to be used as a support forum or feature request platform so choosing a character limit will be difficult. Additionally, if we render HTML in the reviews, especially URLs, we quickly see the review system get targeted by SEO spammers attempting to manipulate search rankings.

[RokeJulianLockhart]

https://github.com/mozilla/addons/issues/15129#issuecomment-2459809162

@abyrne-moz, how about the most basic CommonMark markup, like italicised and bold text, then?

Otherwise, I do understand what you currently do - allowing URIs but not encapsulating them in <a href=""> tags, considering that an SEO crawler shall probably not bother to parse the plaintext of the page to extract the links if they're not semantic.

[abyrne-moz]

In your opinion, what value would allowing Bold and Italicised text bring to the ratings for end users making a decision about whether or not to install the add-on?

[RokeJulianLockhart]

https://github.com/mozilla/addons/issues/15129#issuecomment-2460162405

@abyrne-moz, it doesn't serve a particularly different purpose in this context to most else. Specifically, in some sentences, a section may be of importance in comparison to its surrounding clause. To demonstrate that, a user currently either CAPITALISES it or uses plain-text Markdown syntax (* or **) in lieu of a rendering engine. For the result instead to be semantic, having those basic formatting aids be supported would be useful for screen readers and non-technical readers alike.

[abyrne-moz]

I've consulted with our product designers on this, and researched some other popular ratings platforms to see if they support formatting. We have come to the same conclusion, that the addition of markdown style formatting support would bring a low return on the engineering investment. At this moment we won't be including this functionality on AMO in the ratings area. Thanks again for suggesting it though, I really do appreciate it!