W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Re: The interpretation of script

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 18 Jan 2011 14:26:45 +0200
Message-ID: <4D358705.1000808@iki.fi>
To: public-html-xml@w3.org
On 01/18/2011 10:38 AM, Robin Berjon wrote:
> On Jan 17, 2011, at 19:30 , Norman Walsh wrote:
>> But even something as simple as a (NO)RUN attribute on script (which
>> wouldn't cause any problems in legacy browsers) would at least provide
>> a way to make my intention explicit.
> 
> An alternative, perhaps simpler, approach would be to register application/dumb-data. This, as a type, would indicate something that
isn't to be run. If you have XML inside and you need to know what it is
you have namespaces for that, which are far better than media types in
the first place anyway.

Or simply use application/octet-stream and sidestep the issue of
fighting the IANA battles.

Yes, I realize that the contents of the script element isn't a stream of
octets. Also, I'm OK with you fighting the IANA battles for registering
application/dumb-data as long as I don't have to or Hixie doesn't have to.

Note that using type=application/dumb-data or
type=application/octet-stream would only solve the problem of a Web
author being nervous about a future browser maybe breaking his/her
content in the future. It wouldn't solve the problem that anyone who
wants to introduce a new automatically-executed type has to do the
research to avoid using a type value that has been used previously for
something else.

After all, HTML5 is paving a cowpath here, and e.g. Silverlight has
walked that cowpath with a type that's neither application/octet-stream
nor application/dumb-data.

On 01/18/2011 01:01 AM, Michael Champion wrote:
> Also sprach John Cowan:
>
>> >  if you want something to be data, use a media type that implies it
is data;
>> > if you want something to be code, use a media type that implies that.
> Hmm,  is XSLT "code" or "data"?

It's "data" as long as browsers don't support running it natively from
<script>. If a browser ever wants to add the feature of running XSLT
from a <script>, it needs to mint a new application/xslt-really-run+xml
type if text/xsl and application/xslt+xml have already been used for
"data" out there.

On 01/17/2011 11:48 PM, Norman Walsh wrote:
> I think the implication is that text/javascript is the only type of
> script that will ever execute automatically.

Not really. text/vbscript is also know to execute automatically in a
browser with substantial market share.

> Even if we totally
> replace JavaScript with some new language in 20 years, we'll still
> have to shim it in place with JavaScript.

Not necessarily. The new language just needs a type that hasn't yet been
used in the wild for stuff that isn't expected to be executed
automatically by the UA.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 18 January 2011 12:27:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 18 January 2011 12:27:03 GMT