4 ms·
Ugh, their response: This is an intentional change. Prior to the HTML5 parsing algorithm, browsers backtracked and reparsed when seeing an EOF inside a script
by palish 16y ago
Ugh, their response:
This is an intentional change. Prior to the HTML5 parsing algorithm, browsers
backtracked and reparsed when seeing an EOF inside a script to deal with
</script> inside an inline script. This means that prior to HTML5, an
accidental or maliciously forced premature end of file could change the
executability properties of pieces of an HTML file.
The current magic in the spec was carefully designed and researched to permit
forward-only parsing in a maximally Web-compatible way. The solution in the
spec was known to break a handful of pages among lots and lots of pages listed
by dmoz, but the breakage was deemed negligible.
This is probably the highest-risk change in the HTML5 parsing algorithm, and
this is the first report of it breaking an "important" contemporary site.
Considering that keeping the forward-only tokenization behavior is highly
desirable, in the absence of evidence of more important breakage, I'm treating
this as an evang issue realizing that further evidence may force us to revisit
this part of the spec. But let's try to get away with forward-only parsing!
What is the logic behind this? Just because we want "forward-only parsing", we're going to try to force people not to write </script> inside of a Javascript string? That seems rather silly.
Are there any benefits to forward-only parsing besides speed? Because if this change was done in the name of performance, then we really should re-evaluate who exactly is proposing these types of changes and why.
- cameronh90 16y agoForward only parsing is not only faster, it's less complicated which should translate to fewer bugs. It's worth noting that the HTML parser isn't used only when initially rendering the page, it's also used when rewriting the contents with JavaScript. The bug report has a perfectly reasonable workaround you can use, and you can always put your JavaScript in a separate file or escape < >. It's a good idea to do this even with the current generation of browsers, because if you don't, you sometimes get strange bugs... often bugs that are not reproducible in all browsers. Honestly, allowing unescaped </script> inside inline javascript wasn't a good idea to begin with.
- judofyr 16y agobrowsers backtracked and reparsed when seeing an EOF inside a script to deal with </script> inside an inline script Correct me if I'm wrong, but it seems to me that in order to detect that the </script> is inside an inline script, you'll have to parse the JavaScript. Requiring every HTML5 parser to include a JavaScript parser in order to parse it correctly seems a little too much for me. Another reason: code complexity. Backtracking makes everything a lot more complex which is the exact opposite of what they're trying to achieve with the HTML5 parsing algorithm. Less code = fewer bugs, easier to understand and easier to implement.
- pornel 16y agoECMAScript has escape sequence just for this occasion: <\/script> Works everywhere (it's shame so few people know about it and use uglier and invalid "</sc"+"ript>").
- pbiggar 16y agoWhy is that invalid?
- pornel 16y agohttp://www.w3.org/TR/html4/types.html http://www.w3.org/TR/html4/types.html "The first occurrence of the character sequence "</" (end-tag open delimiter) is treated as terminating the end of the element's content." Of course browsers never implemented this correctly.