5 June 2014 TC39 Meeting Notes

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

5 June 2014 TC39 Meeting Notes

Ben Newman
# 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 Newman (BN), Filip Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK), Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich (BE), Mark Miller (MM), Peter Jensen (PJ)


**quiet typing**

(Agenda item 5.2 added)

(Istvan on the phone discussing non-member CLA process)

AR: It sounds like we're making the process difficult for non-members simply because it's currently difficult for members. Can we change the goal to just make the process simpler for everyone?

IS: We just need the process to be the same for members and non-members. That is the current process -- we need the pdf form

AR: Can you take it back to the assembly(?) as a request from this TC that we'd like to simplify the process for signing the CLA to a click-through form for everyone [members and non-members]

IS: Yes, I can do that

**discussion**

## Conclusion/Resolution
- Allen will continue to work with Istvan on this
- Not clear how to proceed concretely other than having members continue to push for this
- Current process includes printing pdf, signing it, scanning it


## JSDoc*, JSIDL*, Code Editors

(Ask for slides)

SK: Type inferencing is hard

SK: JSDoc*, we need help from the user.

SK: Standardize JSDoc?

SK: JSDoc Proposal

AR: We are the only group that can add syntax so we should not put semantics in the comments.

AR: Interested in designing a type system

DH: I'm skeptic that we can design a type system for ES.

DH: Describes kinds of type systems: sound, unsound, guards

WH: I tried it for ES4. Came to the conclusion that a complex static type system would not work for ES's plethora of array-like things. On the other hand, more primitive type systems for things such as strings, numbers, classes are eminently doable and useful.

WH: I had a proposal for guards. These are more like a max min solution.

DH: Guards are too dynamic.

WH: In order for a type system to be useful, it must be enforceable in some form in order to catch erroneous or out-of-date type annotations.

DH: It is about as much a green field as defining a new language. It can mean so many different things.

JM: Would like to explore types for documentation at least.

DH: If there is no standard there will continue to be a proliferation of tools.

WH: We know this is a large space to explore. That does not mean that we should not explore it.

YK: If we make this a priority it will take years and years of discussion, dropping everything else.

BT: We can manage doing more than one thing at the same time.

AWB: This discussion feels like the early discussions of class syntax. Yet we were able to make progress.

DH: TypeScript is the strongest proposal at this point. Guards have serious problems for structural types. A sound type system (for JS) is still an academic research topic without a solution in sight.

YK: TS type system is incompatible with ES6.

YK: TS is a fork of ES5.

WH: These problems of incompatible forking are exactly why we need to take over this work.
f
AR: I want this for ES7

AWB: We haven't yet started to prioritize our next work items.

DH: The cost is very very high and IMO there are more important thing to work on than types.

WH: IMO documentable types are one of the highest priorities for us now. There is a lot of external interest as evidenced by the various external efforts.

BN: Strict scrutiny (e.g. from DH) can and should come before the proposal comes before TC39.

SK: Back to slides... Not proposing a type system. Implementors are interested in standardizing JSDoc..

SK: JS IDL?

SK: Type definition...

## Conclusion/Resolution

- Stage 0 to work on JSDoc

## Closing Iterators
(Dave presenting, send slides!)

Notes that key stakeholders have signed off on this (Andy Wingo, Luke Hoban, ... others)

**DH talking about breaking out of loops and calling .return() when an abrupt exit occurs in the loop**

WH: Does a yield inside a for loop call the return method in the normal case?

BN: No.

WH: What if that yield then gets killed by a break in the caller?

BN: Show example.

WH: 
    
```javascript
function * a() {
  for (let x of y) {
    ...
    yield ...
    ...
  }
}

for (let b of a()) {
    break;
}
```

** Discussing: How should abrupts inside a yield* get bubbled? **

BN: Any yield on which the generator (or any nested delegate generators) are currently suspended effectively become returns, so the return value "bubbles" all the way out to become the result of the outermost generator.

WH: (back to his code example) What does a's return method do?

MM: The break in the for loop calls the generator's return method -- causes the yield to return

DH: Any abrupt (but only abrupt completion) of a loop [calls .return() method?]

** continues through slides **
DH: Next issue: What if iterator, when given opportunity to stop, decides to keep going?
(see slides for details)

function* g() {
    yield;
}
g = g();
g.next();
g.return(42).value === 42;

WH: where does the 42 passed to g's return method go?
BN: It returns out of g with 42.
WH: Is there any way for g to get at the value 42?
DH: No.

Brendan's Example
```js
function* gen() { 
    try {
        yield 1;
    } finally {
        yield 2;
    }
}

for (let i of gen()) {
    break;
}

// The for-of loop unrolls to this:
var g = gen();
g.next(); // { value: 1, done: false }
g.return(42); // { value: 2, done: false }
// Not executed because of the break from the loop:
g.next(); // { value: undefined, done: true }
```

