-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
html/template: SGML processing Instructions escaped #30168
Comments
I note that html/template does not import the encoding/xml package https://godoc.org/html/template?imports because html5 is not xml. |
Note that XML is not mentioned in my bug report. According to
|
https://en.m.wikipedia.org/wiki/Standard_Generalized_Markup_Language
HTML5 is not SGML either. |
HTML 5 isn't mentioned in the I think it is safe to say that most browser implementations support SGML processing instructions, even if they don't use them. And since most browsers/parsers (except Go's) ignore them, they can be really useful. |
/cc @mikesamuel for owners input |
Per HTML5 rules, After seeing
which then appends content to the first So HTML 5 may support PIs but using node type 8 (comment) not 7 (processing instruction). This can be seen by running: let div = document.createElement('div');
div.innerHTML = '<?PI PI?>';
div.firstChild.nodeType === Node.COMMENT_NODE
// -> true In contrast to the XML grammar, in HTML, Other constructs also enter the bogus comment state: It seems there are a few options: Do nothingMentioned merely for completeness. Recognize
|
Fyi, html/template uses its own hand-written parser that does not assume that a template is a complete document fragment. Open and close tags need not appear in the same template:
And a template may not be in the same language as its caller:
|
@mikesamuel Yes, sorry, that was indeed my point. |
Please don't do that. Filtering out comments was probably also a bad idea originally, but I'm not going down that road. In contrast to comments, which I guess is mostly used to inform/remind people about a certain implementation detail, processing instructions have meanings to computers -- removing them would be a breaking thing.
If |
If you want html/template to preserve things that look kind of like processing instructions, please make the case that that is worthwhile. This talk about processing instructions in HTML seems to be appealing to a standard that does not exist (see below). You seem to be suggesting that using comments that look like PIs is a widespread practice; I have not encountered that in my work, which is why I asked for use cases. Please convince me that this is something developers need. I will need to see some numbers though. If you do want
If you want to demonstrate this, please compare the cost of leaks due to developer comments unintentionally persisting in code to the cost of having to do something like the playground above for the few times you actually need a comment. To the best of my knowledge, the only repeatedly occurring use case for shipping comments in code is MS conditional compilation comments which were deprecated in 2015. """ I know of no use case for shipping comments to modern browsers that is not met by the playground above. Again, please convince me otherwise.
The documentation could be more specific, but I'm not just saying processing instructions are not part of HTML 5. I refer to HTML 5 because that's what modern browsers approximate. To my knowledge no version of HTML has ever supported processing instructions. HTML 4 B3.3 SGML features with limited support says """ B.3.3 SGML features with limited supportSGML systems conforming to [ISO8879] are expected to recognize a number of features that aren't widely supported by HTML user agents. We recommend that authors avoid using all of these features. ... B.3.6 Processing Instructions... Authors should be aware that many user agents render processing instructions as part of the document's text. Browsers do not and have not recognized processing instructions in HTML. What changed between HTML 4 and HTML 5 was how they chose not to parse processing instructions as |
The So: I want the I will leave this thread now. Do as you please, but please consider my concerns above. |
I think you need to look at Go's |
Great. I look forward to seeing them.
How is Go's HTML handling relevant to what the HTML standard is? |
Is it valid to use My understanding is that this type of processing instruction is also sometimes used in HTML. e.g. |
Go version
go1.12beta2
.The above prints
<?PITarget PIContent?>
.I would expect it to be left untouched, e.g.
<?PITarget PIContent?>
.https://en.wikipedia.org/wiki/Processing_Instruction
The text was updated successfully, but these errors were encountered: