langua= vs type=

[xah]

what's the pro and con of using

<script language="javascript">
vs
<script type="text/javascript">

Xah
(e-mail address removed)
∑ http://xahlee.org/

 

[Martin Honnen]

what's the pro and con of using

<script language="javascript">
vs
<script type="text/javascript">

Originally when browser vendors invented the <script> element they gave
it a language attribute where the value could be anything.

Those standardizing HTML did not like that attribute but rather
preferred to introduce the type attribute which is supposed to take a
standardized content type value:
<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.1>
Ironically until recently text/javascript as a content type was nowhere
standardized.

By now you can simply use
<script type="text/javascript">
browsers around understand that and you write valid HTML 4 that way if
you care or other judging your HTML care.

 

[Jim Davis]

what's the pro and con of using

<script language="javascript">
vs
<script type="text/javascript">


I'd use both, personally.

The latter is standardized and recommended while the former is deprecated...
but the former still has the best support and is still the cleanest way to
specify the version of the language needed for the script.

For example using : <script language="JavaScript1.5"> will prevent your
script from running on
most older browsers.

It really annoys me when the W3C replacement technologies don't address all
the features of the thing they're replacing. ;^)

Jim Davis

 

[Kimmo Laine]

very good point. A look over the major sites shows that:

What does major sites have to do with writing valid markup? Nothing. Just
because a site has lot of hits, doesn't automatically say that the code is
valid. In fact, like in Google's case, the code may be complete crap. Just
try running google.com through a w3c validator - doesn't avalidate, man.
Instead you need to look at w3c specs what they have to say about it and do
it like that.

Major sites are not standards, standards are standards. w3c.org has listed
those standards and specifications for html markup, xhtml or css, etc.
Regardless of what major sites do, you need to do like the standards say,
not like major sites do it.

 

[Kimmo Laine]

amazon.com uses both and sometimes just the language=.

http://validator.w3.org/check?verbo...idos/subst/home/home.html/102-0819246-3276165
Cannot even begin to check code, because the charset is already fucked.

applec.om uses just the language=.

Assuming you meant apple.com?
http://validator.w3.org/check?verbose=1&uri=http://www.apple.com/
-> Not valid. One of the errors: required attribute "TYPE" not specified in

yahoo.com uses just the language=.

http://validator.w3.org/check?verbose=1&uri=http://www.yahoo.com/
-> Not valid (failed with unbelievable 266 errors.) Once again one of the
errors: required attribute "TYPE" not specified in <SCRIPT>, but there's
just so many things wrong with the page that one can but wonder, how the do
these pages work at all, unless the browsers have great tolerance for
errors.

orkut.com uses just the type=.

http://validator.w3.org/check?verbose=1&uri=https://www.orkut.com/Login.aspx
-> Not valid. One of the errors: required attribute "TYPE" not specified in

msn.com sometimes uses both, sometimes one or the other.
ebay same with msn.com.

http://validator.w3.org/check?verbose=1&uri=http://www.msn.com/
-> Not valid. Tries to be xhtml, but fails! Hah! And here's the thing:
there is no attribute "language" and required attribute "type" not
specified:
<script language="JavaScript">

And in your follow-up you refered to google.com:
http://validator.w3.org/check?verbose=1&uri=http://www.google.com/
-> Not valid. One of the errors: required attribute "TYPE" not specified in
<script>


In conclusion: in html 4.01 "type" is required in <script> and when moving
to xhtml, language is no more allowed. Need I say more?

Lesson we learned today, kids, is that never ever look at major sites code
and assume it's correct. Not one single site of what you suggested were
valid according to w3c validator.

 

[Lasse Reichstein Nielsen]

I'd use both, personally.

The latter is standardized and recommended while the former is deprecated...

.... and required for validating HTML, not to forget.

but the former still has the best support

Can you find any browser that accepts <script language="javascript"> but

and is still the cleanest way to specify the version of the language
needed for the script.

The version of "JavaScript" that you need, but only Netscape and Mozilla
uses JavaScript as the language. IE uses JScript and other browsers use
their own version of ECMAScript.

For example using : <script language="JavaScript1.5"> will prevent your
script from running on most older browsers.

That might be useful if your script contains new syntax not available
in earlier versions, but otherwise you should use feature detection
instead. It degrades much cleaner.

