i·me·michael

Update!—Turns out I spoke too soon. This problem occurred in version 7.20 build 3087. After finding this little problem last Thursday, I submitted a bug report to Opera. The latest version 7.20 build 3144 does not experience this problem. I’d rather see them rev the version rather than silently change the build number, since they do not specify the build number on their download page. Anyway, this pretty much negates anything I subsequently had to say in this entry, so feel free to skip over it.

At least that’s the way I see it.

With the release of version 7.20, Opera has made a fundamental change in the way that their browser treats XHTML documents, and in my opinion the changes they have made are incorrect, and are ultimately changes that will hurt them, rather than help them.

I first noticed something was weird, after my recent upgrade at work. A script I had been working on for a website suddenly stopped working. I was pretty sure it worked prior to the upgrade, and after checking it on my home PC, I confirmed that it had. Now the trick was figuring out why it stopped working in this latest version of Opera. Was there something wrong with the code? I’m no JavaScript expert, but I was pretty sure that the code was valid. The script was based in the DOM, but wasn’t doing anything extensive, or highly manipulative. [ed—High levels of programming are out of our league.]

Validation is always a first check, and after confirming that, since I was working with XHTML, I decided to remove the XHTML headers to see if there was something about jumping into strict mode that was messing things up. Sure enough, the minute I removed the XHTML headers, the script worked again. I then even managed to narrow the problem down to the URI declared in the xmlns attribute of the head element. If I removed the URI, the script still worked. Now I was off to Opera’s website to see what changed.

Referring to their specs page, if you scroll down to the section titled XML namespaces you will see the following:

The XHTML namespace (http://www.w3.org/1999/xhtml) triggers XHTML handling in Opera.

Well what the hell does that mean? If they already support DOCTYPE switching, why do they need to trigger XHTML handling by way of the namespace? Especially since according to the XHTML spec, a namespace declaration in the form of the xmlns attribute is required for strict XHTML document conformance. It’s not as though I can leave that out. That aside, what does Opera mean when they say XHTML handling?

Again, referring to their specs, their support for XHTML is extensive, although for some odd reason they state that they don’t support the script element. Was I asleep when they deprecated the script element in XHTML? As far as I can tell, the script element is part of the XHTML specification, and Opera should support it. But I digress.

All in all I didn’t really find anything at the Opera website that told me specifically what had changed. I just came away with the general sense that they were treating XHTML pages very strictly, and like XML, so it was back to my script to see if I could debug what Opera was doing.

Where I found my script was failing was when I was looking for nodeNames. I was doing a pretty standard evaluation against a nodeName and I was getting nothing. In reality, it wasn’t that I was getting nothing, it was that Opera wasn’t finding a match.

In this example page, Opera (v7.20) fails to evaluate to true for the five P elements on the page. The piece of code that no longer works is the following:

if (obj.childNodes[j].nodeName.toLowerCase() == ‘p’)
{
	//Do Something
}

Why? Because Opera is no longer returning just the nodeName in XHTML. It is returning the nodeName plus its namespace prefix (example page 2, ). So instead of returning just p it returns html:p. Now for the first mistake. I’ll grant you that technically speaking, treating the document as XML, returning the namespace prefix is probably correct, however, HTML is not the namespace of the document or the element in question. XHTML would have been the proper prefix to return. Under XHTML, these elements are not HTML elements, they are XHTML elements. XHTML is a reformulation of HTML in XML. XHTML is not XML with HTML elements in it. So right there, Opera is wrong.

Next, returning the prefix is basically incorrect for XHTML, since it currently does not support multiple namespaces. And is this DOM 2, or are we only talking about DOM 1 here?

Lastly, with the vast move to XHTML, unless designers and developers are aware of this change, Opera is going to be breaking scripts all over the web, and designers/developers are not going to be too happy about rewriting their code just to support Opera.

Am I incorrect in my assessment? Is Opera approaching this correctly, and is it the thinking behind the scripting that’s wrong? How about some of the DOM gurus chiming in. By all means, somebody correct me if I’m wrong, ’cause otherwise I’m just going to dismiss Opera as a viable browser again.