5 June 2014 TC39 Meeting Notes

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

Re: 5 June 2014 TC39 Meeting Notes

Mathias Bynens
On 13 Jun 2014, at 18:15, Domenic Denicola <[hidden email]> 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
[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
In reply to this post by Domenic Denicola-2
Le 12/06/2014 16:43, Domenic Denicola a écrit :
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
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12