Also, at least one version of JavaScript had different semantics for
the same code, compared to later (and earlier) versions. Specifiying
that version, i.e., <script language="javascript1.2">, will make
some browsers use JS1.2 semantics and other browsers use current version
semantics, so the same program works differently *because* the language
version is specified.

I recommend only using the type attribute and using feature detection
for differences between different browsers. There are far more browsers
than there are JavaScript versions.

/L

 

[xah]

The latter is standardized and recommended while the former is deprecated....
but the former still has the best support and is still the cleanest way to
specify the version of the language needed for the script.

very good point. A look over the major sites shows that:

amazon.com uses both and sometimes just the language=.

applec.om uses just the language=.
yahoo.com uses just the language=.
orkut.com uses just the type=.

msn.com sometimes uses both, sometimes one or the other.
ebay same with msn.com.

so far it seems the language= is more popular...

Those using language= does not always indicate a version.

one wonders if there is a pattern for sites that uses both sometimes
one of the other.
my guess is that it's rather random...

oh, the story of the industry....

Xah
(e-mail address removed)
∑ http://xahlee.org/

 

[xah]

(e-mail address removed) wrote:
A look over the major sites shows that:

amazon.com uses both and sometimes just the language=.

applec.om uses just the language=.
yahoo.com uses just the language=.
orkut.com uses just the type=.

msn.com sometimes uses both, sometimes one or the other.
ebay same with msn.com.

google.com simply uses <script> period, way ahead of the pack!

Xah
(e-mail address removed)
∑ http://xahlee.org/

 

[Jim Davis]

... and required for validating HTML, not to forget.


Can you find any browser that accepts <script language="javascript"> but
doesn't treat <script type="text/javascript"> exactly the same?

Yes - all of them. The former can specific version while the latter
cannot - this is a difference. Also, there is really nothing to do with the
type="text/javascript" - can you give me an exmaple of how a browser that
supports the src attribute but doesn't support the type attribute would
behave differently from one that supports both?

The version of "JavaScript" that you need, but only Netscape and Mozilla
uses JavaScript as the language. IE uses JScript and other browsers use
their own version of ECMAScript.

While that's true in a sense it's not in practice. JScript (and other
browser implementations) are ECMAScript complaint - so they happily accept
"JavaScript1.3" (for example) as a language attribute. The marketing name
of the implementation doesn't affect it compatibility with the standard
name.

That might be useful if your script contains new syntax not available
in earlier versions, but otherwise you should use feature detection
instead. It degrades much cleaner.

True - I agree completely. But often it's unclear what features to detect.
;^)

Noplace did I say (or will I ever say) that you should use this as your only
validation of capability. But it is a very good "front line" which gives
you a basic level of understanding.

Also, at least one version of JavaScript had different semantics for
the same code, compared to later (and earlier) versions. Specifiying
that version, i.e., <script language="javascript1.2">, will make
some browsers use JS1.2 semantics and other browsers use current version
semantics, so the same program works differently *because* the language
version is specified.

