<div dir="ltr">Does there exist any string where an old browser using old rules would decide that a <module> is closed at one place, but a new browser following the rules you propose would decide that the <module> is closed at a different place?<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 9:15 AM, Domenic Denicola <span dir="ltr"><<a href="mailto:domenic@domenicdenicola.com" target="_blank">domenic@domenicdenicola.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Scott; much appreciated.<br>
<br>
IMO it would be a good universe where `<module>` had the following things `<script>` has:<br>
<br>
- Does not require escaping < > & ' " in any contexts.<br>
- Terminates when seeing `</module` + extra chars. (Possibly we could do this only when it would otherwise be a parsing error, to avoid `"</mod" + "ule>"` grossness? But that would require some intertwingling of the HTML and ES parsers, which I can imagine implementers disliking.)<br>

<br>
But it removes the following things `<script>` has:<br>
<br>
- `<!--` escaped data mode and double-escaped mode<br>
- \r, \r\n, \0 special-casing<br>
- The two new single-line comment forms (maybe; I know these work in Node though, so maybe just leave them in as part of the ES6 spec).<br>
<br>
Although I know some people think making `<script>` and `<module>` have different rules would be confusing for authors, IMO this would be a nice authoring experience.<br>
________________________________________<br>
From: <a href="mailto:cananian@gmail.com">cananian@gmail.com</a> <<a href="mailto:cananian@gmail.com">cananian@gmail.com</a>> on behalf of C. Scott Ananian <<a href="mailto:ecmascript@cscott.net">ecmascript@cscott.net</a>><br>

Sent: Friday, June 13, 2014 12:06<br>
To: Domenic Denicola<br>
Cc: Mark S. Miller; es-discuss; Ben Newman<br>
Subject: Re: 5 June 2014 TC39 Meeting Notes<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jun 12, 2014 at 11:11 AM, Domenic Denicola<br>
<<a href="mailto:domenic@domenicdenicola.com">domenic@domenicdenicola.com</a>> wrote:<br>
> I guess part of it is clarifying which part of "<script>'s insane parsing<br>
> rules" we're talking about. From what I'm aware of there are quite a lot of<br>
> different insanities; but I am fuzzy on the details. Does anyone know which<br>
> rules are inherently necessary, and which are historical accidents or<br>
> constraints?<br>
<br>
I'll recap the rules for "script data state" from<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-state" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-state</a><br>

<br>
As a general rule, `\r` and `\r\n` are converted to `\n`, and `\0` is<br>
not allowed.<br>
The case-insensitive sequence `</script` followed by a character in `[<br>
\t\r\n\f/>]` terminates the script data section.<br>
(These constraints would be present for HTML-embedding.)<br>
<br>
In addition, the exact character sequence `<!--` switches to "escaped<br>
data" parsing.  This is a bit hairy, and you can even end up in<br>
"double escaped" modes.  See<br>
<a href="http://stackoverflow.com/questions/23727025/script-double-escaped-state" target="_blank">http://stackoverflow.com/questions/23727025/script-double-escaped-state</a><br>
for an example.  Presumably these are the "insane parsing rules" under<br>
discussion.  You are encouraged to try to follow the logic in the<br>
WHATWG spec yourself. ;)<br>
<br>
In addition, [Web EcmaScript](<a href="http://javascript.spec.whatwg.org/" target="_blank">http://javascript.spec.whatwg.org/</a>)<br>
introduces two new single line comment forms: `<!--` must be treated<br>
as if it were `//`, and `-->` (with some crazy start-of-line<br>
restrictions) is also treated as a single line comment.<br>
<br>
To some degree the line between the HTML parser and Web EcmaScript is<br>
movable; currently the HTML parser recognizes the `<!--` etc tokens<br>
but pushes them into the data section of the script tag anyway; one<br>
could just as easily imagine the HTML parser doing all the work and<br>
stripping the "new comment forms" from the token stream.<br>
  --scott</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div></div>