469,286 Members | 2,522 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,286 developers. It's quick & easy.

langua= vs type=

xah
what's the pro and con of using

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

Xah
xa*@xahlee.org
http://xahlee.org/

Aug 27 '05 #1
31 2370


xa*@xahlee.org wrote:
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.

--

Martin Honnen
http://JavaScript.FAQTs.com/
Aug 27 '05 #2
<xa*@xahlee.org> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
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
Aug 27 '05 #3
"Jim Davis" <ne********@vboston.com> writes:
<script language="javascript">
vs
<script type="text/javascript">
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
doesn't treat <script type="text/javascript"> exactly the same?
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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Aug 27 '05 #4
xah
> <script language="javascript"> vs <script type="text/javascript">
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
xa*@xahlee.org
http://xahlee.org/

Jim Davis wrote: <xa*@xahlee.org> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
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


Aug 27 '05 #5
xah

x...@xahlee.org 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
xa*@xahlee.org
http://xahlee.org/

Aug 27 '05 #6
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:ac**********@hotpop.com...
"Jim Davis" <ne********@vboston.com> writes:
<script language="javascript">
vs
<script type="text/javascript">
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
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?
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.


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.
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.


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
Aug 27 '05 #7
<xa*@xahlee.org> kirjoitti
viestiss:11**********************@g49g2000cwa.goo glegroups.com...
<script language="javascript"> vs <script type="text/javascript">
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:


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.

--
SETI @ Home - Donate your cpu's idle time to science.
Further reading at <http://setiweb.ssl.berkeley.edu/>
Kimmo Laine <et****************@5P4Mgmail.com>
Aug 27 '05 #8
<xa*@xahlee.org> kirjoitti
viestiss:11**********************@g49g2000cwa.goo glegroups.com...
amazon.com uses both and sometimes just the language=.
http://validator.w3.org/check?verbos...819246-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?verbos...www.apple.com/
-> Not valid. One of the errors: required attribute "TYPE" not specified in
<SCRIPT>
yahoo.com uses just the language=.

http://validator.w3.org/check?verbos...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?verbos...com/Login.aspx
-> Not valid. One of the errors: required attribute "TYPE" not specified in
<SCRIPT>
msn.com sometimes uses both, sometimes one or the other.
ebay same with msn.com.


http://validator.w3.org/check?verbos...//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?verbos...ww.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.

--
SETI @ Home - Donate your cpu's idle time to science.
Further reading at <http://setiweb.ssl.berkeley.edu/>
Kimmo Laine <et****************@5P4Mgmail.com>
Aug 27 '05 #9
xa*@xahlee.org wrote:
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/interac....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.
Aug 27 '05 #10
Kimmo Laine wrote:
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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Aug 27 '05 #11
xa*@xahlee.org wrote:
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.
Aug 27 '05 #12
xa*@xahlee.org wrote:
x...@xahlee.org 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.
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!


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.
Aug 27 '05 #13
"Robert" <ro*@secret.xyz> wrote in message
news:43***********************@news.xs4all.nl...
xa*@xahlee.org 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
Aug 27 '05 #14
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:de*******************@news.demon.co.uk...
xa*@xahlee.org wrote:
x...@xahlee.org 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.


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
Aug 27 '05 #15

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:de*******************@news.demon.co.uk...
xa*@xahlee.org wrote:
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.


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).
<script type="text/javascript">


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
Aug 28 '05 #16
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
Prefix subject with [News] before replying by e-mail.
Aug 28 '05 #17
On 27/08/2005 18:18, Jim Davis wrote:
<xa*@xahlee.org> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
[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.

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Aug 28 '05 #18
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.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Aug 28 '05 #19
Jim Davis wrote:
Robert wrote: <snip> 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.

<snip> 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.
Aug 28 '05 #20
xa*@xahlee.org wrote:
[...]

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...


Unfortunately, that's all you have - a guess. Does anyone know why
those sites use those particular script element attributes? If asked,
would anyone at the site have an answer they'd be prepared to share with us?

Large slabs off all the sites seem to be cobbled together from all sorts
of sources (if the randomly distributed copyright and IP claims are to
be believed), much of the UI seems to have been 'developed' elsewhere
using a variety of publishing tools.

My guess is that any legitimate reason for using type or language for
any particular script has long since been forgotten on the basis that if
it ain't broke, don't fix it. In other cases, mixing language and type
(or ignoring them altogether) does not cause them any significant issues
at all.

[...]
--
Rob
Aug 28 '05 #21

"Michael Winter" <m.******@blueyonder.co.uk> wrote in message
news:T6*****************@text.news.blueyonder.co.u k...
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.


So... we should do feature detection only if those features are easy to
detect? ;^)

Those are only examples: there are features like that every version of the
language and there will no doubt be many more to come. There are features
only available in 1.4 and those only available in 1.5 and there will be new
ones only available in 1.6.
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.


But, again, don't discount the question for the examples. There are
definately features that are difficult to detect and plan around. A useful
way to determine supported language version is "a good thing" despite the
fact that the method we have for detemining this is is flawed.

Jim Davis
Aug 28 '05 #22
Michael Winter wrote:
<snip>
[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.


As I recall those older Netscape browsers do not support the type
attribute as such, what they do is ignore an unrecognised attribute, and
default to assuming javascript in the absence of any other instructions.
Which is why you can get away with <SCRIP> in most cases, as all
browsers that can be scripted default to assuming javascript. That is a
good thing as it means that the required type attribute is harmless when
it is not understood.

Richard.
Aug 28 '05 #23
Jim Davis wrote:
Richard Cornford wrote:
xa*@xahlee.org wrote:
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.


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


I suppose that is the distinction between validation as running the
mark-up through a validator, and validation as having the validator
declare the result as valid.
And, since the error is both clear, and (if you know what you're
doing) expected it's hardly an enormous inconvienence.
The error is clear and can be disregarded as not significant. There are
attributes that are not part of HTML that you may be willing to dismiss
in a validator error report, such as the galleryimage attribute, which
the W3C validator will flag as an error, but if it has been used it has
been used for a reason (hopefully). But why have the validator churn out
error messages that can be avoided with no consequences for the
resulting document.
Also, of course, it will validate against a non-strict
version.
And it may validate against non-official DTDs, which is why I said so.
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.

<snip> 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.
But in "nearly all browsers (and all the major ones)" you get ECMA 262
3rd edition if you don't use the language attribute, but use only the
type attribute, so specifying a recent version number gains you little
And it costs some compatibility. I have mentioned IE 5/JScript 5; it
will not load anything higher than language="javascirpt1.3", but IE 5
does have a (more or less) workable, dynamic W3C level 1 DOM and many of
the language features introduced in ECMA 262 3rd edition. It is also not
yet so old that it is out of use entirely (even if those actually using
it would be well advised to switch to a later version (or an
alternative)).

<snip>
pros:-
1. Nothing springs to mind.


There are really only two pros:

<snip> 2) Older browsers may not understand the "type" attribute.
That doesn't matter as they default to using javascript anyway, which is
why you can get away with just <SCRIPT>.
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).
To date IE is the only browser to offer a choice of scripting language,
and it defaults to JScript. So if you use another language you need to
tell it which one, but that is not really significant outside IE only
Intranets.
<script type="text/javascript">


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.


And those are cons of type="text/javascript"?
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 are browser where the type attribute does do something. Such as
IE, where if you put a VBScript element at the top of a page the browser
switches to assuming script elements are VBscript instead of javascript,
but an element with type="text/javascirpt" will still be interpreted as
javascript (or, more accurately JScript, assuming the DLL is
installed/available). Mozilla also does something in response to the
contents of the type attribute, for example, a particular formulation of
type attribute gives you the XML extensions for ECMAScript.

