<script type.... <script language... etc...

[shlagish]

I saw many ways to start javascript in the header:
<script type="text/javascript">
<script language="JavaScript">
<script>
<script type="javascript:1.1"> (not sure for that one)

and more.

What is the GOOD way to start javascript in the header...
which whould I use?
For now, I'm using <script type="text/javascript">
but is it correct?

Also:
same problem for css:
<style type="text/css">
<style>
Which one is the GOOD one?

Thanks

[Vladdy]

There is no good or bad way to use element attributes, just the correct one.
See http://www.w3.org/TR/html4/ for details

[shlagish]

Thanks, I'll try checking out that whole site to make sure I'm doing the right thing :)

[jalarie]

It's a big site, shlagish, so:

&nbsp;http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.1

And a summary:

&nbsp;type=... (e.g., "text/javascript"). Authors must supply a value for this attribute. There is no default value for this attribute.

&nbsp;language=... Deprecated. 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.

I have found a place where I can't get around using the "language" attribute, and I may be getting wrong answers at times, but I use it to learn the JavaScript level:

&nbsp;<script&nbsp;language="JavaScript1.0">JSver='1.0'</script>
&nbsp;<script&nbsp;language="JavaScript1.1">JSver='1.1'</script>
&nbsp;<script&nbsp;language="JavaScript1.2">JSver='1.2'</script>
&nbsp;<script&nbsp;language="JavaScript1.3">JSver='1.3'</script>
&nbsp;<script&nbsp;language="JavaScript1.4">JSver='1.4'</script>
&nbsp;<script&nbsp;language="JavaScript1.5">JSver='1.5'</script>

[realisis]

jalarie: joh6nn once mentioned that same technique on a thread, and I've used it to good advantage once or twice...

However you might want to add one more to the list to reveal which browsers happen to ignore the language attribute:

<script language="JavaScript2.0">JSver=false</script>

using the above made me realize that webTV ignores the language attribute... and strangely, Opera identifies itself is JS1.4...

[beetle]

The only reason to know the version (and the whole purpose for the language attribute) is for sniffing/cloaking. If you're doing what you should be with your JS (object sniffing) then knowing the language version is irrelevant - part of the reason why it's deprecated.

[realisis]

"If you're doing what you should be with your JS (object sniffing) then knowing the language version is irrelevant - part of the reason why it's deprecated."

No, there are certain statements you can't sniff browsers out of, and that's where language comes in handy:

Try using a try/catch statement in a function and feed that script to Netscape 4, and you'll see what I mean.

Even if you use something like:

if (!document.layers)
{
try { /*statements*/ }
catch(error) { blip = error.toString() }
}

the browser will still throw an error - and the reason is because the syntax of try/catch is reserved in NS4. Even though that browser is excluded from executing the statement, it still parses it for errors at runtime.

...

similarly, you can't sniff out NS3 from a RegExp definition without getting an error. For eg, you couldn't use:

if (!window.RegExp) rx = /\d+/g;

NS3 will still parse the script at runtime, and will deliver an error as soon as it sees those forward slashes.

You *could* use:

rx = "/\d+/g"

if (window.RegExp) rx = eval(rx);

... and you'll safely bypass non RegExp browsers from seeing the definition. But some people don't like using stringcloaks, and anyway that particular workaround surely is surely NOT what you meant when referring to object sniffing.

... (edit: added the following item):

as a further example, you can easily sniff out browsers which don't handle replace() for example:

blip = "some string"
if (blip.replace) blip.replace("o","a");

beacuse the *syntax* in that statement doesn't represent anything NEW to the browser...

but you couldn't sniff out via:

if (blip.replace)blip.replace(/o/g, "a");

for the same reasons as previously explained.

[beetle]

Yes, fine - but for those cases you should sniff the navigator object - and not rely on the javascript langauge version.

language is deprecated. What else is there to say?

[realisis]

beetle I started typing my last addendum prior to your post appearing.

Sniffing for navigator is beside the point, and wouldn't snag me all the potential browsers that I want to exclude. And anyway, sniffing for navigator substitutes label for capability, and I'd avoid here for those reasons.

"language is deprecated. What else is there to say?"

Um, maybe something like "big deal"?

Beetle, you're discussing this with someone who has no qualms about putting deprecation aside when appropriate.

... "deprecated" isn't the same thing as "forbidden", except maybe to evangelists.

[beetle]

Isn't sniffing about excluding features, and not browsers?

Anyhow - of all the javascript coding I've done (ALOT), I've never found a case where I needed the language attribute to help.

:D

[realisis]

okay:

notrycatch = ((navigator.appName.toLowerCase() == "netscape") && (parseInt(navigator.appVersion) <= 4))?true :false

if (!notrycatch)
{
try { /*statements*/ }
catch(error) { blip = error.toString() }
}


how will this type of sniffing avoid the errors that I said would occur anyway?

how is this sniff different than the one in my original example?

[realisis]

"Isn't sniffing about excluding features, and not browsers?
"

well, that's exactly what you're recommending by suggesting a sniff based on navigator.

what I said: don't substitute label for capability.

[beetle]

Since IE doesn't implement Javascript, but rather JScript - I consider any sniffing towards a Javascript version to be unreliable.

Well, try...catch is Javascript 1.4 (according to what I've read) and JScript 5.0. So that means IE5.0+ and any browser that supports JS 1.4 (which is really any that supports 1.5). Using new features like that should only be done in a controlled environment - especially an exception handling construct.

And sure, why not sniff for the RegExp object? And instead of a string cloak, use it's constructor.

if (window.RegExp) rx = new RegExp( "\d+", "g" );

Is this not object sniffing?

And I never recommended sniffing navigator - but only said that using it is preferable to relying on sniffing the JS version.

[brothercake]

This thread is related http://www.codingforums.com/showthread.php?s=&threadid=15703

I should say though, since then I've changed my mind and stopped using the language attribute. I'm with beetle on this one now.

[realisis]

thanks brothercake: that thread was an interesting read. I see you espoused the same position I am now advancing, though you did it somewhat more succinctly.

But unlike yourself, I saw nothing in that thread to solve the problem I've advanced. Since you claim to have changed your mind on the language issue, maybe you would be good enough to suggest another workable solution to the try/catch quandary, since beetle is repeatedly and conspicuously avoiding that one, and hasn't proposed anything that will prevent the error.

These discussions are so predictable: I approach a technique from its possible utilitarian value, and find that the opposition is based instead on irrelevant political associations and an a priori prejudice against anything not ECMA-approved: "It is deprecated! ECMA has spoken! ECMA is infallible. You must conform!"

So much for open minds. I might as well be discussing vaccination with a quaker.

To think that the spectre of Political Correctness has invaded an activity as benign as javascripting would be hilarious were it not for the fact of the religious absolutism and uncritical groupthink that it exposes.

But (ahem) as beetle's signature says: minds are like parachutes.

...

btw beetle thanks for the RegExp constructor - more elegant than the stringcloak I had mentioned.

[zoobie]

<script type="text/javascript" language="english"> :D

[brothercake]

Originally posted by realisis
These discussions are so predictable: I approach a technique from its possible utilitarian value, and find that the opposition is based instead on irrelevant political associations and an a priori prejudice against anything not ECMA-approved: "It is deprecated! ECMA has spoken! ECMA is infallible. You must conform!"
Well no, not really - I read most of the threads on CF, and in most people's case their advocation of this point of view is rational and pointed - there are very good reasons why it's best not to use deprecated elements and attributes ... but ... well the reasons are complicated and time consuming to explain; forgive me if I can't be bothered to wait for everybody to catch up .. it's not my repsonsibility to allow for other people's false assumptions. Sorry - I just take it as read unless the premise is challenged (like now ;))

My experience (no offense intended) is that the minority of people who take your view - the view that we're advocating strict compliance for the sake of it or because of some irrational prejudice, are just looking for excuses not to adopt the paradigm - usually because they don't want to let go of their current working practise, take on board a new learning curve, or admit that they were wrong.


It has nothing to do with political correctness, geek chic, absolutism or anything else like that - it has everything to do with the bottom-line realities of professional web development, as much as it does the theoretical development of interoperable web standards. I can explain this in more explicit terms if you want.



Your try/catch situation is interesting - a variant of the syntax problem with netscape 3 mentioned in the other post - I can't see a way to get the solution you want without using the language attribute, but I feel about that the same way - it doesn't matter - on the basis that you know the script isn't going to work in ns4 and your site design/functionality takes account of that properly, then non-runtime JS error messages are not important - netscape 4 users do not have error reporting turned on; only developers have it turned on; the only negative you're going to see is that other developers might see your script and sneer at your lack of legacy error control. And WGAF what they think :rolleyes:

[beetle]

Well spoken, bcake. :thumbsup:

I suppose it all depends on which scenario you are after?

1) Promotion of language in favor of keeping the capability to sniff out the unsniffable, such as try...catch in NS3

