Re: [whatwg] The set of supported @type values for <script> is a bit odd

On Fri, 25 May 2012, Boris Zbarsky wrote:
>
> The list is at 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#support-the-scripting-language 
> or 
> http://dev.w3.org/html5/spec/the-script-element.html#scriptingLanguages 
> depending on which you prefer to read.
> 
> It seems to include several values that no UA actually supports, 
> apparently because of the way the spec uses the same list to deal with 
> both @language and @type.  See compat testing data at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=672814#c6 and the testcase 
> I used to generated that data at 
> https://bug672814.bugzilla.mozilla.org/attachment.cgi?id=627261
> 
> At the moment our plan in Gecko is to just implement this list as-is, I 
> think: it's a superset of what everyone implements, and it just doesn't 
> feel worth pushing back on the two Presto-only items and the three "no 
> one implements this" items.
> 
> This mail is just a heads-up for people in case they want to protest, 
> before we go ahead and ship this full list in Gecko.

On Fri, 25 May 2012, Ojan Vafai wrote:
> 
> Meh. Seems fine to me. My mild preference would be to at least remove 
> the three that no one implements, but I share you're feeling that it's 
> not worth arguing over either way. Filed an equivalent WebKit bug: 
> https://bugs.webkit.org/show_bug.cgi?id=87527.

On Fri, 25 May 2012, Maciej Stachowiak wrote:
> 
> If the weird values are just for compatibility, then I think it would be 
> better to change the spec to drop the ones no one implements. I 
> certainly would not want the list of versioned types to expand over time 
> with new JavaScript versions, so there is no need for it to be a 
> consistent or logical set.

On Sat, 26 May 2012, Anne van Kesteren wrote:
> 
> That is done to define language and type using the same underlying list 
> of values. We can of course change the way language ought to be 
> implemented.

As Anne points out, the weirdness here is just because the spec tries to 
simplify how "language" and "type" are implemented by making them use the 
same logic (basically, though check the spec for the details, the logic 
now is that we use type='' if we have it, else the value of language='' 
with text/ prepended).

Since the union of what was needed to support that had such a great 
overlap with what was actually implemented, it didn't seem worth it to 
instead have two almost identical lists.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 15 June 2012 22:23:48 UTC