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.
# June 5 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben
21 matches
Mail list logo
