HTML-like comment behavior inconsistent
Annex B documents and standardizes legacy browser behavior - the way it's specified is the way browsers already do it, so the "consistent" behavior you're talking about would conflict with the way existing code already works.
the HTML comments were used as a hack to hide the code from browsers that didn't understood the <script> element. It is not meant to commenting JavaScript code. For example,
<script>
<!--
foo = bar;
baz();
-->
</script>
browsers that didn't support <script> treat its content as an HTML comment, and browsers that do support it ignore the <!-- and --> lines, but certainly not the lines inbetween.
Thanks, Claude.
It may be tempting to assume the standard specified something dumb, or due to "legacy" mysteries. Not so. HTML5 fully specifies <script>, which I created in 1995 at Netscape. I had no time for the src= attribute, and even if I had (I implemented that in 1996 for Netscape 3), but basis case was code directly in the HTML page, as I noted on Twitter: twitter.com/BrendanEich/status/683344089308200960.
kdex, think about how < is interpreted within an inline <script> -- it is
not escaped via < nor can or should it be. Likewise, HTML comments don't
work as such in script content. The script element's content model, which I
borrowed from SGML in a hurry in late spring '95, is called CDATA. For ease
of use, I chose not to require the <![CDATA[ and ]]> marked section
delimiters from SGML (this was controversial back then! SGML and later XML
people actually were angry with me over this design decision).
Netscape's HTML parser of the time (Netscape 1 and 1.1, predating JS in
Netscape 2; same as in Mosaic) already supported <!-- and --> as HTML
comment delimiters, without fully parsing SGML comments in all their glory
(see www.flightlab.com/~joe/sgml/comments.html).
Thus, to help early JS adopters hide inline script content from old (non-JS-supporting) browsers, my "two-way comment-hiding hack" was born in Netscape 2. I did require something like this:
//-->
as the last line of the script content, not wanting to make --> yet another
comment-till-end-of-line special case. However, IE implemented support for
just --> (no // in front to hide the otherwise-invalid JS syntax) at some
point while cloning JS prior to ECMA-262 Edition 1. The Ecma TC39 group
only got around to specifying all of this in ES6 Annex B.
Often enough, things are the way they are for good reasons. See "Chesterton's Fence".
Apologies for formatting problems -- I blame the Google Inbox web app.
One typo fix, hope it's obvious already:
On Sat, Jan 2, 2016 at 2:28 PM Brendan Eich <brendan.eich at gmail.com> wrote:
Thanks, Claude.
It may be tempting to assume the standard specified something dumb, or due to "legacy" mysteries. Not so. HTML5 fully specifies <script>, which I created in 1995 at Netscape. I had no time for the src= attribute, and even if I had (I implemented that in 1996 for Netscape 3), but basis
"the basis"
case was code directly in the HTML page, as I noted on twitter: twitter.com/BrendanEich/status/683344089308200960.
This reminds me to add something in re: Herby's reply on that "javaing" thread (esdiscuss.org/topic/small-request-javascript-for-javaing) which has finally died a deserved death:
JS should remain short for JavaScript, the common name whose (possibly untenable) trademark Oracle may yet donate to Ecma. This is because you cannot take Java out of the origin story and explain things like primitives and their auto-boxing wrapper objects. I laid it all out on twitter just yesterday:
twitter.com/BrendanEich/status/683009424940662784
Trademark leverage by marketing implied technical roadmap contents including LiveConnect, the JS/Java bridge, which required primitives and objects (value and reference types).
JS is not derived from Java (both have C as a grandfather), but it had some lateral gene transfer. Hmm, kind of like a trademark-leveraged superhero origin with gamma-irradiated blood transfusion among cousins. You might say that JS is She-Hulk to Java's Hulk ( en.wikipedia.org/wiki/She-Hulk#Publication_history). Or not! ;-)
ES2015's annex section B.1.3 (HTML-like Comments) currently defines
Commentin a way that makesa comment, and likewise for
undefined --> everything after the first occurrence of "-->" in this line.However, the tokens
<!--and-->are inherently used as block commentsin HTML, whereas EcmaScript doesn't allow them to span over multiple lines. As a consequence,
would result in a syntax error.
Is this a deliberate choice? Are there reasons for or against matching HTML's behavior in ES2016?
Personally, I don't use these tokens anyway, but this seems like an obvious inconsistency to me.