Erwin Moller wrote:
I just got out of the bad habbit of using
language="javascript", and now type="text/javascript"
is marked obsolete.
;-)
Any comments on this?
That is a kind of rwar topic, so the following is my personal point of
view that doesn't imply any kind of consensus behind it.
As of the year 2007 the most suggested way to insert script elements on
your page is
<script>
// your code
</script>
or
<script src="file.js"></script>
Any indication of language or type is discouraged as superfluous and
useless.
The _only_ exception from this rule is some MSIE-only solution where on
the same page one has both VBScript and JScript elements. In this case
and if the first element on the page is type="VBScript" then all other
elements without type indication will be treated as VBScript sources.
Even more importantly all intrinsic event handlers like onclick="" etc.
will be treated as VBScript sources. Obviously if one has handlers
written in JScript, she gets nothing by syntax errors around.
This way:
1) If you have JavaScript only on your page (inline or over src) then
any indication of language or type is discouraged as superfluous and
useless.
2) If you have both JScript and VBScript on one page but all your
intrinsic event handlers are written in JScript then be on the safe
side: as the very first script element on your page - in the head
section - place:
<script type="text/jscript">
/* This bogus script element if placed as the very first
* ensures that event handlers on your page will be read
* as JScript and not as VBScript.
*/
</script>
- surely the comment block is not necessary, feel free to leave just
<script type="text/jscript"></script>
but _please_ do _not_ use that ugly hack
<script type="text/jscript" />
Note: Using the moment I want to repeat: i) yes, it is an ugly hack,
demonstrating a lack of basic (X)HTML knowledge and ii) no, you cannot
use this hack unless for very particular circumstances covering lesser
than 1% of situations.
Respectively after that for each script element indicate either
type="text/vbscript" or type="text/jscript".
Actually this nuance is so MSIE+ASP+intranet specific that pretty much
irrelevant for WWW projects. Yet let's us mention it.
So if you have JavaScript/JScript only on your page (inline and/or over
src) then any indication of language or type is discouraged as
superfluous and useless.
Now what about "text/javascript" and "application/javascript" from the
official standard perspective?
First of all "text/javascript" is not a MIME types and never was such.
It is a MIME-looking string recognized by all modern browsers as script
element _attribute_. The only real MIME type ever used anyhow widely is
application/x-javascript associated by default with .js extension on
Microsoft IIS servers. But don't you ever try to set
type="application/x-javascript" even for IE: it doesn't know of such
_attribute_ though it knows about such MIME type. As the result while
for external scripts type attribute with any value is simply ignored,
for inline script blocks it will lead to them being ignored.
Also with external files just for fun of it you can serve even
application/octet-stream and UA couldn't care lesser. The handling of
javascript sources by Content-Type is abandoned years ago as high
security risk. When retrieving a file indicated in <script
src="file.ext"></scriptevery UA relies on its own internal security
check and protection. There are not any perspectives that people will
get better than they are now, so no expectations of any security relief
in the future years.
That moves the topic twenty or so levels down.
The question is then what _element attribute value_ should one use if
the suggested best way
<script>
// your code
</script>
or
<script src="file.js"></script>
just doesn't go with her ideas of right and wrong.
In this case use type="text/javascript". This is the only attribute
value universally understood by all browsers including IE. Attribute
value "application/javascript" is _not_ supported on the absolute
majority of browsers including but not limited by IE.
>From any practical point of view it is enough as an argument to send to
the deepest corner of hell anyone who suggests using
"application/javascript".
Still as long as the task is to cover all issues let's us answer to two
questions:
1) is "text/javascript" is obsolete as the standard script type
attribute value?
2) is "application/javascript" is some new standard as script type
attribute value?
(Earlier it was explained that in any case it is not related anyhow
with MIME questions).
1) is "text/javascript" is obsolete as standard script type attribute
value?
Hardly, because something that never existed cannot get obsolete.
"text/javascript" never was a standard script type attribute value, it
was the "most common usage". This way "application/javascript" cannot
obsolete it. The max "application/javascript" can be is
"standard-endorsed replacement to current usage"
2) is "application/javascript" is some new standard as script type
attribute value?
This is more complicated question where first I need to explain the
nature of RFC.
RFC is Request For Comments and by its "legal status" any RFC is on the
same level as my post you are reading right now. It is a formally
stated opinion of an individual or a group of individuals of how this
or that should be done and asking of what do others think about it.
Anyone can follow the publishing procedure (see details at
<http://www.rfc-editor.org/howtopub.html>) and if passed I-D (Internet
Draft) stage then it becomes one more of RFCs.
Does it become a _standard_ immediately to follow? No more than my
current instructions do not use any language or type attributes will
become such after I press "Send".
I-D RFC procedure has to correspond to the established formal format
criteria. There is not some international technical committee for a
profound expertise. Just like some people manage to patent from time to
time perpetuum mobile, one could manage to create "Best Practice" RFC
say suggesting to set TCP/IP packet length using the provided random
number generation algorithm. RFC archives contain many documents
demonstrating nothing but limits of human's bizarrity or vanity.
At the same time there are many RFC which are indisputable core of the
modern Internet. This is because of the unique nature of the Internet
and especially of the World Wide Web. This is a system with a
tremendous positive link and with almost zero negative link. It means
that if someone suggests or invents something and this something is
really needed, the process of duplication and adoption will go in
geometrical progression. Sometimes it takes lesser than one month when
a single program with sketchy specs being reproduced and used across
all wired world. This is the positive link. But if the positive link
worked out, no one - including the original specs author - has power to
change anything a day later. He himself and all new comers have nothing
to do but follow the original specs otherwise no one recipient will
understand them. IMO the most pictorial sample of this positive vs.
negative link disproportion is HTTP "Referer" header. The typo was
noticed I believe in less than a week after HTTP/1.0 server source and
specs posted, but even then it was too late to change anything, as it
was used on too many servers around the world. The only option was to
introduce special "HTTP grammar" where a referrer is written with one
"r".
Now it comes to Bjoern Hoehrmann, The Man Who Decided To Change The
Internet Alone. :-) Since 2001 he has an idee fix to application'ize
script type attribute value and the last year his initial I-D was
promoted into RFC#4329 <http://www.ietf.org/rfc/rfc4329.txt>
What effect will it produce onto Internet standards? The most strange
things may happen of course but IMO it remains forever what it is right
now: a collection of wasted electrons.
At the same time I am expecting some confusion from time to time for a
while. Now "Internet boomers" are representing the most active part
of the Internet: thus who was too young at the time of the Internet
explosion and now is finishing college or going on the first payroll.
They used to see references to core RFCs as a definitive argument, so
for many of them _any_ RFC is a law to obey as long as it's RFC. Some
people punished by the seventh sin are using it and they will use it:
so pushing whatever RFC to be published and then run around with it
like a plaintiff with subpoena. Boldly send them to hell - until
Internet's positive link worked out there is no law of any kind behind
of them.
As a positive sample I would suggest to work closely by RFC#4627
<http://www.ietf.org/rfc/rfc4627.txtis you are dealing with JSON data
format. Again: not just because it's RFC, such argument is worthless.
But JSON is on popularity growth and if the "positive link explosion"
happens then RFC#4627 will become the same authority as say RFC#2616.
