On Sun, Jan 26, 2014 at 9:44 PM, Brendan Eich <[email protected]> wrote:
> David Sheets wrote: > >> There is no out-of-band metadata in a new script attribute. Attributes are >>> > data, not data-about-data, and in-band in HTML. >>> >> >> The channel is the contents of the script element or the ES resource. >> The attribute is not transmitted in the contents of the script element >> or ES resource. This seems out-of-band from the perspective of the >> programming language you are specifying. >> > > Same argument applies to a novel media type. It'll get stripped just as > much as the module attribute, but the latter has the advantage that old > browsers will ignore just the attribute, while with an unknown type= value > or version parameter (which we rejected with 1JS), the contents will be > ignored. > > >> is it desirable to encourage? Is it worth >>>> >> creating a new attribute on the script element for what should be a >>>> >> parameter of the media type? >>>> >>> > >>> > >>> > Who says modules*should* be a media type parameter? >>> >> >> They can be annotated in a lot of ways. If you want to transmit a >> variation in interpretation of a media type, it would seem >> straightforward to do so either: >> >> 1. in the content you are transmitting >> 2. in the media type of the content you are transmitting >> 3. in a parameter of the media type of the content you are transmitting >> > > This is all abstract and off target. We know what old browsers do, RFC > 4329 (https://www.ietf.org/rfc/rfc4329.txt) codified it. The concrete > choice is between new script attribute and new script type or version > parameter (other parameters than ;version would be ignored by old browsers, > making them equivalent to a new attribute, but harder to detect). > > > >> Is there a reason that feature detection and a new media type or >>>> media >>>> >> type parameter would not suffice? >>>> >>> > >>> > >>> > I'm advocating feature detection based on a new attribute, not a new >>> media >>> > type. I thought you were advocating the reverse. >>> >> >> Is a new attribute to change interpretation behavior feature >> detection? Usually feature detection happens in the language using the >> features... >> >> I'm advocating introducing the smallest possible number of ways to >> indicate the same bit of information. It seems that there is a demand >> for: >> >> 1. a file extension >> > > Talk here is not demand, and I bet we'll regret trying to add a new one. > Extensions mapped by servers to media types require server configury, often > missed or mangled. This has led in the past to clients hardcoding, e.g. > text/javascript for missing content type / type= attribute / > Content-Script-Type header in IE (older versions, not sure about 9 and up). This is concerning, an new file extension affects build systems, editors, servers, etc. This moves use back to something in the source code: // hey, I'm a module not a script "hey, I'm a module not a script"; ? > > 2. a media type mechanism >> > > Also a pain, easy to get lost as "metadata", easy to mangle, easy to > forget. IETF red tape is the least of it, but there's that too. > > 3. an HTML attribute >> > > See my repeated points about fallback in old browsers, this is the way to > win migration. > > > 4. in-language feature detection or declaration >> > > With module bodies in files in NPM and AMD, you don't need to detect > anything. Clients require provided modules, there's no new suffix or MIME > type. > > Why should ES6 be different? > > Now, say we add <script module>...</script> support. The ... bits can use > export, but need not. It could use the module loader API to do its deed, > detecting that API and falling back on global or other properties in old > browsers. > > Why shouldn't we support such two-way-compatible inline modules? > > > Of these, the HTML attribute seems to be the least flexible and most >> coupled. >> > > We want most coupled between 3 and 4, because that's what enables two-way > compatibility. > > > Is there a use case for 3 that is not covered by some combination of >> 1, 2, and 4? If 1 is used or encouraged, will you not specify 2? If >> neither 1 nor 2 is specified, >> > > Do Not Want 1 or 2, as far as I can tell. Both new media type and new > suffix face stiff adoption hurdles, hamper migration, add more typo and > forgetfulness habitat, and smell bad. :-P > > > will you expect each carrier >> specification (HTML, HTTP, file system, etc) to specify their own >> special way to convey this bit of metadata? >> > > It's implicit in filesystem cases such as NPM today, and that wins. > > If you insist on treating it as meta- (or OOB, better, but same point > here), please explain how filesystems convey media types today. Suffix > conventions do not do it on Unixy systems. #! is in-band but not relevant > to modules. Content sniffing considered harmful. > > HTML is the prize. We aren't going to generalize any useful "module body > here, not global code" in- or out-of-band attribute across all containers. > We don't need to for the out-of-line module case anyway. Only <script> is > recognized usefully in browsers old and new. This leaves two-way > compatibility winning, by my current analysis. > > /be > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
