On Mon, Jan 27, 2014 at 1:29 AM, Brendan Eich <brendan at mozilla.com> wrote:
> David Sheets wrote:
>>
>> On Sat, Jan 25, 2014 at 11:26 PM, Brendan Eich<brendan at mozilla.com>
>> wrote:
>>>
>>> >  David Sheets wrote:
>>>>>
>>>>> >>>
>>>>> >>>  . Old browsers ignore the new attribute will process the content,
>>>>> >>> which
>>>>>>
>>>>>> >>>  >    could be written to work "both ways".
>>>>
>>>> >>
>>>> >>
>>>> >>  Is a new attribute necessary? What about using @type?
>>>
>>> >
>>> >
>>> >  Old browsers will ignore unknown types, losing the two-way fallback
>>> > option.
>>
>>
>> While it is possible to write scripts that change interpretation based
>> on out-of-band metadata,
>
>
> 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.

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

>> 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
2. a media type mechanism
3. an HTML attribute
4. in-language feature detection or declaration

Of these, the HTML attribute seems to be the least flexible and most coupled.

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, will you expect each carrier
specification (HTML, HTTP, file system, etc) to specify their own
special way to convey this bit of metadata?

Thanks,

David

On Mon, Jan 27, 2014 at 1:29 AM, Brendan Eich <brendan at mozilla.com> 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.

> 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

> 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
2. a media type mechanism
3. an HTML attribute
4. in-language feature detection or declaration

Of these, the HTML attribute seems to be the least flexible and most coupled.

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, will you expect each carrier
specification (HTML, HTTP, file system, etc) to specify their own
special way to convey this bit of metadata?