miscoded

One of the points of having open, independently developed standards from the W3C is of course to achieve compatibility.

However, standards are not always clear and consistent, and browsers do not always get things right.

When facing a choice between being compatible with other browsers and websites OR the standard, we may have a third way: fixing the standard to align it with the common implementations and the content. That's the only way one can have the cake and eat it, be standards-compatible and compatible with the Web as it is. Is it feasible? Or even a good idea? Standards are supposed to be set-in-stone after all, to keep implementors happy so that we don't spend hours and money doing it this way only to find a rewritten standard tells us to follow that way instead..

Three real-life examples of cases where we do break or are about to break the standard:

1) getAttribute on non-existing attributes
Standard mandated returning an empty string. Other browsers returned null. Sites running into problems due to Opera's correct standards support included Yahoo mail.

We reached a general consensus that returning null is a better idea, so we have changed Opera and asked the relevant W3C group to consider changing the text in an errata or the next version.

2) Throwing WRONG_DOCUMENT_ERR on cross-document node usage
If a node created in one document is appended to another document, the standard clearly states that a WRONG_DOCUMENT_ERR should be thrown. Firefox doesn't, and sites taking the Firefox behaviour for granted and breaking in Opera included Blogger.com's rich text editor.

Opera will start to call adoptNode implicitly. I'm not sure what way the standard will go - nobody seems to intend to push for a change here. According to their bug report, Mozilla intends to fix it (which is great!) and as soon as they do and websites fix their coding errors, we can revert to spec-compatible mode. Meanwhile, we are not going to live with sites being broken in Opera due to Firefox's bugs.

3) addEventListener and firing capturing events on target
Setting a capturing "click" event listener on, say, an IMG tag has no effect, because the standard clearly says that event listeners should not fire on target. Again, Firefox gets the implementation wrong and sites where this has caused trouble include live.com (according to the Safari team, I have not seen this myself but their analysis is probably right).

Sure, we should fix the standard here and go for it - I don't see any specific benefit to not firing the event listener though I'm all ears if anyone knows why the spec is written like that. We haven't changed this yet but I guess we will follow Safari.

The lesson? To standards bodies: please care about existing implementations, experience and content when developing the standards. Specs that are seriously incompatible with prior implementations or web content cause implementation headaches, incompatibilities and suffering users.

This page should have a Flash in it. Now Opera, where is it?

Well, here's a pretty little function from Dell, meant to return an element with a specific name:

function ParseDivObjects( targetName )
{
var objs = document.getElementsByName( targetName );

//-- Workaround for "inconsistent" W3C ruleset in IE as DIV's aren't mapped with name properties
if( objs.length == 0 )
{
var targets = document.getElementsByTagName( "DIV" );
var tmpObj;

objs = new Array();

for( var targetidx = 0; targetidx < targets.length; targetidx++ )
{
tmpObj = targets[targetidx];
if( tmpObj.name == targetName )
{
objs.push( tmpObj );
}
}
}
return objs;
}

Let's start: document.getElementsByName is not supposed to be used for elements that are not supposed to have a "name" attribute. So, for example you can use getElementsByName with INPUT elements but not with DIV. Except that Mozilla apparently disagrees with that interpretation of the specification and thinks IE's behaviour is "a quirk". Really?

Anyway, Dell has a workaround for IE: they go through all DIVs in the page and check tmpObj.name, which means Opera is out of luck again. Since DIVs are not meant to have a "name" attribute we don't create any .name property for it. Using getAttribute here would make it work.

So Dell crams two different quirks into one function, and Opera fails because it supports neither. Time to violate the DOM spec a little more..

live.com was fixed to work in Opera but apparently recent changes have broken it again. Here is why:

• They declare a namespace without associating a namespace URI with it: <html xmlns:Web> in a normal text/html document
  
• When they use the namespace in <web:binding>, Opera will not return that element when you do document.getElementsByTagName('binding')
  
• (Also note that they use a capital letter in the namespace declaration and lower case in the document)
  

Now, this would work fine if they sent an XHTML content-type, added a namespace URI and fixed the case issue.

But is it a bug in Opera? I haven't been able to interpret the xmlns spec in enough detail to understand whether this is covered. Or is it in the DOM spec? Validation certainly seems to say it is wrong to declare a namespace without URI.

The only thing I know for sure is that FireFox does the same as Opera, and that might indicate that a standard is being followed. Perhaps readers more skilled at xmlns juggling can enlighten me, if not I'll learn when developers comment on the bug report..

A few times in my life I've had the mixed blessing of dealing with Visa authorities. Their job is to ask for impressive piles of paper that I guess noone will read closely, and among the things one must document is usually that you have enough money in your bank account to survive for a while without "resorting to public funds" (doesn't sound like the type of resort I'd want to spend a holiday at but Visa People like reminding you not to anyway).

Now, since I try to save some trees by asking all my banks never to send me paperwork and prefer online banking, I usually supply printouts of online bank statements. I'm always shocked that nobody questions this. I mean, it's not rocket science to edit the cache file before printing or use a bookmarklet to add a couple of strategic zeros is it? If becoming a millionaire was that easy..

Well, I'm glad visa authorities don't know this - but there is absolutely nothing in the design of a browser that is meant to guarantee the authenticity of a printout. The very simple reason for that lies in the term "User Agent". The browser is your "agent", your tool for performing tasks online. It is designed to "trust" and empower YOU as the user. It wasn't designed to verify the size of your bank account. It never ever submitted an application about becoming the Visa Authority's agent. And it does not accept responsibility for any consequences of being forced into this role by ignorant Visa Officers!

I'm sure someone in the right office would call that a security problem. To me, it demonstrates how the simple design principle "User Agent" has plenty of scope for controversy. I believe that while the importance of the Internet keeps growing, we'll run into more and more of these implicit and explicit expectations to user agent behaviour - like the assumption "web page printouts show the authentic data sent from the server" - and it may sometimes be difficult to balance these expectations.

Not every website or authority likes an empowered user. You've got those sites who don't want you to right-click or view source or save or whatever idiocy they try to enforce. Noone needs to be concerned with those that "hide" source code under such tin foil hats - but then you also have the sites that for very plausible reasons want to prevent passwords being saved or make sure the back button doesn't return you to the cached version of the previously viewed page. And several of those sites have both guts and importance to give the UA the ultimate threat: do as we tell you, or we block your users!

And those sites have a point - there are security concerns inherent inn building software that trusts the user - because what if the user right now isn't you but the next guest at the internet cafe you left without closing the browser, or your rogue colleague at work playing with your Wand logins?

Evidently, we don't want to let pages block right-click nor become the Visa Authority Agent - but how do we strike the balance between security for the sites that really need it and a trust-the-user, empowering design?