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).

> 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

David Sheets wrote:
> 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.

> 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 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).

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