On Jan 27, 2014, at 10:58 AM, David Bruant <bruan...@gmail.com> wrote:
> Agreed. Note that I didn't suggest to stop writing inline scripts and > proposed an alternative to script@module that can work today. > Granted, it's somewhat hacky, but I think it can work during the period > during which there'll be both ES6 and non-ES6 browsers to support. > > I was sloppy in my phrasing. What we don't need is the current inline script > "execute right now and block everything else" semantics, specifically for > modules which order of execution shouldn't block things. OK, sorry I jumped in the middle of things missing some context. In fact, I think what we've been planning on proposing is not too far -- I think -- from what you're talking about. The plan is *not* a module attribute (that was a think-o on my part, and maybe some misinformation that crept into this discussion earlier?) but type="module". That way on old browsers it's ignored and you can add shims to load it. Shims can be made future-proof via feature detection, so type="module" can obtain new semantics. Moreover, the type="module" should not actually mean "execute right now and block everything else," but rather "executing asynchronously once all my module dependencies are loaded and linked." Does that make more sense? I realize part of the issue here is there isn't a concrete plan or proposal that's been spelled out, it's just been informal discussions. That's on us, the modules champions, to put forward a proposal for web (i.e. non-Ecma) standardization ASAP. Yehuda's going to be in town for TC39 this week, so he and I will sit down and do an informal write-up so people can see the plan more clearly, while we work on a fuller proposal for standardization. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