Granted, in the vast majority of cases what a browser does in response
to encountering type="text/javascript" is indistinguishable from what it
would do if there where no attributes in the script element at all, but
that does not mean that they actually do nothing in response to it.
There isn't a browser in existence that changes it's
behavior based on this attribute.
Well there are, but that is not what I was referring to. The important
aspect of HTML validity for scripting is structural validity; the
correct nesting of the various types of elements. Documents that are
structurally invalid are subject to browser error correction during the
creation of their DOM, and no two browsers follow the same
error-correction rules (as they are non-standardised and unpublished).
It is entry possible to present an invalid document to the three most
common browsers and get 3 distinct DOM structures as a result. If you
are then trying to script that DOM coping with the differences is extra
work, and will tend to give the impression that accommodating a range of
browsers is harder work than it really is.

Structurally valid mark-up maps directly to a single DOM structure,
following well understood and standardised rules. Thus structurally
valid mark-up results in DOM structures that are more consistent across
browsers, and so easier to script. That is what is important about HTML
validation in relation to browser scripting.

Obviously a document that is reported as valid by a validator will be
structurally valid. You can have structural validity (and so a constant
DOM) alongside invalid/missing attributes, but it is easier to see that
a document is structurally valid when you don't have to look past a mass
of validity errors relating to missing required attributes.
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.


Well it could, but it doesn't tend to. Searching this newsgroup's
archives for the last three years will hardly turn up any
recommendations for the use of the language attribute.
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.


Version 1.3 is pointless in a world where pre-version 1.3 browsers are
not used, and later versions exclude some of the older browsers still in
use where such exclusions are not necessarily justified.

Richard.
Aug 28 '05 #24

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:de*******************@news.demon.co.uk...
Jim Davis wrote:
Richard Cornford wrote:


But in "nearly all browsers (and all the major ones)" you get ECMA 262
3rd edition if you don't use the language attribute, but use only the
type attribute, so specifying a recent version number gains you little
And it costs some compatibility. I have mentioned IE 5/JScript 5; it
will not load anything higher than language="javascirpt1.3", but IE 5
does have a (more or less) workable, dynamic W3C level 1 DOM and many of
the language features introduced in ECMA 262 3rd edition. It is also not
yet so old that it is out of use entirely (even if those actually using
it would be well advised to switch to a later version (or an
alternative)).


IE 5.x is a peeve of mine: using "JavaScript1.5" prevents it from running
some script which is exactly what I want in some cases. But there are
others. For example Opera (versions 5-7) will claim a "1.4" compatibility
and will not run code labeled "1.5".
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.


And those are cons of type="text/javascript"?


Not at all. I've never, ever argued against using the type attribute -
never. I'm all for it. I'm a booster, you see!

(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. ;^) )
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.


Version 1.3 is pointless in a world where pre-version 1.3 browsers are
not used, and later versions exclude some of the older browsers still in
use where such exclusions are not necessarily justified.


1.3 _or higher_ (which as we've already noted can succesfully keep versions
of IE and Opera from biting).

However, all that said you may very well be convincing me... and I'm big
enough to admit it. (Actually I'm big enough to admit it while shattering
folding chairs... but let's not get personal. ) Give me the night to think
it over but I think you've got a convert.

Just to be clear (and ramble a bit): I appreciate the conversation for the
content of it. Your arguments are (what I consider) good arguments: you
argue practically for the standard and THAT'S what convincing.

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.

Personally I would REALLY like to see the standard expanded to indicate
supported language version. While there will always be browser bugs and
inconsistencies to deal with it would be vastly nicer to deal with them on a
field of level expectations. Although a MIME type to do this isn't very
attractive to me (this isn't just a browser issue: it has to do with
different levels of support in ActionScript, Windows Scripting host and
other ECMAScript containers).

I'm not naive enough to think this will actually happen... but it's still a
nice thought.

Jim Davis
Aug 28 '05 #25
"Matt Kruse" <ne********@mattkruse.com> kirjoitti
viestiss:de********@news4.newsguy.com...
Kimmo Laine wrote:
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.


You read me like an open book.
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.
What do are doing right, is that they have the stuff people need from the
web. those examples given would be buying and selling stuff and searching
and communicating. I'm not a regular user of the sites so I couldn't tell
what the added functionality would be. Except for google.com, which is my
start page, I see no added functionality in unqualified source code.

I do see One Major Disadvantage in the future as I look into my crystal
ball. It's this: IE css hacks will break in the future when IE7 comes. IE
css hacks are pieces of code that hide certain style sheet properties from
IE, that it cannot handle. The code is "hidden" inside a syntax IE can't
handle. Now: IE 7 can handle the syntax, so it can see the code too. But it
can't still handle the code. Because well, let's just say that IE still
sucks. Same shit, different version number.
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?


This is where the two of us differ. I will not implement browser-specific
code that would add functionality /if/ it caused page not to validate. So
far that has meant simply no ActiveX components. I have always achieved what
I wanted so that it does work on all major browsers and remains valid code.

--
SETI @ Home - Donate your cpu's idle time to science.
Further reading at <http://setiweb.ssl.berkeley.edu/>
Kimmo Laine <et****************@5P4Mgmail.com>
Aug 28 '05 #26
Jim Davis wrote:
"Robert" <ro*@secret.xyz> wrote in message
news:43***********************@news.xs4all.nl...
xa*@xahlee.org 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.


The other posters have already answered this for me :)
I myself am sceptic towards using the language attribute for detecting
such language features.

