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

Is there a reason that feature detection and a new media type or media
type parameter would not suffice?

The HTML metadata aspect of the syntax goals is different from the
general metadata hinting at the syntax type. If files with "es" or
"jsm" extensions will be treated differently by some interpreters,
this same indicator should be available at the media type level. If
this indicator is available at the media type level, it should be
usable in script/@type. If it is usable in script/@type, the
interpretation/non-interpretation of that element can be used to
detect the interpreter's capability in code common to both syntaxes.

I guess I'm not seeing the use case that is impossible under this
scenario which requires one fewer duplicate way to transmit the same
bit of metadata.

Thanks,

David

On Sat, Jan 25, 2014 at 11:26 PM, Brendan Eich <brendan at mozilla.com> wrote:

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

Is there a reason that feature detection and a new media type or media
type parameter would not suffice?

The HTML metadata aspect of the syntax goals is different from the
general metadata hinting at the syntax type. If files with "es" or
"jsm" extensions will be treated differently by some interpreters,
this same indicator should be available at the media type level. If
this indicator is available at the media type level, it should be
usable in script/@type. If it is usable in script/@type, the
interpretation/non-interpretation of that element can be used to
detect the interpreter's capability in code common to both syntaxes.

I guess I'm not seeing the use case that is impossible under this
scenario which requires one fewer duplicate way to transmit the same
bit of metadata.