- From: Philip Taylor <philip@zaynar.demon.co.uk>
- Date: Sat, 08 Sep 2007 18:09:46 +0100
- To: Mihai Sucan <mihai.sucan@gmail.com>
- CC: Anne van Kesteren <annevk@opera.com>, public-html <public-html@w3.org>
Mihai Sucan wrote: > The spec only defines a very simple way to process the language > attribute - which actually, most likely, breaks backwards-compatibility. > Here's why: if the UAs would implement the algorithm, they will end up > having things like: > > <script language="JavaScript1.2"> > <script language="Mocha"> > ... > > Interpreted as: > <script type="text/JavaScript1.2"> > <script type="text/Mocha"> > ... > > Which is obviously wrong - no current UA implements these MIME types. Some UAs do - from http://canvex.lazyilluminati.com/misc/jsversions2.html I see: IE7: text/javascript1.(1|2|3), text/jscript, text/livescript, text/ecmascript, text/javascript. Firefox 3: text/ecmascript, text/javascript, text/(java|ecma)script;version=1.n for n <= 8, text/(java|ecma)script;e4x=1. (Some of those versions have different language syntax.) Opera 9.5: text/jscript, text/ecmascript, text/javascript, text/x-javascript, text/x-ecmascript. Safari 3: text/javascript1.(1|2|3), text/jscript, text/livescript, text/ecmascript, text/javascript. http://www.ietf.org/rfc/rfc4329.txt mentions most of those, and defines text/javascript and text/ecmascript (but defines them as obsolete). Depending on which ones are needed for interoperability, it does sound sensible to map some language and type values onto the standard defined JavaScript MIME types, or to list them in the "3.17.1.1. Scripting languages" section. -- Philip Taylor philip@zaynar.demon.co.uk
Received on Saturday, 8 September 2007 17:09:53 UTC