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
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
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
.
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
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
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.
-
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 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
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
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
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
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
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
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
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
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
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
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.
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
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.
20 matches
Mail list logo