Re: 5 June 2014 TC39 Meeting Notes
On 13 Jun 2014, at 18:15, Domenic Denicola dome...@domenicdenicola.com wrote: IMO it would be a good universe where `module` had the following things `script` has: - Does not require escaping' in any contexts. - 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.) But it removes the following things `script` has: - `!--` escaped data mode and double-escaped mode - \r, \r\n, \0 special-casing - 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). The majority of those are impossible without introducing different parse trees in old browsers (that do not recognize `module`) versus in new browsers. Different parse trees are a security risk. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
Le 12/06/2014 16:43, Domenic Denicola a écrit :
Also, David: modules are not named; you cannot import them. Check
out
https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md
Thanks, that's the context I was missing.
I'm uncomfortable with the async part of the proposal as currently
(under?)specified. Sharing my thought process.
Async loading prevents the rendering blocking problem, but creates
another problem.
async loading isn't an end in and of itself. As far as I'm concerned, I
never use script@async for app initialization code (which is the target
of the script type=module proposal) because it offers no guarantee
on whether the script will be executed before or after the HTML is fully
parsed.
I'm a big fan of script@defer though, because I have a clear idea of
loading order (which will be covered by modules, so unimportant for the
topic at hand) as well as when the script will be executed (when the
HTML is fully parsed and DOM is complete, but before the
DOMContentLoaded event)
I'm extremely interested in how other devs use the @async attribute in
practice. In the context of an application, scripts that have no
temporal dependency with other scripts loaded in the same document are
rare beasts.
Back to script type=module, I'm not sold on arbitrary async
loading if it forces me to add this boilerplate:
// assuming function loadApp(){}
if(document.readyState === loading)
document.addEventListener('DOMContentLoaded', loadApp)
else
loadApp();
A @defer semantics for script type=module might make more sense and
not force all devs to add the above boilerplate to make sure their code
loading is robust to the laws of physics.
If people want to execute scripts before the HTML is fully parsed they
can just use regular script.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Thu, Jun 12, 2014 at 11:11 AM, Domenic Denicola dome...@domenicdenicola.com wrote: I guess part of it is clarifying which part of script's insane parsing rules we're talking about. From what I'm aware of there are quite a lot of different insanities; but I am fuzzy on the details. Does anyone know which rules are inherently necessary, and which are historical accidents or constraints? I'll recap the rules for script data state from http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-state As a general rule, `\r` and `\r\n` are converted to `\n`, and `\0` is not allowed. The case-insensitive sequence `/script` followed by a character in `[ \t\r\n\f/]` terminates the script data section. (These constraints would be present for HTML-embedding.) In addition, the exact character sequence `!--` switches to escaped data parsing. This is a bit hairy, and you can even end up in double escaped modes. See http://stackoverflow.com/questions/23727025/script-double-escaped-state for an example. Presumably these are the insane parsing rules under discussion. You are encouraged to try to follow the logic in the WHATWG spec yourself. ;) In addition, [Web EcmaScript](http://javascript.spec.whatwg.org/) introduces two new single line comment forms: `!--` must be treated as if it were `//`, and `--` (with some crazy start-of-line restrictions) is also treated as a single line comment. To some degree the line between the HTML parser and Web EcmaScript is movable; currently the HTML parser recognizes the `!--` etc tokens but pushes them into the data section of the script tag anyway; one could just as easily imagine the HTML parser doing all the work and stripping the new comment forms from the token stream. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: 5 June 2014 TC39 Meeting Notes
Thanks Scott; much appreciated. IMO it would be a good universe where `module` had the following things `script` has: - Does not require escaping' in any contexts. - 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.) But it removes the following things `script` has: - `!--` escaped data mode and double-escaped mode - \r, \r\n, \0 special-casing - 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). 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. From: canan...@gmail.com canan...@gmail.com on behalf of C. Scott Ananian ecmascr...@cscott.net Sent: Friday, June 13, 2014 12:06 To: Domenic Denicola Cc: Mark S. Miller; es-discuss; Ben Newman Subject: Re: 5 June 2014 TC39 Meeting Notes On Thu, Jun 12, 2014 at 11:11 AM, Domenic Denicola dome...@domenicdenicola.com wrote: I guess part of it is clarifying which part of script's insane parsing rules we're talking about. From what I'm aware of there are quite a lot of different insanities; but I am fuzzy on the details. Does anyone know which rules are inherently necessary, and which are historical accidents or constraints? I'll recap the rules for script data state from http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-state As a general rule, `\r` and `\r\n` are converted to `\n`, and `\0` is not allowed. The case-insensitive sequence `/script` followed by a character in `[ \t\r\n\f/]` terminates the script data section. (These constraints would be present for HTML-embedding.) In addition, the exact character sequence `!--` switches to escaped data parsing. This is a bit hairy, and you can even end up in double escaped modes. See http://stackoverflow.com/questions/23727025/script-double-escaped-state for an example. Presumably these are the insane parsing rules under discussion. You are encouraged to try to follow the logic in the WHATWG spec yourself. ;) In addition, [Web EcmaScript](http://javascript.spec.whatwg.org/) introduces two new single line comment forms: `!--` must be treated as if it were `//`, and `--` (with some crazy start-of-line restrictions) is also treated as a single line comment. To some degree the line between the HTML parser and Web EcmaScript is movable; currently the HTML parser recognizes the `!--` etc tokens but pushes them into the data section of the script tag anyway; one could just as easily imagine the HTML parser doing all the work and stripping the new comment forms from the token stream. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 6:06 PM, C. Scott Ananian ecmascr...@cscott.net wrote: To some degree the line between the HTML parser and Web EcmaScript is movable; currently the HTML parser recognizes the `!--` etc tokens but pushes them into the data section of the script tag anyway; one could just as easily imagine the HTML parser doing all the work and stripping the new comment forms from the token stream. No, that would be bad for debuggers. ECMAScript just has to suck this up (I think a bug is already filed and pending a fix), just like CSS has. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 12:15 PM, Domenic Denicola dome...@domenicdenicola.com wrote: - Does not require escaping' in any contexts. `` will need to be escaped if it would otherwise start `/module`, of course. But I'm pretty sure you mean, does no character reference processing. - 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.) Anything other than strict `/module` is not going to fly. An argument in favor of keeping `/script` is that bundling tools and minifiers already know about avoiding `/script` -- using another tag name now means that a conservative tool needs to avoid another magic string. But it removes the following things `script` has: - `!--` escaped data mode and double-escaped mode Hear hear. - \r, \r\n, \0 special-casing Not going to happen, IMO. The HTML spec does linefeed conversion before any part of the tokenizer even sees the characters. And \0 is banned in HTML for good reasons. - 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). I've no strong opinion on this. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
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? On Fri, Jun 13, 2014 at 9:15 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Thanks Scott; much appreciated. IMO it would be a good universe where `module` had the following things `script` has: - Does not require escaping' in any contexts. - 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.) But it removes the following things `script` has: - `!--` escaped data mode and double-escaped mode - \r, \r\n, \0 special-casing - 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). 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. From: canan...@gmail.com canan...@gmail.com on behalf of C. Scott Ananian ecmascr...@cscott.net Sent: Friday, June 13, 2014 12:06 To: Domenic Denicola Cc: Mark S. Miller; es-discuss; Ben Newman Subject: Re: 5 June 2014 TC39 Meeting Notes On Thu, Jun 12, 2014 at 11:11 AM, Domenic Denicola dome...@domenicdenicola.com wrote: I guess part of it is clarifying which part of script's insane parsing rules we're talking about. From what I'm aware of there are quite a lot of different insanities; but I am fuzzy on the details. Does anyone know which rules are inherently necessary, and which are historical accidents or constraints? I'll recap the rules for script data state from http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-state As a general rule, `\r` and `\r\n` are converted to `\n`, and `\0` is not allowed. The case-insensitive sequence `/script` followed by a character in `[ \t\r\n\f/]` terminates the script data section. (These constraints would be present for HTML-embedding.) In addition, the exact character sequence `!--` switches to escaped data parsing. This is a bit hairy, and you can even end up in double escaped modes. See http://stackoverflow.com/questions/23727025/script-double-escaped-state for an example. Presumably these are the insane parsing rules under discussion. You are encouraged to try to follow the logic in the WHATWG spec yourself. ;) In addition, [Web EcmaScript](http://javascript.spec.whatwg.org/) introduces two new single line comment forms: `!--` must be treated as if it were `//`, and `--` (with some crazy start-of-line restrictions) is also treated as a single line comment. To some degree the line between the HTML parser and Web EcmaScript is movable; currently the HTML parser recognizes the `!--` etc tokens but pushes them into the data section of the script tag anyway; one could just as easily imagine the HTML parser doing all the work and stripping the new comment forms from the token stream. --scott -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 6:31 PM, Mark S. Miller erig...@google.com wrote: 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? Is that the constrain? (If it is, removing !--/-- weirdness would indeed be good.) I suspect in part this depends on where we allow module as well. If we make it generic like template and script, tablemodule/table would no longer have the element end up before the table element, but rather inside (and unclosed until EOF). -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 9:39 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 6:31 PM, Mark S. Miller erig...@google.com wrote: 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? Is that the constrain? (If it is, removing !--/-- weirdness would indeed be good.) I suspect in part this depends on where we allow module as well. If we make it generic like template and script, tablemodule/table would no longer have the element end up before the table element, but rather inside (and unclosed until EOF). Hi Anne, I didn't understand the answer. When an old browser that knows nothing of module specifically sees tablemodule/table, does it consider the module to be closed when it sees the /table ? This also raises the question: Does such an old browser consider the table to be closed by this occurrence of /table? -- http://annevankesteren.nl/ -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller erig...@google.com wrote: Hi Anne, I didn't understand the answer. When an old browser that knows nothing of module specifically sees tablemodule/table, does it consider the module to be closed when it sees the /table ? This also raises the question: Does such an old browser consider the table to be closed by this occurrence of /table? Yes and yes. I recommend playing with http://software.hixie.ch/utilities/js/live-dom-viewer/ if you do not want to read the algorithm in the specification. The tree it generates might surprise you. Be sure to switch out module with script for differences ;-) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 12:53 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller erig...@google.com wrote: Hi Anne, I didn't understand the answer. When an old browser that knows nothing of module specifically sees tablemodule/table, does it consider the module to be closed when it sees the /table ? This also raises the question: Does such an old browser consider the table to be closed by this occurrence of /table? Yes and yes. I recommend playing with http://software.hixie.ch/utilities/js/live-dom-viewer/ if you do not want to read the algorithm in the specification. The tree it generates might surprise you. Be sure to switch out module with script for differences ;-) To be clear, you're referring to the automatic placement of module as a descendant of BODY even if it's explicitly written inside head/head (but not for script)? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 6:57 PM, Rick Waldron waldron.r...@gmail.com wrote: To be clear, you're referring to the automatic placement of module as a descendant of BODY even if it's explicitly written inside head/head (but not for script)? That is a similar effect. My example was about it becoming a previous sibling rather than a child. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
Thanks, and thanks to Hixie for that playground. I can't see us adopting parsing rules for a new tag that results in different structure for the rest of the page on old vs new browsers. Otherwise we just invite a whole new category of injection attacks. On Fri, Jun 13, 2014 at 9:53 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller erig...@google.com wrote: Hi Anne, I didn't understand the answer. When an old browser that knows nothing of module specifically sees tablemodule/table, does it consider the module to be closed when it sees the /table ? This also raises the question: Does such an old browser consider the table to be closed by this occurrence of /table? Yes and yes. I recommend playing with http://software.hixie.ch/utilities/js/live-dom-viewer/ if you do not want to read the algorithm in the specification. The tree it generates might surprise you. Be sure to switch out module with script for differences ;-) -- http://annevankesteren.nl/ -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Fri, Jun 13, 2014 at 12:57 PM, Rick Waldron waldron.r...@gmail.com wrote: On Fri, Jun 13, 2014 at 12:53 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller erig...@google.com wrote: Hi Anne, I didn't understand the answer. When an old browser that knows nothing of module specifically sees tablemodule/table, does it consider the module to be closed when it sees the /table ? This also raises the question: Does such an old browser consider the table to be closed by this occurrence of /table? Yes and yes. I recommend playing with http://software.hixie.ch/utilities/js/live-dom-viewer/ if you do not want to read the algorithm in the specification. The tree it generates might surprise you. Be sure to switch out module with script for differences ;-) To be clear, you're referring to the automatic placement of module as a descendant of BODY even if it's explicitly written inside head/head (but not for script)? There are a number of interesting effects. 1) Only certain tags can live inside `head`; the other tags are automatically moved into `body`. So: `htmlheadscript/script/head/html` but: `htmlheadmodule/module/head/html` gets parsed as `htmlhead/headbodymodule/module/html`. 2) Only certain tags can live inside `table`; other tags are foster parented above the `table`. So: `htmlbodytablescript/script` but: `htmlbodytablemodule/module` is parsed as `htmlbodymodule/moduletable` 3) Since `module` doesn't exist in the current HTML spec, old browsers will use the generic data state rules for parsing the body and finding the end tag. So: `htmlscriptconsole.log(amp;)` prints four characters, but `htmlmoduleconsole.log(amp;)` prints one character and `bascriptb/bc/scriptd` is parsed as `bascriptb/bc/scriptd/b` (that is, there is a literal /b in the script data), but: `bamoduleb/bc/moduled` is parsed as `bamoduleb/module/bcd` There are more, but these are the main effects of using an generic tag name. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
Le 11/06/2014 18:21, Ben Newman a écrit :
## 7.1 script type=module status update (from DH)
DH: Would really rather have moduleimport { foo } from bar;
.../module, which is like script but async, strict mode, has its
own top-level scope, and can import declaratively (using ES6 module
import syntax) from other (named) modules.
Just to be sure I understand, with module (or script type=module),
the module has to be named? So module never really makes sense on its
own and should always have a name attribute?
DH: module name=qux creates race conditions with HTML imports
(part of WebComponents).
YK: People who saw named HTML module tags though you should mix html
imports w named module imports
YK: When you have packaging solution (SPDY, etc), you no longer need
named modules
+1
MM: script type=module would inherit the special termination rules
of /script, whereas old browsers might not handle module the same
way, since that tag name doesn't mean anything special in old browsers
AR: script type=module means the browser won't even try to parse
it as JS, which is what we want [so that we can execute the script
contents as a module, via some sort of polyfill]
DH: script type=worker might also need to have the script
type=module semantics, and type= attribute syntax makes it hard to
mix and match those attributes; maybe script worker module would be
better? (i.e. the type attribute values become optional value-less
attribute names)
DH: The difference between script type=module and module is that
as long as there's … you always have the option of writing
scriptSystem.import(main.js)/script
TODO: Get DH to clarify this point when we edit the notes.
cc'ing Dave Herman for this part.
AR: [note taker (BN) may be misinterpreting] The JS API remains
important even when we have HTML sugar.
Was this part edited after the misinterpretation or is it the original
note?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
I urge TC39 to assess the cost/benefit of module carefully. It brings in
a lot of issues orthogonal to JS. script is already a mess and HTML
Imports are barely a thing. Web developers need a solution to the bundling
problem for ES modules with much, much higher priority than module.
On Thu, Jun 12, 2014 at 2:22 AM, David Bruant bruan...@gmail.com wrote:
Le 11/06/2014 18:21, Ben Newman a écrit :
## 7.1 script type=module status update (from DH)
DH: Would really rather have moduleimport { foo } from bar;
.../module, which is like script but async, strict mode, has its own
top-level scope, and can import declaratively (using ES6 module import
syntax) from other (named) modules.
Just to be sure I understand, with module (or script type=module),
the module has to be named? So module never really makes sense on its own
and should always have a name attribute?
DH: module name=qux creates race conditions with HTML imports (part
of WebComponents).
YK: People who saw named HTML module tags though you should mix html
imports w named module imports
YK: When you have packaging solution (SPDY, etc), you no longer need
named modules
+1
MM: script type=module would inherit the special termination rules of
/script, whereas old browsers might not handle module the same way,
since that tag name doesn't mean anything special in old browsers
AR: script type=module means the browser won't even try to parse it
as JS, which is what we want [so that we can execute the script contents as
a module, via some sort of polyfill]
DH: script type=worker might also need to have the script
type=module semantics, and type= attribute syntax makes it hard to mix
and match those attributes; maybe script worker module would be better?
(i.e. the type attribute values become optional value-less attribute names)
DH: The difference between script type=module and module is that as
long as there's … you always have the option of writing
scriptSystem.import(main.js)/script
TODO: Get DH to clarify this point when we edit the notes.
cc'ing Dave Herman for this part.
AR: [note taker (BN) may be misinterpreting] The JS API remains important
even when we have HTML sugar.
Was this part edited after the misinterpretation or is it the original
note?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: 5 June 2014 TC39 Meeting Notes
I like module, simply as a better script. Whether it's worth the cost is
largely a matter of finding out what the cost is, from implementers. I don't
recall reading any opinions from them on the matter.
Hixie has brought up some interesting points on the interaction of module and
script in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868? which may have bearing.
Ideally module does not use script's insane parsing rules, but there is a
lot of complex stuff there that I don't think I fully grasp.
Also, David: modules are not named; you cannot import them. Check out
https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md
From: es-discuss es-discuss-boun...@mozilla.org on behalf of John Barton
johnjbar...@google.com
Sent: Thursday, June 12, 2014 10:02
To: David Bruant
Cc: Ben Newman; es-discuss
Subject: Re: 5 June 2014 TC39 Meeting Notes
I urge TC39 to assess the cost/benefit of module carefully. It brings in a
lot of issues orthogonal to JS. script is already a mess and HTML Imports are
barely a thing. Web developers need a solution to the bundling problem for ES
modules with much, much higher priority than module.
On Thu, Jun 12, 2014 at 2:22 AM, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 11/06/2014 18:21, Ben Newman a écrit :
## 7.1 script type=module status update (from DH)
DH: Would really rather have moduleimport { foo } from bar; .../module,
which is like script but async, strict mode, has its own top-level scope, and
can import declaratively (using ES6 module import syntax) from other (named)
modules.
Just to be sure I understand, with module (or script type=module), the
module has to be named? So module never really makes sense on its own and
should always have a name attribute?
DH: module name=qux creates race conditions with HTML imports (part of
WebComponents).
YK: People who saw named HTML module tags though you should mix html imports w
named module imports
YK: When you have packaging solution (SPDY, etc), you no longer need named
modules
+1
MM: script type=module would inherit the special termination rules of
/script, whereas old browsers might not handle module the same way, since
that tag name doesn't mean anything special in old browsers
AR: script type=module means the browser won't even try to parse it as JS,
which is what we want [so that we can execute the script contents as a module,
via some sort of polyfill]
DH: script type=worker might also need to have the script type=module
semantics, and type= attribute syntax makes it hard to mix and match those
attributes; maybe script worker module would be better? (i.e. the type
attribute values become optional value-less attribute names)
DH: The difference between script type=module and module is that as long
as there's ... you always have the option of writing
scriptSystem.import(main.js)/script
TODO: Get DH to clarify this point when we edit the notes.
cc'ing Dave Herman for this part.
AR: [note taker (BN) may be misinterpreting] The JS API remains important even
when we have HTML sugar.
Was this part edited after the misinterpretation or is it the original note?
David
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola dome...@domenicdenicola.com wrote: I like module, simply as a better script. Whether it's worth the cost is largely a matter of finding out what the cost is, from implementers. I don't recall reading any opinions from them on the matter. Hixie has brought up some interesting points on the interaction of module and script in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868 which may have bearing. Ideally module does not use script's insane parsing rules, but there is a lot of complex stuff there that I don't think I fully grasp. But a module embedded in html needs script's insane parsing rules. That's why module doesn't work and we need script type=module instead. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: 5 June 2014 TC39 Meeting Notes
But a module embedded in html needs script's insane parsing rules. That's why module doesn't work and we need script type=module instead. This isn't immediately clear to me; would you mind explaining? I guess part of it is clarifying which part of script's insane parsing rules we're talking about. From what I'm aware of there are quite a lot of different insanities; but I am fuzzy on the details. Does anyone know which rules are inherently necessary, and which are historical accidents or constraints? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I like module, simply as a better script. Whether it's worth the
cost is largely a matter of finding out what the cost is, from
implementers. I don't recall reading any opinions from them on the matter.
Hixie has brought up some interesting points on the interaction of
module and script in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868 which may have
bearing. Ideally module does not use script's insane parsing rules, but
there is a lot of complex stuff there that I don't think I fully grasp.
So you are saying that you want something better, something less complex
that you can fully grasp. In my opinion, that option already exists:
scriptSystem.import('moduleName').then(more-code);/script. A module
tag won't have those properties for the same reasons script is insane now.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
