XHTML and JavaScript

[edgework]

I don't wish to cross-post, but my problem seems to be a combination of JavaScript and XHTML. I had a drop-down menu that worked well in it's original form, but which turned buggy as week-old fruit when I reworked my pages to validate as XHTML Transitional. If anyone well-versed in the subtleties of scripting with XHTML would care to check out my post on the JavaScript Forum, it can be found under the title "Script Fails In IE Mac."

Any observations would be greatly appreciated. I'm clearly in over my head.

Thanks.

[Grant Palin]

Keep in mind that in XHTML, javascript event handlers are ALL lowercase. So onClick becomes onclick, etc.

[edgework]

I knew about that and believe that I adjusted the relevant ones. None of the actual xhtml code that I'm dealing with is in the page proper; it's all written to the page from a javascript command. I'll double check it, however, and see what I might have missed.

[brothercake]

The most common cause of a script failing on an XHTML page that I've seen is like this example:

myObj.style.top = 10;

This would fail on an XHTML page because the top position of an object is a string, not a number. It should be:

myObj.style.top = "10px";

Look out for things like that.

[Alex Vincent]

http://www.codingforums.com/showthread.php?s=&threadid=15664 is the thread in question.

Commentary, looking at the source code:
<script language="JavaScript" type="text/JavaScript">

The mime-type is lowercase.

type="text/javascript"

In Netscape 6+ and Mozilla, onfocus="blur()" is known not to work. This is a known bug, not yet fixed.

[Grant Palin]

Also, drop the language="Javascript". It's not needed in XHTML.

[brothercake]

Originally posted by Alex Vincent
In Netscape 6+ and Mozilla, onfocus="blur()" is known not to work. This is a known bug, not yet fixed.

Let's hope it never is, eh ;)

[Alex Vincent]

Originally posted by Grant Palin
Also, drop the language="Javascript". It's not needed in XHTML.

It's allowed in XHTML 1.0 Transitional specifically for compatibility with older browsers. In XHTML 1.0 Strict, XHTML 1.1 and the proposed XHTML 2, it is not allowed.

[WA]

Just wondering, without the language attribute, how do you make your script downgrade friendly with older browsers? For example, your script may utilize features of JavaScript1.2 you wish older browsers to ignore. In the past the easiest way would simply be to use the tag:

<script language="JavaScript1.2">

Thanks,

[Roy Sinclair]

Originally posted by WA
Just wondering, without the language attribute, how do you make your script downgrade friendly with older browsers? For example, your script may utilize features of JavaScript1.2 you wish older browsers to ignore. In the past the easiest way would simply be to use the tag:

<script language="JavaScript1.2">

Thanks,

If the browsers are that far downlevel the user needs to upgrade. Javascript 1.2 is very ancient history by now, it's a very rare or very poor browser that doesn't support it.

[brothercake]

Originally posted by Roy Sinclair
If the browsers are that far downlevel the user needs to upgrade. Javascript 1.2 is very ancient history by now, it's a very rare or very poor browser that doesn't support it.

That's not the point; the language attribute prevents those early browsers from running scripts they can't handle; sometimes the mere presence of code within a script element can create errors, if it refers to an unsupported method, even if that method is never called.

Remember that you normally have no influence over which browser your visitors use; nor should you try to have - "please upgrade your browser" is IMO as meaningless as a road-sign saying "please use a different car"

I'd second WA's question - how to acheive this downgrading without language. Personally, this exact issue is *the only major barrier* to my using valid XHTML Strict for everything (at the moment, I keep the attribute and ignore the validator warning)

[Roy Sinclair]

Since you convinced me there's a need for detecting downlevel javascript support. Try using object detection techniques, look to see if functions that were added to the later version are present, if they aren't present then you have a downlevel version and can handle it accordingly.

[brothercake]

Well yeah, that's usually enough; but it doesn't answer this one:

Originally posted by brothercake
sometimes the mere presence of code within a script element can create errors, if it refers to an unsupported method, even if that method is never called.

I remember this happening in netscape 3; I've adopted the generalised use of "javascript1.2" for all 4+ scripting ever since. I'll see if I can dig out a "working" example.

[WA]

To cite an example of the problem regarding the type attribute, I'm writing a script that uses literal arrays, ie:

var myarray=[1, 2, 3]

Without the language attribute, I would need to add an extra if statement around the arrrays, which looks really messy.

[brothercake]

Originally posted by WA
a script that uses literal arrays

Yup - that's the same example I just found. But it's worse than that:


<script type="text/javascript">

if(typeof document.createElement!="undefined") { var myarray=[1,2,3]; }

</script>


This still generates an error in netscape 3; doesn't matter what the condition says, ns3 barfs at the syntax.

[liorean]

Originally posted by WA
Just wondering, without the language attribute, how do you make your script downgrade friendly with older browsers? For example, your script may utilize features of JavaScript1.2 you wish older browsers to ignore. In the past the easiest way would simply be to use the tag:

<script language="JavaScript1.2">

Thanks,

Well, that's handled by a version parameter to the Content-Type http header OR something like this <script type="text/javascript;version=1.2">.



Oh, and as for the reason to use 1.2, if you use just ordinary javascript, the changes that netscape did won't kick in. For example, if you use 1.2 and use new Array(2), you get the equivalent to [2] instead of an array containing two (undefined) elements.

[brothercake]

Originally posted by liorean
Well, that's handled by a version parameter to the Content-Type http header OR something like this <script type="text/javascript;version=1.2">.

Doesn't help :( Sure - that identifies to the interpretor what language version you're using, but that's not the purpose of it here - the purpose is a way of telling legacy browsers "this is a language you don't understand, so don't even send it to the interpretor".

I've found some more examples; anything that looks like:

window.onload = function () {

or

SomeObject.prototype.someMethod= function () {

and also regular expressions

var str = str.replace(/xxx/ig,'');


All of these create errors if there's no language attribute.

Any other ideas? I suppose we could go

<script type="text/javascript" src="selector.js"></script>

and then inside selector.js, go

if(supported DOM browser) { document.write('<script ... ');

But it's a bit of hack - it adds an unecessary server request, which slows things down.

[liorean]

Originally posted by brothercake
Sure - that identifies to the interpretor what language version you're using, but that's not the purpose of it here - the purpose is a way of telling legacy browsers "this is a language you don't understand, so don't even send it to the interpretor".


Well, the real world and the world of standards doesn't match on this... Correct MIME-type handling is lacking in the browser world, though it predates even Netscape Navigator. If browsers (among them the notorious mime-type ignorer IE) did have correct mime-type handling, this method would work.

The language attribute of the script tag is of course widely supported, while the newer type attribute is less so. Even less supported than correct MIME-type handling via Content-Type header.


In fact browsers shouldn't try to run scripts with a type attribute indicating a MIME-type they don't handle. And, even if that MIME-type was something they handled, the Content-Type header should be treated as an absolute, overruling any others.

Sadly, only a few browsers, among them Mozilla, correctly handles MIME-types, and don't download files with MIME-types they know they can't parse.

[brothercake]

Right, so it would seem we've reach all-too-familiar ground with this one - do it the right way and it doesn't work, do what works and it doesn't validate :rolleyes: