On Sun, Jan 26, 2014 at 9:44 PM, Brendan Eich <brendan at mozilla.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140127/4e2006f3/attachment.html>

On Sun, Jan 26, 2014 at 9:44 PM, Brendan Eich <brendan at mozilla.com> wrote:

> 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:

```js
// hey, I'm a module not a script
"hey, I'm a module not a script";
```

?