2) Demotion of language in favor of adopting standards compliancy, and rely on alternate sniffing techniques where applicable

Sorry, I'm just a #2 guy. I'm looking foward - not back (certainly not back to NS3)

Besides -- if I'm really concerned about that sort of thing - would not the HTML commenting of scripting work? (not sure here) ie

<script type="text/javascript">
//<!--
var some = 'code';
//-->
</script>

Also - try...catch is nice - but its use is rarely warranted in Javascript. If I had to use it (and I have) I suppose I'd analyze how the script will be used, and decide at that point what needs to be done about it. I just happen to think that sniffing around a exception handling mechanism is ridiculous.

Never sacrifice for the many to benefit the few.

[beetle]

Originally posted by zoobie
<script type="text/javascript" language="english"> :D <script type="text/javascript" language="justamese&reg;"> :D

[Vladdy]

Applying some logic to the discussion.

Axiom 1:
Web site should work and be accessible without javascript

Derivative 1.1 (from Axiom 1):
The purpose of javascript is to enchance the presentation of content in capable browsers.

Axiom 2:
Web designer must eat

Derivative 1.2 (from Axiom 2):
Efficient coding is such that produces the most with least effort.

Derivative 2.0 (from 1.1 and 1.2):
If the browser does not have the set of objects/features/etc you are designing to, let it degrade as if there was no javascript at all.

Derivative 3.0 (from 2.0)
<script type="text/javascript">
function loadJS()
{ allFeaturesSuported = document.getElementById // && expand as needed
if(allFeatuersSupported)
{ js = document.createElement('script');
js.src = 'myBellsAndWhistles.js';
js.type = 'text/javascript';
document.getElementsByTagName('head')[0].appendChild(js);
}
}
</script>
</head>
<body onload="loadJS();">

;)

[realisis]

Thanks to the folks who have bothered to type out those long commentaries - interesting all of them. Before launching into my rebuttal, allow me a quick redux of the discussion so far:

1) I made a friendly rejoinder to jallarie about the use of language

2) beetle didn't like the fact that someone seemed to be promoting the language attribute, and jumped on it.

3) I responded, citing my rationale for using language in scripts "once or twice", and why I felt object-sniffing was insufficient in those cases

4) beetle and I had a few exchanges, and thereafter, others decided to comment on my perceived position

5) and now here we are:

***

"My experience (no offense intended) is that the minority of people who take your view - the view that we're advocating strict compliance for the sake of it or because of some irrational prejudice,"

No offense taken. And if even a single person were to say to me "don't use the language attribute in this situation" and then convinced me "here's something much better that will do what you want" then yes of course I would adopt it, and I would have no reason to think that person was motivated by irrational prejudice (nice phrase, brothercake).

But prior to my last post the only contribution I saw was essentially "don't use it - it's deprecated, that's all there is to it" ... with no attempt to suggest a concrete workable alternative. What else am I to think but that personal bias is involved?

***

"the minority of people who take your view (...) are just looking for excuses not to adopt the paradigm - usually because they don't want to let go of their current working practise, take on board a new learning curve, or admit that they were wrong."

Well, that doesn't apply here... You will note in my original post I mentioned using the language attrib only "once or twice". Fact is, I could care less about older browsers most of the time. And though I'm no standards purist, I'm willing to learn and use the ECMA DOM as much as any other approach, and have been doing just that.

