Confessions of a Web Developer

I've been away from this corner of the web for a month or so, focusing on the upheaval in comics fandom with The Flash, so I don't know if anyone's tagged me for Opera Watch's 5 things I’d like to see in Opera meme.

So I'm just going to throw my hat in the ring before I head off to Comic-Con tomorrow.

1. Inline spell-check and other improvements. Yeah, on-demand spell-check is available, but it's so much more convenient to have problem words highlighted as you type. I'd also like to see an "Ignore All" button, in case I don't want to teach the spell checker a word that appears repeatedly in a post. And it would be great if it would recognize and skip URLs and HTML/BBCode tags. I get really tired of hitting "Ignore" on things like href and http, but I don't want add them to the dictionary in case I accidentally type them in the body of a post.

2. Apt and Yum repositories for Linux. Opera's Linux offerings break down to about half a dozen binaries, which are available in 3 forms: .rpm, .deb, and tar.gz. Opera doesn't have to provide a separate repository for each distribution, just one yum repo for each .rpm, and one apt repo for each .deb. Once the user installs the repository, the OS's own update system will be able to take care of updating Opera. (As an example, see what Adobe has started doing with its yum repository for Flash.)

3. Delete all cookies on close with site-specific exceptions. I've given up trying to figure out what overrides what in Opera's cookie settings. What I'd like to do is just wipe everything on exit, with a list of sites that are allowed to keep cookies across sessions. Firefox does this with the "Keep until... I close Firefox" setting. I can sort of manage it in Opera by telling it to delete all new cookies when exiting, but it's more of a pain to add a new site. Instead of just adding it to the list of exceptions, I have to disable the option, log in to the site, then re-enable it. And that's assuming the site doesn't have to update the cookie later on.

4. Experimental CSS3 properties, especially box-shadow and border-radius. I know Opera 9.5 is supposed to have a bunch of CSS3 capabilities, but so far they've been cagey on just what's on the list.

5. Wii emulator mode for the desktop version. I'm not likely to pick up a Wii, but I'd like to make sure my websites look right. Small-screen rendering is great for simulating mobile devices, and the Opera Mini simulator takes care of that platform, but I can only go on descriptions for the Wii version.

I'm not big on the whole tagging thing, so I won't tag anyone else. (Besides, most of the people I could think of have probably already posted by now.)