AWB: Important to remember that none of the costs (e.g. checking for a "return()" method) happen on "normal" completion of the loop -- only abrupt exits from the loop

DH: Let's talk bikeshedding: return() vs close()

BN: close() doesn't suggest that you can pass an argument

MM: .throw() is reflecting the throw construct within the generator, thus .return() makes sense

AWB: [strawman idea?] What about forbidding yield in try blocks?

RW: (silently, because I'm muted) Disagree with restricting use of `yield`

RW: Since we have an additional six months of "quality control" time with the spec, should we consider dealing with this directly as part of the "quality control" effort? Opposed to limitations on yield in try/catch/finally. 

AWB: that could be applied to any subject that comes up.

DH: forbidding yield in try blocks is a non-starter because there would then be no way to ever do any kind of cleanup on a yield using finally

BE: Python 2.5(?) added similar restrictions and then later relaxed them, which proves that there are use cases for yield in try-finally.

AWB: You'd have to structure your loop with an outer try-catch, yield takes away guarantee that finally would run

DH: Understand this is intended as temporary (i.e. to avoid adding complexity to generators last minute), but worst thing would be if we landed on this as a permanent semantic

DH: Agreement is that this is right semantics, there's a question as to whether we can get there in time

AWB: I worry about the precedent of adding changes like this now

BN: I will be happy to review the changes to chapter 25 (Generators and Promises) that are necessary to capture these changes.

AWB: Still worried because of the precedent this sets.

## Conclusion/Resolution

- Ratifying DH's proposal ("proposal" to be clarified), with the fallback (in case we run out of time, or decide to prioritize other work) of forbidding yield in try-finally blocks and making abrupt exits from for-of loops put the iterated-over generator into the GeneratorComplete state (which is a semantic change from leaving it in the GeneratorSuspendedYield state).


## Generator comprehensions (slides plz)


** Basically DH is proposing deferring comprehensions to ES7 with some minor changes to future-proof **

let a = for (x of a1) for (y of a2) if (y > x) {x,y};

WH: What type does this return?
?: It depends on the type of a1.
WH: Generating an array in the proposed world is ugly. If you want an array, you now need to convert the result of the comprehension to an array.

BE: The basis case doesn't work in the new design. To create a generator, you need to start with a generator. Awkward to write the first generator.

BE: problem is that a1 is evaluated eagerly rather than lazily

AWB: Where would we put Iterator.prototype in the Generator-related prototype object graph?
AWB: Hardest thing about this change is LAYING OUT THE DIAGRAM ALL OVER AGAIN: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorfunction-objects

BE: Inserting a new object without populating it with any methods invites breaking changes when we do populate it with methods like .flatMap.

JH: Really need to go with type-directed comprehensions (letting the iterable object determine the type of the comprehension) rather than the current syntax-directed syntax: (...) and [...].

WH: Worried that we'll rat-hole on the new proposal, which is pie-in-the-sky with a number of identified deficiencies. The current proposal is solid. The perfect is the enemy of the good here.

## Conclusion/Resolution

- Defer comprehensions from ES6 to ES7 to work on the more general type-directed, method-based approach to supporting comprehensions for arbitrary iterable types (arrays, generators, streams, parallel arrays, etc.).


## 7.1 <script type=module> status update (from DH)

DH: Would really rather have <module>import { 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.

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

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 <script>System.import("main.js")</script>
TODO: Get DH to clarify this point when we edit the notes.

MM: The <module> tag still has HTML misparsing consequences that <script> wouldn't have.

YK: The success of <template> proves that we can introduce a new <script>-like <module> tag.

DH: Need to create ways of doing this with pure JS, like <script>System.import("main.js")</script> and then add new HTML sugar later, like <script type="module">.

AR: [note taker (BN) may be misinterpreting] The JS API remains important even when we have HTML sugar.

## Conclusion/Resolution

- Adopt <script type="module"> and expect transitional code to do <script>System.import("main.js")</script>.


## 7.3 HTML Imports

BE: Recast as <script type="import"> rather than <link rel="import">?

## Conclusion/Resolution

- Consensus not reached.


## 7.2 Event loop

The issue is interleaving Promise response tasks with other tasks.

MM: Let's just not use the term "task" because it's confusing with other tasks (microtasks, etc).

Brainstorming names: job, tick (seems too close to process.nextTick), slice, turn, chore (lots of enthusiasm for chore!), quest (fits with realms!), schlep

## Conclusion/Resolution:

- Consensus not reached.



## Two or Three-day TC39 meetings in the future?

AR: Breakout sessions the third day?

EA: Can notes be taken in those breakout sessions?

MM: Breakout sessions for the rest of today?


## Modules breakout session:



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

David Bruant-5
Le 11/06/2014 18:21, Ben Newman a écrit :
> ## 7.1 <script type=module> status update (from DH)
>
> DH: Would really rather have <module>import { 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
> <script>System.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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

John Barton
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 <[hidden email]> 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 <module>import { 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 <script>System.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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: 6 June 2014 TC39 Meeting Notes

Jafar Husain
The slides included earlier in the thread are up-to-date. The link to the GitHub is for the Observable type that the syntax is expected to emit and consume.

J

Dictated using voice recognition. Please forgive the typos.

On Jun 12, 2014, at 10:02 AM, John Barton <[hidden email]> wrote:

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 <[hidden email]> 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 <module>import { 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 <script>System.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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: 5 June 2014 TC39 Meeting Notes

Domenic Denicola-2
In reply to this post by John Barton

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​ 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: <module>s are not named; you cannot import them. Check out https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md



From: es-discuss <[hidden email]> on behalf of John Barton <[hidden email]>
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 <[hidden email]> 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 <module>import { 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 <script>System.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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Mark S. Miller-2
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola <[hidden email]> 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​ 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: 5 June 2014 TC39 Meeting Notes

Domenic Denicola-2

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

John Barton
In reply to this post by Domenic Denicola-2



On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola <[hidden email]> 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​ 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: <script>System.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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

C. Scott Ananian
In reply to this post by Domenic Denicola-2
On Thu, Jun 12, 2014 at 11:11 AM, Domenic Denicola
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: 5 June 2014 TC39 Meeting Notes

Domenic Denicola-2
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: [hidden email] <[hidden email]> on behalf of C. Scott Ananian <[hidden email]>
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
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Anne van Kesteren
In reply to this post by C. Scott Ananian
On Fri, Jun 13, 2014 at 6:06 PM, C. Scott Ananian <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

C. Scott Ananian
In reply to this post by Domenic Denicola-2
On Fri, Jun 13, 2014 at 12:15 PM, Domenic Denicola
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Mark S. Miller-2
In reply to this post by Domenic Denicola-2
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 <[hidden email]> 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: [hidden email] <[hidden email]> on behalf of C. Scott Ananian <[hidden email]>
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
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Anne van Kesteren
On Fri, Jun 13, 2014 at 6:31 PM, Mark S. Miller <[hidden email]> 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>,
"<table><module></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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Mark S. Miller-2
On Fri, Jun 13, 2014 at 9:39 AM, Anne van Kesteren <[hidden email]> wrote:
On Fri, Jun 13, 2014 at 6:31 PM, Mark S. Miller <[hidden email]> 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>,
"<table><module></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 "<table><module></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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Anne van Kesteren
On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller <[hidden email]> wrote:
> Hi Anne, I didn't understand the answer. When an old browser that knows
> nothing of <module> specifically sees "<table><module></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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Rick Waldron



On Fri, Jun 13, 2014 at 12:53 PM, Anne van Kesteren <[hidden email]> wrote:
On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller <[hidden email]> wrote:
> Hi Anne, I didn't understand the answer. When an old browser that knows
> nothing of <module> specifically sees "<table><module></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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Anne van Kesteren
On Fri, Jun 13, 2014 at 6:57 PM, Rick Waldron <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

Mark S. Miller-2
In reply to this post by Anne van Kesteren
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 <[hidden email]> wrote:
On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller <[hidden email]> wrote:
> Hi Anne, I didn't understand the answer. When an old browser that knows
> nothing of <module> specifically sees "<table><module></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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 5 June 2014 TC39 Meeting Notes

C. Scott Ananian
In reply to this post by Rick Waldron
On Fri, Jun 13, 2014 at 12:57 PM, Rick Waldron <[hidden email]> wrote:

> On Fri, Jun 13, 2014 at 12:53 PM, Anne van Kesteren <[hidden email]>
> wrote:
>> On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller <[hidden email]>
>> wrote:
>> > Hi Anne, I didn't understand the answer. When an old browser that knows
>> > nothing of <module> specifically sees "<table><module></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:
   `<html><head><script></script></head></html>`
but:
  `<html><head><module></module></head></html>` gets parsed as
`<html><head></head><body><module></module></html>`.

2) Only certain tags can live inside `<table>`; other tags are "foster
parented" above the `<table>`.  So:
   `<html><body><table><script></script>`
but:
   `<html><body><table><module></module>` is parsed as
`<html><body><module></module><table>`

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:
   `<html><script>console.log("&amp;")` prints four characters, but
   `<html><module>console.log(&amp;")` prints one character
and
   `<b>a<script>b</b>c</script>d` is parsed as
`<b>a<script>b</b>c</script>d</b>` (that is, there is a literal </b>
in the script data), but:
   `<b>a<module>b</b>c</module>d` is parsed as `<b>a<module>b</module></b>cd`

There are more, but these are the main effects of using an generic tag name.
  --scott
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12