However, after Beetle's objection to my original post, I've began arguing this point from a very particular perspective regarding a suite of analysis/troubleshooting modules I've been developing: these are expressly devoted to revealing a browser's entire DOM (or as much as a given browser is willing to enumerate). And part of my aim for this utility is that it be as universal as I can make it (if it worked only on generation 5 browsers, it'd be of much less heuristic value to me - and ultimately to any potential audience).

***

in case anyone needs background:

I implemented try/catch specifically to address a bug(?) in K-Meleon (v0.7, based on MOZ 1.2) - which otherwise throws errors (and completely hangs) on all the BarProps when you try to query them (and occasional similar problems have been encountered with IE5.5 on a isolated sub-objects of window). Implementing try/catch allows me to represent those errors as returned data (which is still useful), while letting the remainder of the script proceed without incident, which is paramount. I had already tried an onerror event-handler, but wasn't completely able to stop the errors in every case.

Having done that, I then realized the simple presence of try/catch was itself incurring errors in NS4 (etc), and that these statements could not be sniffed out for the reasons originally given. And so far the only solution I've found is to use the language attribute.

***

The fact that none of the present commentators who are contesting my perceived position has bothered to consider or even to ask "where I'm arguing from" is amusing. Instead I'm encountering a plethora of major assumptions and generalizations about what javascript is, who the intended market is, which forum of activity will be the means of transmission, etc...

***

Some examples:

From Vladdy:

Vladdy's Axiom1 ("Web site should work and be accessible without javascript") is irrelevant here. I'm designing a javascript utility on a meta level - the javascript requirement is built-in to the concept. His Derivative 1.1 is similarly irrelevant in this case. So is his Axiom 2 ("Web designer must eat"). Regarding Derivative 2.0 - I wonder how Vladdy came to decide I wasn't already attempting to have the script "degrade" gracefully? Another assumption.

***

From Beetle:

"1) Promotion of language in favor of keeping the capability"

I'm not expressly promoting the use of language. Merely making use of it, when no other avenue has presented itself to me in getting the behaviour I want from the script, globally speaking.

"2) ...and rely on alternate sniffing techniques where applicable"

Did you decide I wasn't already doing that? Trust me, almost all of my sniffing is object/capability based.

"If I had to use it (and I have) I suppose I'd analyze how the script will be used, and decide at that point what needs to be done about it."

Fine beetle. That's exactly what I did in the one or two cases where I have used language. If you had given me the benefit of the doubt also, or made any attempt at asking which alternatives I had considered or which context I was operating from, instead of jumping on my original post, we would not now be having this discussion.

"I just happen to think that sniffing around a exception handling mechanism is ridiculous."

Nice to know you've already considered every conceivable context in which it could be done, and why it would be ridiculous in absolutely every case.

"Never sacrifice for the many to benefit the few."

Another massive assumption. How on earth did you decide I was sacrificing anybody? And why load the alternative with a choice between populism and elitism?

"I'm looking foward - not back "

Well, in this one case I have to look back. Never occured to you to ask, huh?


***

From Brothercake:

"it doesn't matter - on the basis that you know the script isn't going to work in ns4 and your site design/functionality takes account of that properly, then non-runtime JS error messages are not important - netscape 4 users do not have error reporting turned on;"

Another assumption which doesn't apply here.

"it has everything to do with the bottom-line realities of professional web development,"

Again.

"well the reasons are complicated and time consuming to explain; forgive me if I can't be bothered to wait for everybody to catch up .. it's not my repsonsibility to allow for other people's false assumptions."

I think I'm feeling something exactly similar ;^]


***

Trust me guys, I've got loads of respect for your respective levels of knowledge and accomplishments - but I can't help feeling that this is another case of "jumping the gun" and projecting your crusades into what was originally a fairly innocuous comment. Hopefully after reading this post - you can see why.

Although Vladdy thank you for document.createElement('script'), and beetle, thanks for the "comments-within-script-"
idea - I'll look into these, when I no longer have to spend time composing polemics on this thread. ;^]

[Vladdy]

Originally posted by realisis
From Vladdy:

Vladdy's Axiom1 ("Web site should work and be accessible without javascript") is irrelevant here. I'm designing a javascript utility on a meta level - the javascript requirement is built-in to the concept. His Derivative 1.1 is similarly irrelevant in this case. So is his Axiom 2 ("Web designer must eat"). Regarding Derivative 2.0 - I wonder how Vladdy came to decide I wasn't already attempting to have the script "degrade" gracefully? Another assumption.
[/B]

We are talking about javascript which is component of a web browser which in turn is used to access data on the internet.
If you are designing a general purpose web site, then it should be accessible with non-javascript browsers, therefore javascript can not be used for essential functions. Since web site can function without javascript, you do not need to sniff for different javascript versions. If the implementation is not current, simply drop the javascript functionality and call it a graceful degradation. Designing separate code for every legacy browser is INEFFICIENT.
If you are designing some intranet service which functionality relies on client scripting, then you can require the set of tools that can be used. Once again, it is easier to say this application requires DOM compliant browser with Javascript enabled, than designing separate branches for every other possibility.

"Web designer must eat" is irrelevant only if you are designing something for your own amusement (which I called "mental mastrubation" in another thread :D :D :D ). In this case disregard my input as non-applicable. :thumbsup:

[beetle]

A very well written rebuttal, realisis. Let it be said that I originally rebuked the idea of using langauge because of jalarie's post - not yours. I understand how you thought my comments to be directed at you - but trust me, my comments existed for their own sake, and for the sake of the original poster.

That aside - I think we had a healthy debate - although I'm disturbed to see by your rebuttal it seems that you took some of this personally? Not sure - hard to tell from written text - but it certainly feels that way ("If you had given me the benefit of the doubt..."). Remember - I'm not arguing with you - just language. And, I think I mostly agreed with the very rare cases when I said

If I had to use it (and I have) I suppose I'd analyze how the script will be used, and decide at that point what needs to be done about it.
Example - the last time I used it, the statement was already pretty far into a script that had already sniffed away browsers that wouldn't support it - so worrying about it was a non-issue. Oh - and I've never appeased NS4 - not even 3 years ago - just something I don't do.

Nice to know you've already considered every conceivable context in which it could be done, and why it would be ridiculous in absolutely every case.
Oh, come on now. Even the well-educated such as yourself should know that this type of clarivoyance rarely (never?) exists. I'd have to be in your shoes doing what you're doing to know that - and I'm not. I'm speaking generally.

And you're right, it never occured to me to ask - and it's clear from your recent statement...if it worked only on generation 5 browsers, it'd be of much less heuristic value to me - and ultimately to any potential audience...that you are looking back - and that's fine. I personally think it's a waste of time - but that is my point-of-view, not yours.

Heuristic value? Sure - you got that.
Value to a potential audience? Not so sure - this is where my "sacrifice" comment would apply.

Let me know if the script comenting works - becuase I never had a suitable environment to test it.

Afterthought: Just by composing your polemic, does it not seem you are just as interested in promoting your crusade as we are ours? :p

[whammy]

I haven't had any problems with:

<script type="text/javascript">
<!--

// -->
</script>

Except in XHTML 1.0 Strict which apparently wants the language attribute - which is also deprecated in XHTML 1.X...

Anyway, it works... even in Netscape 4.7x which is as far back as I care to go!

[whammy]

P.S. I can also relate with the pain (and frustration) of having to code for browsers that are either old (I don't care anymore about NS 4.x) or non-compliant (see Microsoft to start with).

Just the CSS incompatibilities and differences are enough to drive one insane - let alone javascript. ;)

[realisis]

Hi beetle, thanks for the response. Also for the compliment.

"but trust me, my comments existed for their own sake, and for the sake of the original poster."

Point granted. No problem.

***

"Let it be said that I originally rebuked the idea of using langauge because of jalarie's post - not yours."

No that wasn't obvious to me - not your fault though - now that I reread the sequence of posts. Although obviously by your second post, we had got a direct conversation going, but that's another thing.

***

That aside - I think we had a healthy debate - although I'm disturbed to see by your rebuttal it seems that you took some of this personally? Not sure - hard to tell from written text - but it certainly feels that way ("If you had given me the benefit of the doubt...").

beetle, Yes it was/is a healthy debate... and no, nothing was taken personally - there were no flames, or outright smears... and as far as I can see, we both kept our arguments within conceptual bounds, and certainly there was no invective - so no real problem. It's just after a certain point in a debate my antennae go way up, and I jump into a mode where very word has weight - just sharpening my teeth ;^]. Anyway, what I meant by saying "given me benefit of doubt" is covered by similar point in next item.


***

"Oh, come on now. Even the well-educated such as yourself should know that this type of clarivoyance rarely (never?) exists. I'd have to be in your shoes doing what you're doing to know that - and I'm not. "

Er, that was exactly my point... If you admit that exceptions to a given rule exist, and you haven't ascertained whether those exceptions apply in the present situation - rather than the rule - why raise objections based on the rule? The Zen of Exception handling, eh? ;^] Since you weren't in my shoes, how could you decide ahead of time? And why risk embarassing yourself like that?

Well, that was my point at the time - I'm stating it more baldly here perhaps, but only to explain my use of irony the first time around - no offense intended here.


***

Afterthought: Just by composing your polemic, does it not seem you are just as interested in promoting your crusade as we are ours?

Whoa! Everybody likes to state their case. But you've gotta consider the etiology of the discussion: there is a difference between promoting your crusade by challenging other people (who weren't necessarily or originally addressing you), and advancing an argument in self-defense because somebody else is already challenging you.

