detecting JS language mode for tools
brendan at mozilla.com
Sun Jan 26 21:44:02 PST 2014
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
> I'm advocating introducing the smallest possible number of ways to
> indicate the same bit of information. It seems that there is a demand
> 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,
Content-Script-Type header in IE (older versions, not sure about 9 and up).
> 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
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
> 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.
More information about the es-discuss