Exactly (the browser you're thinking of is Netscape 2.0) which is why, in
general, I recommend using "JavaScript1.3" as the language attribute.
You're code won't run on Netscape 2.0 but neither will you have to deal with
it's broken implementation.

Jim Davis

 

[Matt Kruse]

Regardless of what major sites do, you need to do like the
standards say, not like major sites do it.

Answer this: Why?

Maybe your answer is, if you code to the standards and validate, then you
can expect well-behaved browsers to handle your code correctly.

However, this isn't always the case. Sometimes, browser quirks need to be
taken advantage of. Sometimes you can add functionality to a site for older
browsers or even modern quirky browsers by 'hacking' the source, when the
browsers wouldn't have otherwise been able to handle the functionality using
the 'standards' approach.

There are certainly good arguments for validation and following standards.
In most cases, they are completely convincing and good advice. But you also
need to consider the 'big guys' and what they are doing. If they get more
hits than you can imagine, can hire the best people, can throw lots of money
at problems, and can make sites which offer advanced functionality in many
browsers, then maybe they ARE doing something right, even if their source
doesn't validate.

If you can enhance the user experience with functionality that one browser
has (say, IE) and others do not, but using this functionality causes the
source to not validate perfectly, then what would you be gaining by removing
the added functionality? Would you rather have it validate, but remove
functionality?

IMO, validation is a tool. Having source that validates is one of many goals
for a site. If the validation goal conflicts with another goal (such as
supporting older browsers, or supporting non-standard browser functionality)
then a decision needs to be made. People who blindly say the sites should
always validate are naive. IMO.

 

[Robert]

what's the pro and con of using

<script language="javascript">
vs
<script type="text/javascript">

Use
<script type="text/javascript">

http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1

It's the only way to get standards compliant HTML.

Although the language parameter allows you to detect the version, it is
actually much easier to use feature detection instead of having to
figure out which feature is in which version. And it would not surprise
me if browser think different about what is in which version.

The fact that most website use the language parameter (too) is no reason
to do it like that too. Most people do not know or care about web
standards and other browsers than IE.

 

[Richard Cornford]

(e-mail address removed) wrote:
A look over the major sites shows that:

Don't make that mistake. Being a major site says nothing about best
practice. Indeed they often represent a good demonstration of how badly
you can get away with doing things, but the bigger you are generally the
more you can get away with.

google.com simply uses <script> period, way ahead of the pack!

Using Google with IE set up to pop-up its script error dialog (as I
usually do at work) will soon free you from the delusion that Google
have anything to teach anyone about browser scripting.

Richard.

 

[Richard Cornford]

what's the pro and con of using

<script language="javascript">

cons:-
1. Any document using that attribute cannot be validated
against a strict version of an official W3C HTML 4+
or XHTML DTD.
2. There is a risk that individuals using the language
attribute may employ the formulation -
LANGUAGE="Javascritp1.2" - and may get what they are
asking for (with all of JavaScript 1.2's divergent behaviour)[1].
3. There is a risk that an individual using the language
attribute may make the mistake of believing that a browser's
willingness to execute the contents of a script element with
a language version implies the availability of the complete
set of features from that version of JavaScript (tm), and that
its unwillingness to execute such a script implies that it
does not support the language features require by the script.
So, a language attribute might specify version 1.2+ and
expect Object's to implement the - watch - method, only to be
disappointed in many (most) cases, or a script may require
try-catch and so specify version 1.4+, only to have JScript 5
browsers refuse to execute the script, even though JScript 5
supported try-catch (but not finally).

pros:-
1. Nothing springs to mind.

[1] Indeed you will often see scripts that try to test for the existence
of some feature by combining a comparison with null and a - typeof -
test to see if the result is "undefined". This is a direct result of
trying to author scripts that will function with the divergent
type-converting behaviour of JavaScript 1.2 and the more expected
behaviour of all other versions (and all ECMAScript implementations).
Without a specified version the only browsers that will exhibit this
divergent behaviour are Netscape 4.0 to 4.05, and nobody will still be
using those versions, as all Netscape versions below 4.6 are well known
to have significant security vulnerabilities, and Netscape 4 is very
much on its last legs by now anyway.

vs
<script type="text/javascript">

cons:-
1. Nothing springs to mind.

pros:-
1. The type attribute is _required_ in all official W3C
HTML 4+ and XHTML DTDs and so must be used if a document
is going to validate, and valid documents exhibit much
more consistent behaviour/structure when their DOMs are
being scripted.


If the language attribute is combined with the type attribute, and the
language attribute does not specify a version (and so avoids inviting
all of the problems that specifying a version implies) then the language
attribute is redundant, and so a waste of time.

Informed opinion recommends using the type attribute, always and only.

Richard.

 

[Jim Davis]

(e-mail address removed) wrote:

Although the language parameter allows you to detect the version, it is
actually much easier to use feature detection instead of having to figure
out which feature is in which version. And it would not surprise me if
browser think different about what is in which version.

And yet certain features are difficult to detect...

For example what code would detect the "typeof" operator (only available in
1.1 and above)? How about the delete operator - which only works correctly
in 1.2 and above? The identity operator was only introduced in 1.3 and
above and so forth.

I'm not saying that there are NOT ways to test for these, however setting a
baseline defining the "language" attribute (which is supported by all major
browsers and most, if not all, minor ones) allows you to focus more on the
code and less on the checking.

I think for many things you should still do some checking - but but really,
doing feature detection for language _version_ is weak. And some features
of the language are version specific in how they work although they exist in
all versions.

The fact that most website use the language parameter (too) is no reason
to do it like that too. Most people do not know or care about web
standards and other browsers than IE.

I agree... and yet ignoring the real-world situation and pendantically
following standards is just as myopic in my opinion.

I feel VERY strongly that standards should be followed whenever possible. I
also feel just as strongly that choosing not to follow standards can be a
valid choice IF you know why you're doing and the decision is defensable in
your situation.

Put simply you need to know (and respect) the rules before you should ever
consider breaking them.

Jim Davis

 

[Jim Davis]

Don't make that mistake. Being a major site says nothing about best
practice. Indeed they often represent a good demonstration of how badly
you can get away with doing things, but the bigger you are generally the
more you can get away with.

I have to agree with this.

Another issue is that large sites often make very bad choices - especially
large sites which do not represent technological companies.

Try, for example, Metlife.com with no scripting enabled. Once you do that
enable script and check out the source of the page.

I could go into horror stories about this (well... actually, I can't, since
I work there - but I don't work on this).

Jim Davis

 

[Jim Davis]

cons:-
1. Any document using that attribute cannot be validated
against a strict version of an official W3C HTML 4+
or XHTML DTD.

Well... it cannot be validated without errors. It can still be validated
however!

And, since the error is both clear, and (if you know what you're doing)
expected it's hardly an enormous inconvienence.

Also, of course, it will validate against a non-strict version.

2. There is a risk that individuals using the language
attribute may employ the formulation -
LANGUAGE="Javascritp1.2" - and may get what they are
asking for (with all of JavaScript 1.2's divergent behaviour)[1].

Which is a great reason to only use JavaScript1.3 or above - not a reason
not to use the attribute at all.

3. There is a risk that an individual using the language
attribute may make the mistake of believing that a browser's
willingness to execute the contents of a script element with
a language version implies the availability of the complete
set of features from that version of JavaScript (tm), and that
its unwillingness to execute such a script implies that it
does not support the language features require by the script.
So, a language attribute might specify version 1.2+ and
expect Object's to implement the - watch - method, only to be
disappointed in many (most) cases, or a script may require
try-catch and so specify version 1.4+, only to have JScript 5
browsers refuse to execute the script, even though JScript 5
supported try-catch (but not finally).

This is really the big one... and it's not as easy to address as it really
should be.

If you use "JavaScript1.5" you do get, in nearly all browsers (and all the
major ones) what you want - but that's not enough.

Any language version filter must, almost by definition, extend itself to
deal with implementation-specific issues. In many cases this can be done
using feature discovery, however this is difficult for core statements and
operators.

But in the end this is a good reason not rely completely on the language
attribute... but not a good reason to ignore it compeltely.

pros:-
1. Nothing springs to mind.

There are really only two pros:

1) The language validation does indeed work in most browsers and all of the
most popular ones. If you're willing to go off standard (and this choice
should be an informed one of course) you do gain a level of detection.

2) Older browsers may not understand the "type" attribute. In some, rare,
cases the language attribute is really the only way to get the job done (as
when using vbscript instead of JavaScript in an older version of IE).

cons:-
1. Nothing springs to mind.

Nothing at all. It's standardized, it's easy, it's ignorable by those that
don't understand it.

pros:-
1. The type attribute is _required_ in all official W3C
HTML 4+ and XHTML DTDs and so must be used if a document
is going to validate, and valid documents exhibit much
more consistent behaviour/structure when their DOMs are
being scripted.

Too true... of course it doesn't actually DO a damn thing, but still, it is
required. There isn't a browser in existence that changes it's behavior
based on this attribute.

If the language attribute is combined with the type attribute, and the
language attribute does not specify a version (and so avoids inviting
all of the problems that specifying a version implies) then the language
attribute is redundant, and so a waste of time.

Informed opinion recommends using the type attribute, always and only.

Informed opinion can inform either decision. My preference (based on my
informed opinion) is still to use both with a language attribute of 1.3 or
higher depending on the script.

Jim Davis

 

[Michael Winter]

On 27/08/2005 23:26, Jim Davis wrote:

[snip]

For example what code would detect the "typeof" operator (only
available in 1.1 and above)? How about the delete operator - which
only works correctly in 1.2 and above?

Exactly why would you need to? Browsers that don't support them have an
object model that is too primitive to be useful, if they are in use at all.

Avoiding fatal errors is important, but trying to cope with Netscape 3
(including other browsers in its generation or earlier) is utterly
pointless, and NN4 is generally ignored (and becoming more so with good
reason).

The identity operator was only introduced in 1.3 and above and so forth.

That would /mainly/ affect very early NN4 versions, so again it would
seem irrelevant.

[snip]

Mike

 

[Michael Winter]

[snip]

<script language="javascript">
vs
<script type="text/javascript">

[snip]

The latter is standardized and recommended while the former is
deprecated... but the former still has the best support

The type attribute has existed since the Working Draft of HTML 4.0
(1997), just after the initial release of NN4, but before IE4. Given
that both support the type attribute[1], and they are the oldest
generation worth considering when scripting (and that can be of some
debate), your statement seems somewhat irrelevant.

and is still the cleanest way to specify the version of the language
needed for the script.

The language version is also irrelevant. Most features of ECMAScript 3rd
Ed. can be used with no problems even on obsolete browsers.

[snip]

Mike


[1] The earliest NN4 version I have installed is 4.77. I might check an
earlier version tomorrow (4.08). I expect it will also support the type
attribute, but I'll follow up if it doesn't.

 

[Randy Webb]

Jim Davis said the following on 8/27/2005 3:42 PM:

Exactly (the browser you're thinking of is Netscape 2.0) which is why, in
general, I recommend using "JavaScript1.3" as the language attribute.

No. NN4.xx showed the same behavior. I don't know about NN2.0 (and don't
care to be honest) but I do know that NN4.xx had a severe problem with
javascript1.2 as the language attribute.

 

[Richard Cornford]

Robert wrote:

And yet certain features are difficult to detect...

For example what code would detect the "typeof" operator
(only available in 1.1 and above)?
How about the delete operator - which only works
correctly in 1.2 and above? The identity operator
was only introduced in 1.3 and above and so forth.

It is certainly true that language features that have been introduced
across versions are not necessarily easy to detect, especially compared
to browser features. On the other hand it is worth considering the
context in which we are working (i.e. August 2005). Netscape 4.06
introduced JavaScript 1.3, in 1998 as I recall, and as an implementation
of the second edition of ECMA 262. At this point the chances of
encountering a browser that does not support the features of JavaScript
1.3/JScript 3/ECMA 262 2nd edition or better are extremely slim, as such
ancient browsers are not capable of coping with the Internet as it now
is, and so are of little use to anyone.

Even tow-three years ago nobody was particularly worried about using the
typeof operator, though they would not use try-catch on the Internet.
These days we are getting to the point where even relatively recent
additions like try-catch are starting to seem practical, especially as
ECMA 262 3rd edition has existed since the end of 1999 and is the
standard to implement as the basis for a client-side scripting language.
That is, the current standard is now getting old enough to be relied
upon to provide a consistent basis for scripting across browsers.

Now we just have to hope that ECMA 262 4th edition never gets ratified,
and starts us off again on another round of language version
incompatibility.

I'm not saying that there are NOT ways to test for these,
however setting a baseline defining the "language" attribute
(which is supported by all major browsers and most, if not
all, minor ones) allows you to focus more on the code and
less on the checking.

That would be true if specifying versions actually worked. We have the
problem with IE, where JavaScript versions just don't map directly to
the capabilities of JScript versions. And then there are the browsers
that happily execute scripts specified as language="Javscritp1.6" (which
is a fictional version that may never exist), and so can be assumed to
execute any script with one single interpreter. These browsers (as
identified to date) are all ECMA 262 3rd edtion implementations so it
doesn't matter that they are not interested in the languae versions, but
if it is possible to find a pre-ECMA 262 3rd edition implementation that
disregards specified versions then specifying language versions would
already be a nonsense (and the fact that nobody has yet identified such
a browser is no guarantee that there is not one).

I think for many things you should still do some checking
- but but really, doing feature detection for language
_version_ is weak.

You would not be testing for the language version, in the same way as
you don't check browser versions. The point of feature testing is to
find out what you need to know in the context of the specific script, no
more and no less. The version doesn't matter much once you have
determined that.

And some features of the language are version specific
in how they work although they exist in all versions.

After 5 years of language standardisation there are not that many
problematic features lest. There are aspects of Regular Expressions that
are extensions beyond ECMA 262, and very difficult to test for, and
there are a few optional language features (such as function references
as the second argument to the String.replace function), but they are
much easier to test for.

We do have a standardised language with a core that is sufficient for
the vast majority of authoring tasks. The remaining issues are almost
entirely with the browser object models and not in the language.

Put simply you need to know (and respect) the rules before
you should ever consider breaking them.

Yes, that is the way to go.

Richard.