This is probably an assinine and ridiculous analogy, but I can't think of a better one at the moment:

Imagine a party (this forum). Stranger A is talking to someone. Stranger B walks up to Stranger A and says "Hey man, you've got long hair. Look around you man: haven't you noticed? Long hair isn't cool anymore. Why don't you cut it?"

So a discussion ensues (or argument in that case, more likely). Both A + B make alternating statements, with A defending his (anyone's) right to have long hair, and B contesting it.

Yes everybody has a right to be in the room. Yes everybody has the right to make comments and partake in a discussion. And at this point both A and B are taking normative positions (ie "promoting a crusade" as you phrased it).

But note that "A" wasn't originally specifically crusading for anything, he was just matter-of-factly talking to someone - maybe he was even talking about hair (maybe even the party is a convention of hair-dressers ;^] and maybe they're even SUPPOSED to talk about hair). But - and this is important - "A" wasn't challenging or contesting anything or anyone. Whereas B obviously is.

So who's the one with the crusade?

[realisis]

AND

Vladdy, you have the gift of reading without being sidetracked by understanding. Every proposition (read: arbitrary assumption) in your first paragraph was already precluded or covered in my existing rebuttal.

As for your second paragraph - it was entirely gratuitous:

"Web designer must eat" is irrelevant only if you are designing something for your own amusement (which I called "mental mastrubation" in another thread ). In this case disregard my input as non-applicable.

