(However, if we want to get pendantic there is the fun that the MIME
type "text/javascript" itself isn't exactly standardized... it was
ratified and deprecated at the same time... at the moment it's the
same state as the "Language" attribute. ;^) )
The W3C prompted a fiasco in requiring a type attribute, specifying that
it was a MIME type (and referencing the official list of MIME types) and
then citing the (at the time) fictional "text/javascript" as the only
ECMAScript related example. It left us with no reasonable choice but to
use "text/javascript" in the type attribute regardless of its unofficial
status, and the browser manufacturers with little choice but to
disregard HTTP content type headers sent with script files (as there was
no 'correct' MIME type to accept).
And now "text/javascript" has been recognised, deprecated, and "correct"
alternatives provided we cannot stop using "text/javascript" because the
current browsers will have no idea what to make of the new official MIME
types. A situation that is likely to remain for the next 4-5 years.
Still, that particular botch in the HTML specification is not nearly as
bad as the way they rendered the NOSCRIPT element unusable (in part
through failing to provide it with a matching type attribute so it could
be used when a particular type of scripting was unavailable).
On the subject of the deprecation of language as an attribute and
"text/javascript" as a MIME type, these deprecations are in different
standards. The status of the type attribute in not altered by the
deprecation of one if its values and non-deprecated alternatives exist
for its value, even if it will not be practical to use them form many
years.
Ironically, the older browsers that don't really understand the type
attribute and just default to javascript anyway will be more tolerant of
the use of the new MIME types than the browsers that have been in use in
the recent past will be.
1.3 _or higher_ (which as we've already noted can succesfully keep
versions of IE and Opera from biting).
My preference is to maximise active script support across browsers and
so only exclude browsers on the basis of their capabilities. Opera 7 and
IE 5 are both dynamic visual browsers capable of most of what can be
achieved in the other dynamic visual browsers, so I see little reason to
exclude them, and in the event that they cannot support a script I can
find other means of determining that.
I don't like the idea of excluding based on a browser's willingness to
accept a language version. I would worry about not knowing how the
"unknown browser" will react, or eve3n the set of browsers I am aware
of. Of the dynamic visual browsers I would rate Safari/Konqueror as the
least capable, with IceBrowser only fractionally ahead of them. I cannot
be sure of how they (and their various versions) may react to
language="javascript1.5" but I doubt that I want to exclude Opera 7
while including less capable browsers. I prefer to make decisions based
on what a browser is actually capable of.
My gander is raised by those that scream "STANDARDS" and beat their
chests but seemingly have no sympathy for those trying to work in the
real world where there is sloppy support and, in some cases, hacks
being the only method for getting something done.
Standards are very important and useful, and their adoption has
certainly contributed to making my life progressively easier. But I also
dislike the promotion of standard for their own sake, and without a
regard for the realities of the context in which they are used. XHTML
being a particular bugbear of mine when people propose writhing XHTML
because it is "the future", serving it as text/html and then scripting
the resulting HTML DOM. I.E. writing XHTML and then scripting it on the
assumption that the browser will be interpreting it as tag soup HTML.
Probably the most important aspect of standards is to read and
understand the ones that are applicable to a particular context, and to
understand their implications. It is probably the widespread failure of
web developers to ever do that that is most responsible for the
knee-jerk reaction of insisting upon standards no matter what. A
polarisation of attitudes, in which the insistence upon dogmatically
following the standards is almost justified by the monumental stupidity
that follows from the ignorance of them.
I read a good example in the last couple of weeks. A PHP author had
found a 'nice' little script that allowed the conditional serving of
XHTML as text/html or application/xhtml+xml depending on the content of
the HTTP request's Accept header (i.e. an effort at content
negotiation). Unfortunately the author of this script had done so in
total ignorance of the specified mechanism for content negotiation and
had instead decided to just search the content of the Accept header for
the character sequence "application/xhtml+xml" and use that content type
if it was found. The practical upshot being that an Accept header in a
request that explicitly stated its rejection of application/xhtml+xml
would be served that exact content type. And of course the PHP author
who was using the script also had no understanding of HTTP and its
content negotiation mechanism (even though HTTP is pretty much
fundamental to server-side scripting).
So I want people to understand the standards that apply to what they are
doing, and use those standards in preference to not doing so, but I am
also willing to accept that some things are best done outside of
published standards. However, my impression is that there are far fewer
things that actually require a disregard of the published standards than
some of the people who argue in that direction seem to think there are.
That is, if some of the people who cry; "you cannot always follow
standards" enumerated their specific concerns they may find others in a
position to significantly shorten the list. And in the absence of the
specifics I start to suspect that the cry is actually a justification
for sustaining and ignorance of the standards.
Personally I would REALLY like to see the standard expanded
to indicate supported language version.
<snip>
If ECMA 262 3rd edition was the last version of the specification for
the language there would be no need for a language versioning mechanism.
Richard.
