Allow literal html tags to stand for themselves
Categories
(bugzilla.mozilla.org :: User Interface, enhancement)
Tracking
()
People
(Reporter: dylan, Assigned: dylan)
References
Details
Attachments
(1 file)
Split off from the discussion on Bug 1518304.
Right now, all html tags are considered "invalid" and thus omitted from the output. If we wish to have 100% GitHub compatibility, we would allow tags like \<b> and \<img>.
For other tags -- including bits of text that are not tags, such as \<example argument> the behavior on GitHub would be to display nothing.
Here we could diverge, and say that unknown tags stand for themselves.
|
Assignee | |
Comment 1•6 years ago
|
||
Based on feedback, I'm inclined to believe we should diverge. But this bug is filed so conversation can still be had.
I think we should heed GitHub's decisions here, since they are driven by several years of markdown based comments on their products.
\<img> is an exposure, \<b> much less so but people do understand how to *embolden* text.
Can we automatically escape markup? So that we can display pasted HTML as markup (which would be the intended use case almost all the time, or at least the use case most relevant to a bug tracker for a web browser)?
|
|
Assignee | |
Comment 3•6 years ago
|
||
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #2)
I think we should heed GitHub's decisions here, since they are driven by
several years of markdown based comments on their products.
<img> is an exposure, <b> much less so but people do understand how to
embolden text.
Can we automatically escape markup? So that we can display pasted HTML as
markup (which would be the intended use case almost all the time, or at
least the use case most relevant to a bug tracker for a web browser)?
GitHub renders markdown to HTML, and then applies an HTML whitelist filter to that result.
All unknown tags are removed from the output. We can do the same easily, with something like the following:
$dom->find(':not($safe_tags)')->map('remove');
To do more than removing them:
$dom->find(':not($safe_tags)')->map(sub { $_->replace(html_escape($_->to_string)) });
The problem with the later approach that simple tags like \<foo> will get a closing partner, becoming \<foo>\</foo>
That doesn't sound like the use case I'm thinking of where a person reports a bug and includes a block of markup in the description.
We don't want to render that markup, just display it.
|
|
Assignee | |
Comment 5•6 years ago
|
||
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #4)
That doesn't sound like the use case I'm thinking of where a person reports
a bug and includes a block of markup in the description.
We don't want to render that markup, just display it.
That is what option #2 does, but because of limitations of the DOM we don't know if they wrote \<foo> or \<foo>\</foo>.
|
|
Assignee | |
Comment 6•6 years ago
|
||
<form>
<label>snorp <input type="button" value="1"></label>
</form>
|
|
Assignee | |
Comment 7•6 years ago
|
||
|
|
Assignee | |
Updated•6 years ago
|
|
||
Comment 8•6 years ago
|
||
(In reply to Dylan Hardison [:dylan] (he/him) from comment #5)
That is what option #2 does, but because of limitations of the DOM we don't know if they wrote \<foo> or \<foo>\</foo>.
In a bug comment about a browser mis-rendering HTML transformations like that could hide the bug in question. Would it be feasible to auto-escape angle brackets on submission if they're not in a backtick-quoted code section? That is, any < becomes \< (and any \< has to become \\\<). Or is it better to just let people edit their comments now when they come out wrong?
Is there a way to see the "source" of a comment? That way if a new person shows up to report a browser bug and there are obvious "stripped-HTML" shaped holes in their description we'd have a fighting chance of figuring it out. Kind of the inverse of the "Preview" button when creating a comment.
|
|
Assignee | |
Comment 9•6 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #8)
(In reply to Dylan Hardison [:dylan] (he/him) from comment #5)
That is what option #2 does, but because of limitations of the DOM we don't
know if they wrote <foo> or <foo></foo>.In a bug comment about a browser mis-rendering HTML transformations like
that could hide the bug in question. Would it be feasible to auto-escape
angle brackets on submission if they're not in a backtick-quoted code
section? That is, any < becomes \< (and any \< has to become \\<). Or is it
better to just let people edit their comments now when they come out wrong?
Is there a way to see the "source" of a comment? That way if a new person
shows up to report a browser bug and there are obvious "stripped-HTML"
shaped holes in their description we'd have a fighting chance of figuring it
out. Kind of the inverse of the "Preview" button when creating a comment.
It's moot now, as soon as the current code is deployed html will be shown literally. Which means we're incompatible with github but we can iterate on that.
Description
•