I would like to go back to the question of the original poster. I do
think we can all agree that:

type="text/javascript"
is better than
language="javascript"

Robert.
Aug 28 '05 #27
On 28/08/2005 02:25, Jim Davis wrote:

[snip]
So... we should do feature detection only if those features are easy to
detect? ;^)


Not at all. We should detect features that we need, that are likely to
be missing and, with the exception of some built-in methods (in
Array.prototype, for instance), these features are almost exclusively in
the object model not the language.

Yes, there are language features that can often be missing in some
earlier browser versions (not limited to exception handling, the
instanceof operator, property/prototype examination methods), but these
can be happily avoided for the most part.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Aug 28 '05 #28
"Robert" <ro*@secret.xyz> wrote in message
news:43***********************@news.xs4all.nl...

I would like to go back to the question of the original poster. I do think
we can all agree that:

type="text/javascript"
is better than
language="javascript"


Well - I've been convinced.

Although... just to be a prick... I must point that both are, in fact,
deprecated. ;^)

Jim Davis
Aug 28 '05 #29
Jim Davis wrote:
Richard Cornford wrote:
Jim Davis wrote:
Richard Cornford wrote: <snip> (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.
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.


Version 1.3 is pointless in a world where pre-version 1.3 browsers
are not used, and later versions exclude some of the older browsers
still in use where such exclusions are not necessarily justified.


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.

<snip> 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.
Aug 29 '05 #30
On Sat, 27 Aug 2005 15:42:04 -0400, "Jim Davis"
<ne********@vboston.com> wrote:
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:ac**********@hotpop.com...
but the former still has the best support
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.


but only some browsers support versions on the former even, the latter
can also have a version and other consider e4x in Mozilla.
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.
ECMAScript compliance has nothing to do with JavaScript1.3 as a
language attribute, indeed IE with JScript 5.6 despite being broadly
ECMAScript Ed.3 compliant which only JavaScript 1.5 does not support
JavaScript1.5 in the language attribute.
The marketing name
of the implementation doesn't affect it compatibility with the standard
name.
JavaScript1.5 is not a standard name!

[JavaScript1.3]You're code won't run on Netscape 2.0 but neither will you have to deal with
it's broken implementation.


It will however run on other inferior user agents and won't run on
many capable user agents...

Jim.
Aug 29 '05 #31
Lasse Reichstein Nielsen wrote:
I recommend only using the type attribute and using feature detection
for differences between different browsers.


Is there a way to detect for features like try/catch or get/set? Just
having these keywords in your javascript can break the javascript in
some browsers, even if they are not in that browsers code path (so it
breaks during parsing).

Not that I've been able to avoid that problem with the language
attribute ...

Kevin N.
Aug 29 '05 #32

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by S.Tobias | last post: by
reply views Thread by Chris Fink | last post: by
1 post views Thread by Rob Griffiths | last post: by
669 posts views Thread by Xah Lee | last post: by
5 posts views Thread by JH | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.