The language and type attributes on <script> tags

Using the language= attribute

[BlobFisk]

Hi all,

I've noticed that some people still advocate leaving the language= attribute in on <script> tags. I totally omit it, using just the type= attribute. Everyone agrees that the language tag is deprecated, but many still seem to favour leaving the language in for old versions of NN4.

I've tested script and style calls on NN4.7 (nothing earlier though) using only the type attribute, and everything works fine. Any stats I look at (my own and those available online) show NN4.x at ~2% and I image most of these are NN4.7.

I'd be interested in hearing from people who still retain the language= attribute (in conjunction with type=) and their reasons for doing so. Do you do this for all sites, or just for sites that you expect to see a high number of NN4.x users?

[BlobFisk]

The point of the language tag is one that I've been thinking a lot about of late, but in relation to a much bigger picture. It extends to a more broad "how far do we go to support older browsers?" issue.

While we all try to be as standards compliant as possible, there generally comes the time when, against all our better judgement, we have to hack our code to make it acceptable to NN4.x! We can then sit back and watch validation flying past us, out the window!

But what it means is that in time to come when newer browsers stop supporting deprecated tags, we are at an impasse. Our code works in older browsers but not newer browsers! The reverse of what we have today!

How far away are we from this? IE6 has quirks mode, a possible stepping stone along the way. Maybe harping on about the language tag was not a good way to start, there are many other examples - but the fact remains the same. Many of us can expend a lot of time an energy trying to support a small percentage of older browser users (depending on market/audience of course), but this may well come back to haunt us in the future...

[tedster]

The use of comment tags to "hide from older browsers" is another remnant than can just vanish with no downside that I know of. Of course, comments are forward compatible, so it's no biggie, just code bloat.

[ShawnR]

A few random thoughts, not leading to any conclusion one way or the other:

"...Do you do this for all sites, or just for sites that you expect to see a high number of NN4.x users?..."

In general, I try to support NN4.7. Even though the stats show it as pretty low, 2% of the web population is still pretty large. Also, some corporates still have it as their mandated standard desktop environment. A case in point is Morgan Stanley, I understand.

I wouldn't try to support earlier than NN4.7, but if someone on this board asks for advice in debugging a problem with earlier, then I'd try and help if I can, hence in that context I'd be included in the "... some people ..." (msg #1).

It may well be that the reason NN4.7 is dying such a slow painful death despite being such a buggy browser is exactly the things that BlobFisk describes. For example, corporate Intranets having legacy applications which rely on quirks of old browsers.

"...comment tags to "hide from older browsers" ... can just vanish..."

I think hiding with comments is really ugly, makes code hard to read (particularly in a syntax-highlighting editor), and only protects you from one generation of browser updates. Instead, I think browser vendors should be lobbied to ensure taht the browser degrades gracefully... That if they come across a tag, attrib, etc they don't understand, they ignore it, so that hiding with comments aren't required.

"...IE6 has quirks mode..."

I'm in favour of an open, standards-based industry. However, I think quirks are a necesary part of progress. We find it painful because the web is so pervasive, but other well-respected languages do it too. For example, perl has many features yet to be documented, because those features are in the experimental stage. There needs to be some mechanism to see if something would be a useful feature or not. It is a pity that this mechanism is also used to capture browser market share, but all that means is that the 'quirks' are features that both developers and users find useful, hence should make their way into the standard. Historically the standards bodies have had difficulty keeping pace... Committees take much longer to update a standard than developer's R&D departments take to canvas users (web developers) and implement new features. That is part of progress. Standard bodies shouldn't mandate things just based on theory, without understanding if it would work in practice, so this form of experimentation is neccesary.

"...Many of us can expend a lot of time an energy trying to support a small percentage of older browser users..."

For me that is part of the fun and engineering challenge. And with new media such as PDA's coming out, it is only going to become more fun and challenging

"...when newer browsers stop supporting deprecated tags..."

I think that if that day should come, it will be a sad day indeed. The standard should mandate backward support. Obviously not for quirks which never made it into a standard, but for older standards-compliant features. The code should generate warnings if you try to validate it, but it should still be legal. I don't know any language that is not backward compatible. I'm pretty certain that a really old C program (ala the original K&R spec) will compile on the newest C++ compiler, let alone an Ansi C compiler.

Shawn

[pageoneresults]

From the W3C...

Language: This attribute specifies the scripting language of the contents of this element. Its value is an identifier for the language, but since these identifiers are not standard, this attribute has been deprecated in favor of type.

From the WDG...

In the absence of the LANGUAGE attribute, browsers that do not support the TYPE attribute typically assume that the language is the highest version of JavaScript supported by the browser. Thus authors may safely omit the deprecated LANGUAGE attribute when using JavaScript.

One would assume that there is no longer a need for the language attribute based on current information from the above resources. I've been using <script type="text/javascript" src="file.js"></script> since first seeing the discussions here pertaining to the deprecated language attribute.

[grahamstewart]

However, I think quirks are a necesary part of progress.... 'quirks' are features that both developers and users find useful, hence should make their way into the standard.

Can't help thinking that your mis-representing the 'quirks' mode a little here.

Quirks mode is not a way for Microsoft et al to try out cool new features and push the boundaries of the standard. It's a basically just a way to emulate the bugs in earlier versions of the browser, so that our old (non-standard) html renders the same as it used to.

Microsoft calls this mode 'compatability' mode and says this about it..

When Internet Explorer 6 or later is not in standards-compliant mode, it is in compatibility mode. If you developed applications for earlier versions of Internet Explorer and you want the applications to render the same way on Internet Explorer 6 or later, make sure the!DOCTYPE declaration doesn't switch on standards-compliant mode.

In standards-compliant mode, compatibility with other versions of Internet Explorer is not guaranteed. When standards-compliant mode is switched on, the rendering behavior of documents might differ in future versions of Internet Explorer. You should not use this mode for content that is fixed in nature, such as content that is stored on a CD.

See [msdn.microsoft.com...] for more info.

[ShawnR]

"...Can't help thinking that your mis-representing the 'quirks' mode a little here..."

Yes, you are probably right. I may not be using the correct terminology (and even if I do, I suspect my position will be controversial). I don't mean bugs in rendering. I mean features that may or may not become popular, hence may or may not make their way into the standard. Examples that come to mind are the ability to colour the scroll bars, or the marquee tag.

Shawn

[grahamstewart]

Yeah, those kind of things (proprietary browser extensions) seem to work regardless of whether you are in 'quirks' or 'standards-compliant' mode. (I just tested it - marquee works in HTML4.01 Strict :))

In general, I try to support NN4.7. Even though the stats show it as pretty low, 2% of the web population is still pretty large.

Do you also still write specific code for Opera 3.0, Mosaic 3.0 and IE4?
They also date from 1997 and together they probably account for around 2% as well.

I just don't see the point - I'd rather just bump them on to an 'upgrade your browser fool' page and get on with my life.

[ShawnR]

"...Do you also still write specific code for Opera 3.0, Mosaic 3.0 and IE4?
They also date from 1997 and together they probably account for around 2% as well. ..."

No, although I try to write code so that it degrades OK no matter what browser (And don't look at my profile... You know the story about how the cobler's son goes without shoes... Well, that is my excuse and I'm sticking to it ;) )

Part of my reasoning is that NN4.7 is still mandated standard desktop environment for some large corporates. My gut feel tells me that the Opera 3.0, Mosaic 3.0 and IE4 users are home users (plus a few web developers using these browsers to test ;) ) I figure it is easy for a home user to upgrade once they understand that their browser is out of date. It is not as easy in a large corp. (BTW, stats I have seen don't position these 3 combined anywhere near 2%)

I agree that my reasoning might not sound 100% logical. For example, I test with Opera and Mosaic (latest version), but most stats I have seen place them at less than 0.5% each, whereas I don't bother testing using the AOL version of IE, yet AOL has quite a following. Yet, despite this not being 100% logical, my guess is that most web developers are the same: test against latest versions of Opera, Mosaic, even though they are at 0.5%, and don't stoop to test against AOL.

Shawn

[DrDoc]

Of course, comments are forward compatible, so it's no biggie, just code bloat.

Actually, comments are a biggie!

Try this in NN7 or so and you'll see what I mean ;)

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-type" content="text/html;charset=ISO-8859-1" />
<meta http-equiv="Content-language" content="en" />
<title>Testing</title>
<style type="text/css">
<!--
body {
font-size: 500%;
}
//-->
</style>
</head>
<body>
Test
</body>
</html>

[tedster]

I tried it in NN7, and it is rendered the same with or without the comment tags. What is it that you're pointing to?

[BlobFisk]

the reason NN4.7 is dying such a slow painful death despite being such a buggy browser

That's a very good point. NN4.x seems to be hanging on in there for dear life. Other browsers have dropped off the radar, but it keeps hanging on in there.

Do you also still write specific code for Opera 3.0, Mosaic 3.0 and IE4?
They also date from 1997 and together they probably account for around 2% as well.

Not when I don't have to! The client (most of the time) dictates this. But, I have to say that NN4.x does crop up every now and again (industry depending), but I.ve yet to see Opera 3.0 and Mosaic 3.0 in logs, although IE 4.0 does crop up every now and again.

I just don't see the point - I'd rather just bump them on to an 'upgrade your browser fool' page and get on with my life.

Again, I have to say that I don't think that this works on an eCommerce site. You can't really afford to alienate customers .... having said that, on any of the eCommerce site log files I look at, old browsers just don't feature (NN4.x cropping up now and again).

[grahamstewart]

I have to say that I don't think that this works on an eCommerce site. You can't really afford to alienate customers

I agree its never good to alienate cutomers. :)

But in my experience compatability with NN4 comes at a price. Producing pages that are NN4 compatible, standards compliant [validator.w3.org] (HTML4.01 Strict and CSS1), which pass Bobby accessibility tests [bobby.watchfire.com], are well optimised for search engines [searchengineworld.com], and actually look nice, is a near impossible task.

Something in this equation has to give. All too often I have seen developers sacrifice one of these factors in favour of NN4.

What we need to realise is that this also alienates our customers:

New browsers may have trouble rendering non-standard code (especially browsers on limited platforms like phones and PDAs) - alienating the net-savvy trendy young things (who in many cases could be your best customers).

Screen readers and other accessibilty tools may not read the site correctly - alienating the 'impaired' market.

Bad SEO means you alienate passing trade.

And no-one is impressed with a site with a clunky design - regardless of its compatability with decrepit browsers.

I realise that many of us are forced into producing sites that are NN4 compatible by our customers. When this situation arises I have this discussion with them.

No one has yet insisted on NN4, but if they did then I would probably rather spend my time producing a second cut-down compatability version of the site than crowbarring my design into a broken browser. :)

[DrDoc]

>> tedster

C.4. Embedded Style Sheets and Scripts [w3.org]
Use external style sheets if your style sheet uses < or & or ]]> or --. Use external scripts if your script uses < or & or ]]> or --. Note that XML parsers are permitted to silently remove the contents of comments. Therefore, the historical practice of "hiding" scripts and style sheets within "comments" to make the documents backward compatible is likely to not work as expected in XML-based user agents.

I could have sworn that the comments would cause issues in NN7. Either way, it does in some browsers... (Maybe it was NN6 even.)

Quite a few posts in the CSS forum have been related to this problem.