Note the word "only". Nice false dichotomy here - let me see if I got the insinuation right:

Vladdy's Postulate 1A:

there are two - and only two - motivations for (my or anyone else?) doing web-design:

1) you must eat (pecuniary rewards and/or existential prolongation)

- OR -

2) mental-masturbation: which is equated with "amusement" - you know, jerking-off just for superficial ego-gratification, or maybe just to kill time.

And if it's true of web-design, well gee, by inference it must also be true of tennis, yoga, writing novels, adult education, playing the banjo and long-distance running and molecular physics - ad ridiculum. You're either trying to make money off of it, or you're just jerking off.

No mention or concept of motivation by research, or of expanding one's knowledge and understanding of an activity, or as a practical step towards a further goal, nor even the simple aesthetic drive or healthy joy at creating something useful and educational and worthwhile. Nice omissions there Vladdy - and if you think any single one of those equate to merely a form of "amusement" - let alone "mental masturbation" - you're more of a hedonist than you know. Quite a revealing character profile.

And lo! Since I had already declared that "web-designer must eat" was irrelevant to me, your ingenuous false-dichotomy conveniently slots me in the "mental masturbation" category. Golly I never saw it coming! Nice try.

"In this case disregard my input as non-applicable."

Well, although I'm really not the one who's masturbating here, I'll take your suggestion anyway and disregard your input as non-applicable. Again.

[beetle]

Originally posted by realisis
So who's the one with the crusade? Uhhh, I guess everyone but you, then. :p

[liorean]

Hmm, seems I came into this too late...

Why don't you use window.onerror to catch and suppress errors in nn4 specifically, and continue to use the script without the language attribute?


On another note, nn4 is the only non-fifth-generation JavaScript browser still used by the general public, with the possible exceptions of ow (omniweb) and op3-6. Both op and ow, however, have support for try...catch and window.onerror.



Another thing I noted is one of little importance to the discussions in this thread, but still:

ECMA standardises ECMAScript, the core features of JavaScript. How and what host objects are implemented and what HTML you use to include the script is not of their business. They never tell you how you should do it, they ONLY tell the implementors how to do it.

W3C on the other hand, have both best-practice and pure standardising documents. They are the ones who standardise the DOM, not ECMA (you mention ECMA DOM there once).

[realisis]

liorean thanks for your suggestions:

Well, I already have an onerror implemented (NS4 included) for other potential "one-time" errors, but:

Note that I specifically DO NOT want to actually suppress any errors with this utility (it is partly after all, a troubleshooting utility) - it is important that if any data is unable to be read, that the associated error be reported instead.

However if I were to expand onerror to actually include the try/catch, then fine: NS4 loads utility, NS4 generates error, onerror catches the error... but ... doesn't the browser still refuse to implement or parse any remainder of the script? (guess I should test this out)

Or: if every single time my functions are called (which is every time the user wants to pursue a specific sub-object when analyzing an HTML document), wouldn't NS4 still throw a new error for the try/catch? Hmmm, on second thought, that doesn't seem likely - but I guess I should test this out once again.

However here's something more problematic (and I can already hear the sniggers, the outrage, the apoplectic cries of "HERETIC! KILL HIM!!" from the villagers): I know that with this utility I will never be able to include Javascript 1.0 browsers (NS2 and contemporaries) - and that's okay - I don't feel a great loss there - but I've recently been able to incorporate basic coverage for NS3.0 with a few minor changes to the scripts - which in itself has taught me a great deal about exception handling for older browsers. And with this utility I 've been able to reveal most of its DOM (what little there is of it) so that's of interest to me, for historical purposes.