(On the subject of Comic-Con, I'll be posting about it at my main site, K-Squared Ramblings, and guest-blogging at Comics Should Be Good.)

From time to time the idea is put forth that Opera needs to start dealing with bad code. There are two problems with that view:

1. Opera already deals with quite a bit of "bad code" (but there's always room for improvement)
   
2. Just dealing with bad code isn't enough: you have to deal with it the same way someone else does.
   

#2 is the tough part.

The rules for dealing with good code are, for the most part, specific. If you encounter well-formed HTML, you can be reasonably sure you know what the author meant. But there are very few rules for dealing with bad code. Trying to "deal with it" means trying to guess what the author meant, and sometimes different assumptions are equally as likely.

Example:

<p><b>Here's some text</i> and here's some more.</p>

Did the author close the non-existent italics by mistake, meaning to close the bold? Or did he open bold by mistake, intending to open italics? Or is the closing italics tag left over from copy-and-paste? Depending on what assumptions the browser makes, it should display it as:

Here's some text and here's some more.

Here's some text and here's some more.

Here's some text and here's some more.

And that's just a simple example. It gets wilder when you throw in issues like inline vs. block elements. A paragraph should never appear inside a tag for text formatting, like bold or italic. By all rights, starting a new paragraph (or more precisely, ending the previous one) should also revert to plain formatting. But a lot of old pages expect the formatting to continue into the next paragraph, because way back when, a P tag was a double-line break, not a container.

Now, suppose that Browser A always makes the first assumption, and Browser B always makes the second. If someone tests their code in Browser A, and it happens to be what they want it to do, they won't necessarily notice that their code is broken. The result: the site looks wrong in Browser B, and the page author -- who thinks the page is fine, since he tested it in Browser A -- blames Browser B.

Multiply that scenario by millions of pages and you have a large chunk of the web as we know it today.

So the solution isn't just to "handle bad code." It's to handle that bad code in the same way that the dominant browser handles it. And since there's no document you can look to for guidance, that means taking every possible chunk of bad code, running it through the other browser, and seeing what it does to it.

And there are a lot of ways to break code!

Even Microsoft did this back when IE was new. At the time, lots of people were writing broken code and testing it by seeing whether it looked right in Netscape. So IE had to make the same assumptions Netscape did on certain things. Once IE became established, they diverged.

Some relevant articles:

• The Residual Style Problem (Surfin' Safari)
  
• Tag Soup: How UAs handle <x> <y> </x> </y> (Hixie's Natural Log)
  
• XML Error Handling in Web Browsers (Surfin' Safari, mostly about HTML error handling)
  

I plan on refining this post from time to time.

I just read an interesting post from Microsoft's Internet Explorer team on The IE7 User-Agent String. This statement in particular illustrates a problem not unfamiliar to Opera users:

There are a few remaining sites which fail to recognize IE7 because they are performing exact string matches to look for specific IE version strings. Those checks will need to be removed or updated to accommodate IE7.

Yes, you read that correctly: there are websites out there using bad browser sniffing code which will send the wrong code to Internet Explorer 7. In fact, they go on to say that they've released a tool which will let IE7 pretend to be IE6!

To enable you to workaround any remaining sites that block access to Internet Explorer 7, we developed the User Agent String Utility. The utility comes in the form of a small executable that opens an IE7 instance that sends the IE6 user agent string. It also provides a mechanism for you to report problem web sites to Microsoft so that we can follow up with the affected site owners.

I'll admit to a certain amount of schadenfreude, but it also points up just how bad a strategy browser sniffing can be when done thoughtlessly: It effectively builds an expiration date into your website after which even the browser you designed it for will run into problems.

Posting an Opera button on your website or blog is a great way to encourage people to try out the browser -- but what if the visitor already uses Opera? It shows solidarity, but what if you could show them something else, something that is new to them?

You might want to replace your regular Opera banner with an ad for Opera Mini. Or show them another graphic of your own design. Or maybe not even a graphic, maybe post some sort of message, like "Opera spoken here!" or "Welcome, Opera visitors!"

It's relatively simple to do this in PHP, or ASP, or some other server-side script...but sometimes you have to stick with static HTML. Well, client-side JavaScript can replace chunks of your page, and here's how to do it.

1. Put the following script in a file called operalinks.js:

function replaceOperaLink(linkID) {
if(linkNode=document.getElementById(linkID)) {
if ( 0 <= navigator.userAgent.indexOf('Opera') ) {
var newButton=document.createElement('span');
newButton.innerHTML = '<a href="http://www.opera.com/">Glad to see you\'re using Opera!</a>';
var parentNode=linkNode.parentNode;
parentNode.replaceChild(newButton,linkNode);
}
}
}

For the innerHTML section, you can plug in a new link and banner, or a special message, or anything you want. (Just make sure that you put a backslash (\) in front of any apostrophes you use.)

2. Put a unique ID in the tag for your regular Opera button. Use the outermost tag that you want to replace. For example, let's start it off with this:

<a id="OpLink" href="http://www.opera.com">Download Opera!</a>

3. Load the script in your document's <head> section:

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

4. Call the function in the body onload event using the ID you chose in step 2:

<body onload="replaceOperaLink('OpLink')">

When the page loads, the script will check the visitor's browser. If it's Opera, it'll replace the banner with whatever message you chose in step 1. It's compatible with both HTML and XHTML, and you don't need to worry about using <noscript> tags to make sure the banner still shows up for people with JavaScript disabled.