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.

So to make up for lost time I thought I’d share another little thing I’ve been playing with. [ed—No, it’s not that!] It’s a CSS/DOM enhanced form.

The form is basically styled with CSS, and then I use the DOM for couple of subtle enhancements. What the DOM script does is look for all INPUT and TEXTAREA elements on the page, and then set the default background color, as well as a background color for when the element has focus. It filters for text input fields and leaves button types alone. It will also set the initial value for the field, assuming you have a value in the title attribute. For accessibility reasons it’s best to set the initial value anyway, and if you do, the title attribute should match. When the element has focus, the value of the field will clear, and unless you change the value, it will reset to its default (the title attribute).

It’s just a little DOM fun, and it could probably be cleaned up some, and actually made a bit more modular, but hey, I never promised you a rose garden. Feel free to play, tweak, use, whatever. Usual disclaimer applies; meaning it works on all my Win browsers. Mac users are on your own.

So I was trying to work out a CSS version of some information that was previously formatted in a table. This CSS formatted list is what I came up with so far. [Ed note—Although coded using fixed widths, it can be modified to be variable width. And don’t think we don’t know how to do it!]

The CSS works in all my Win browsers (IE, Moz, Op, Fb, NN4.x excluded), which means it probably fails miserably on Mac. I had originally coded the CSS slightly differently, but it failed in IE5.5, so a couple of tweaks and boom one more browser nobody uses anymore.

It doesn’t look like much less code to me than the table version, but I do think it’s more semantic, has more going for it from an accessibility standpoint, and I hope y’all can make some use of it.

Update! So I re-checked the page in Opera on my home PC and everything looked fine. It’s virtually identical to my work PC as far as OS and browser versions, so I can’t understand why I saw a difference at work.

In any case, I didn’t update the page, so by way of compensation I added the variable width version. [ed—Like that was hard!] I wouldn’t necessarily say that it stays crispy in milk, but it’s good down to a width of about 400px.

Update 2! It turns out that my work PC had Opera v7.11 installed, while my home PC had v7.03. Opera 7.11 showed a little glitch in the presentation, but an upgrade to 7.20 fixed it. Yay for Opera, and yay for my browser addled brain.

About a year or so ago, I did some host shopping, and after a bit of research, I was pretty confident about my switch to a new host. I knew it was a small, two-man operation, and apart from a few glitches, and slow response to support requests, I was happy with the cost/features. I had even made a point of recommending them to anyone I knew requiring hosting [ed—Something we don’t do often. Good hosting is subjective/relative.]

So this past July was a surprise, when I started to run into problems. The first clue that there was a problem was my site went offline for a few days, though email was still working. After contacting the host, I found out that they were in the midst of a server move, something I hadn’t been notified about, and something I wasn’t completely prepared for as far as backups were concerned. I also found out that they were having a problem, and were working with their new server company, (recently aquired by Hostway), to find a quick solution. The site came back online not long after, so I made a couple of quick backups (not everything), and assumed all was well. Wrong assumption.

In August the site went offline again. This time email was down as well. One day turned into two, into three, and so I contacted them again. This time there was no response. A week passed. Nothing. I waited patiently. I emailed them. I opened a support ticket. Still nothing. I checked the host’s website. Their homepage was changed to a note that they had received hundereds of emails and couldn’t get back to everyone, but that it “should be sorted out in a matter of days”.

By the second week I was signed up with a new host, and getting ready to put things back together. Near the end of the month I’d gotten a message from one of the people I’d recommended the now funked up host to that there were some new people answering questions in the forum, so I poked my head in to see if I could get some answers about the status of my site/data.

First, it was, “We have no record of you on our servers”, then it was, “Sorry, but you should have backed up your data”, and although it was a bit frustrating, the most frustrating part was that this info wasn’t coming from the site owners/admins Aron Nimani, and Jorge Catena, but from Brandon Rivers and Martyn (last name witheld by request) of Southeast Creations, who had recently merged with the troubled HostCulture, and although they were now partnered with HostCulture, were acting as though they were just good samaritans, doing a thankless job by posting DNS settings, and fielding questions from customers wondering what the hell happened to their websites. Their lack of professionalism and experience in customer relations quickly showed, and I became increasingly irate with their detached attitude, and the pretense that they’re only involvment with HostCulture was in a support capacity.

I mean, here’s a company (Southeast Creations), who although they weren’t defending him, had decided it was a good idea to go into business with a kid (Aron) who shirked his responsibility to his customers, and then ditched them when things went bad. You think they’re helping out of the goodness of their heart? Please.

So instead of addressing the concerns of those that lost websites, they simply adopted an attitude of, “Your site’s gone. It’s your fault for not backing it up. What more do you want us to say?” Then when they had enough dealings with irate customers, they closed the thread, directed all support questions to the Southeast Creations forum, and then closed the HostCulture forum. Now they’re having fun playing at being a multi-national corporation complete with a board of directors, which you’ll notice Aron is on. All the pretty Dreamweaving and Photoshopping on the site aside, you’d think a company that professes to be a “global leader in Web Solutions” would know how to to prevent directory indexing on their site.

At the end of it all, I was left extremely upset, most especially over the fact that someone can set up a business, throw up some bogus TOS, forgoing any responsibility or liability, and leaving the consumer without any expectation of warranty for services rendered. What are you supposed to do when faced with entering into a non-negotiable service agreement with an online business? Grin and bear it?