But as you know NS3 does not implement the onerror event-handler. So in the normal course of things, I can only hope that NS3 never generates an error, but if I take away the "language " cloak (or other viable alternatives yet to be investigated), that certainly won't be the case, cuz the browser will just refuse to load the utility after encountering try/catch.

***
On another note, nn4 is the only non-fifth-generation JavaScript browser still used by the general public, with the possible exceptions of ow (omniweb) and op3-6. Both op and ow, however, have support for try...catch and window.onerror.

OP6 and 7 are already covered - no primary script issues there (but haven't tried 3-5). Omniweb I'm really not familiar with, but will investigate.

***
ECMA standardises ECMAScript, the core features of JavaScript. How and what host objects are implemented and what HTML you use to include the script is not of their business. They never tell you how you should do it, they ONLY tell the implementors how to do it.

Sorry - you are quite right. It's the evangelists on public message boards who walk around telling others "how you should do it". #8'0

***
W3C on the other hand, have both best-practice and pure standardising documents. They are the ones who standardise the DOM, not ECMA (you mention ECMA DOM there once).

Again my inaccuracy - point taken.


Thanks again for your contribution.

Cheers -

[beetle]

Hey realisis - don't know if you've been here (http://browsers.evolt.org) or not - but it may help you on your "quest" ;)

Of course - you've got alot of work ahead of you if you want to test all of them. :p

[realisis]

thanks beetle... btw "quest" is definitely the right word, in fact let's make it Quest.

Yeah I go to evolt every once in a while and see if there's anything new or anything I missed...

I think NS3 is as far back as I care to (or can) go.

And incredibly, IE < 5 doesn't respond to the for(in) loop, which is sad, cuz originally I was really hoping to integrate v4 at some point.

... and still haven't yet had time to experiment with the various suggestions raised on this thread!

[beetle]

Of course, of all the browsers there, how far back you go is less relevant than what breadth you intend to conquer :p

[brothercake]

And anyway size is not as important as quality ;)

Personally, I have a cutoff point with CSS: 5+ graphical browsers get the fully styled layout, everything else gets no CSS - and the plain semantic layout works all the way back to text only, which means you don't have to test them all.

[whammy]

I like your approach, brothercake... all or nothing.

;)

[joh6nn]

my particular preference has already been noted above, so i just thought i'd mention my reasons for using the meta tag, as opposed to any of the others

first, as far as i know, the meta tag is supported by most of the major browsers, as far back as version 3. if anyone knows otherwise, please tell me

second, i think that it sort of falls in with the principle of separating style and content. i like having <script> much more than i like having <script language="javascript">; it keeps things much simpler, i feel.

also, i support standards, but sometimes they just don't work the way we'd like. The CSS box model is a great example, and if like realisis, you're trying to get your code to work in as many browsers as possible, with as little effort as possible, then the standards can actually work against you, as the deprecation of the language attribute shows.

personally, i found that most of the time, i could get around using the language attribute. which was great, because it was an absolute terror to use; it promotes clutter, and repetition of code, which are even better reasons to evangelize against it than deprecation.

all that i really wanted to say, though, was this:

Originally posted by realisis
... I can already hear the sniggers, the outrage, the apoplectic cries of "HERETIC! KILL HIM!!" from the villagers ....

/me clears his throat

ahem:

Thou vilest heretic! Have at thee, and off with your head!

...he turned me into a newt, he did

[MotherNatrsSon]

I have Deamweaver 4 and in it is OReilly's HTML Reference. Here is the suggestion from that....

"An important shift in atribute syntax is introduced in HTML 4.0. To specify the scripting language of the statements within a SCRIPT element, the LANGUAGE attribute has been used since the first scriptable browsers. HTML 4.0 deprecates that attribute in favor of the TYPE attribute, whose value is a MIME type. When the TYPE attribute is widely adopted by vrowsers, you may want to include both attributes in documents for long term backward compatibility with older browsers.

Newer browsers also allow script statements to be imported into the document from a document whose URL is specified for the SRC attribute. Older non scriptable browsers do not recognize the SCRIPT element and may attempt to render the script statements as regu;ar HTML content. To prevent this, wrap the script statements inside HTML block comment markers The end-of-comment marker(-->) must be preceded by a JavaScript comment marker(//) to prevent JavaScript from generating a script error.

IE recognizes four case insensitive language names: JavaScript, JScript, VBS, VBSScript. Navigator only recognizes JAVASCRIPT. The versionless JAVASCRIPT is recognized by all browsers.......when SCRIPT elements are assihned these later version values, older browsers that do not support the named version ignore the SCRIPT elements."


USE BOTH FOR CROSS BROWSER ACCESABILITY...NEVERMIND THE W3C

MNS

edit:

And for all you "bleeding edge" folks out there. There are WAY more people on the web using older browsers like NS4x and IE 5x than there are using the "latest, fastest, newest" browsers.......If you do not design to incorporate older vrowsers, you aren't doing yer job...imho

pss.... I jus tried validating a page at W3C and it failed because in HTML 3.2 it would not accept either atribute or element or combination of them I could come up with....SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript"

[brothercake]

Originally posted by MotherNatrsSon
And for all you "bleeding edge" folks out there. There are WAY more people on the web using older browsers like NS4x and IE 5x than there are using the "latest, fastest, newest" browsers.......If you do not design to incorporate older vrowsers, you aren't doing yer job...imho
No there aren't - check out google zetigeist (http://www.google.com/press/zeitgeist.html) and you'll find that 4-version browsers are barely a blip. IE5 yeah, but that counts as a modern browser in my book.

And anyway that isn't the point. Nobody said stop supporting those browsers - I simply advocate not providing them with rich content - they get plain, unstyled semantic XHTML which is perfectly accessible, navigable and comprehensible; it may not look as nice, but that doesn't matter - not if you have to tie yourself in to the vicious circle of vendor- and platform-specific tag-soup for another five years.

You wanna talk about professional responsibility, well imho our responsibility is to the standards, not to the parochial commercial interests of browser vendors. We try to make the standards work, even though they're very far from perfect, because they're the best hope we have for a way out of this nightmare.

[MotherNatrsSon]

I just dread the day when the W3C gif HAS to be on your page for a search engine to recognize it or a server to put it on the web.

As far as "older" browsers go, who made google an authority? Anyone on a MAC that does not have OS 9 or 10 is using NS4 or IE 5. From a "design" point of view, I guess I do not understand the need for the complexities. Huge PhP or MySQL database driven sites do not seem very "user friendly". If your site has that many pages and that much information on it, what are the odds that any one person is ever going to attempt to read it all let alone find what info they need from your site?

Back to topic: Which tag is going to pass "the standards"? Script Type=text/javascript or SCRIPT LANGUAGE=JAVASCRIPT

[brothercake]

<script type="text/javascript"> is the correct way - the way that will pass validation.

I suggested Google because of its representativeness- it's not a case of authority because those figures aren't compiled manually, they're everyone who uses Google, which is near-as-dammit everyone who uses the internet.

[beetle]

MotherNatrsSon - brothercake is right

The older browsers are definitely a minority. Okay, granted that those without OS9 or 10 use NS4 maybe - but Mac users compromise a very small percentage of the browsing audience (generally speaking)

If you don't trust google's numbers - here's another source (www.thecounter.com) that shows a similar trend.

My website is of the flavor he describes - newer browsers get the fancy looks AND the content - older browsers (even text readers) get just the content. New browser users get the fanciness and I don't compromise everyone else in the process - that is how it should be.

[MotherNatrsSon]

Will older browsers read <script type="text/javascript">???

Ok. I have stats n my site too.

Mozilla/1.xx
Mozilla/2.xx
Mozilla/3.xx
Mozilla/4.xx 85 5.7 %
Mozilla/5.xx 1388 94.2 %

IE versions

Versions Hits Percent
MSIE/1.xx
MSIE/2.xx
MSIE/3.xx
MSIE/4.xx 8 0.1 %
MSIE/5.xx 1213 28.1 %
MSIE/6.xx 3089 71.6 %

Those are from yesterday.

Which browser that is currently available is most "standards compliant"?

The W3C site is an example of overly huge and not user friendly site. I couldn't find just a list of code tags for HTML 3.2 I gotr tired of looking and the techno speak really makes it difficult to understand a majority of it for me. I am on the other end of accesability it seems. What it means to me is that anyone should be able to put pages up and have them work, rathersimply. Instead of making things more and more complex, why not go the other way and make it simpler and easier for everyone? Part of the reason I am doing my site myself is that my business would not support paying someone to do it for me. K.I.S.S., you know, keep it simple stupid. :D



MNS

[brothercake]

Exactly.

And what we're showing you is the simplest way - back to basics; back to the semantic language that HTML was always intended to be.