Google Maps vs. DOM2 specification 1-0

Since users reported that seeing saved addresses and getting directions on Google Maps was broken in Opera I had to do some digging. Actually a lot of digging. Eventually, I ended up here:

xO.Tia=function(a){if(!a||a==window||!a.hasOwnProperty||xO.uSa(a))return xO.Type.NATIVE;if(xO.jTa(a))return xO.Type.PROTO;if(a.constructor===Function)return xO.Type.FUNCTION;if(a.constructor===Array)return xO.Type.ARRAY;if(a.constructor===Object)return xO.Type.OBJECT;return xO.Type.NATIVE};

..which in its unwrapped and scrambled glory is a method to figure out what sort of object "a" is. The bit we didn't handle like Maps expected was:

if(a.constructor===Object)return xO.Type.OBJECT;

If you pass a DOM node to this function that if clause is true and it will conclude that it is of type "Object". Further along there was some logic detecting that this node was an Object and thus not able to have event listeners.

So, no event listener is added and nothing at all happens when clicking the triangle to view your search history:

In Firefox, a node's constructor property points to the corresponding DOM2 HTML interface. To explain that in real English, the DOM 2 HTML specification says that for each element in HTML (BODY, A, DIV, P and so on) there should be a JavaScript object named window.HTML+name of element+Element (HTMLBodyElement, HTMLAnchorElement, HTMLDivElement, HTMLParagraphElement and so on).

What's the point of that? These are "prototypes" of the DOM. Through JavaScript's prototype inheritance feature you can add properties and methods to for example HTMLDivElement.prototype and all DIVs in your document will appear to have those properties and methods. For example

HTMLDivElement.prototype.getExternalLinks = function(){
    for(var list=[],links=this.getElementsByTagName('a'),l,i=0;l=links[i];i++)
        if((new RegExp( "https?://(?!"+location.hostname+")" )).test(l.getAttribute('href')))list.push(l);
    return list;
}

lets you call div.getExternalLinks() for any DIV in your DOM to list the anchors inside that DIV that point to a an external URL. Or maybe you want an isExternalLink() method on A nodes instead? No problem:

HTMLAnchorElement.prototype.isExternalLink = function(){
    return (new RegExp( "https?://(?!"+location.hostname+")" )).test(this.getAttribute('href'));
}

As you see, the DOM2 HTML standard gives you quite a lot of power to extend the DOM.

Back to our problem. When Google Maps in Firefox looks at div.constructor it points to the HTMLDivElement object.

In Opera, it points to window.Object.

The obvious question is: is Opera wrong?

The answer: No. We are perfectly standards-compliant. We follow ECMAScript 2.62 4.3.4 Constructor property spec, DOM2 Core, and DOM 2 HTML.

The problems is: none of these specifications really cover what the constructor property of a DOM node should return.

Opera and Google Maps compatibility is a victim of spec fragmentation. The DOM specifications over there are not sufficiently aware of the details in that other spec over there to cover the issue.

The funny thing is that the public-html mailing list has had loooong-winded discussions where a vocal group argued that the HTML5 spec was too comprehensive and should be split into multiple stand-alone specifications.

Looking beyond the "what I'm not interested in should not be in the spec" shoot-out, they have a point: the spec as-is might not be "reviewer-friendly" to someone who, for example, is only interested in discussing the semantics of the HTML language. ("Spec reviewers" are completely ignored in the HTML5 "priority of constituencies" design principle).

However, fragmenting the spec increases the risk of dropping another "constructor" underspecified on the floor. Google Maps basically found an omission in DOM2's ECMAScript bindings. Opera simply followed the spec and implemented the omission..

Let's do whatever it takes to make the next HTML spec comprehensive enough. To quote Jamie Zawinski: "your needs are big because the Internet is big". So fasten your seat belts, HTML5 will be huge, it'll be complex, it'll have the weird DOM bits and parser bits – and those bits are necessary to make it a really solid specification.

Advertisements

19 thoughts on “Google Maps vs. DOM2 specification 1-0

  1. Well, did you file a bug calling for changing of the constructor properties? After all, Firefox's implementation makes a lot of sense in this case, in my opinion.I have got to admit that I had knowledge of this diversion for about 3 years and I believe I didn't file a bug. Sorry 😦

  2. Yes, I've filed a bug..on changing Opera's behaviour. I agree that Firefox's implementation makes sense (though not quite according to the formal ES-262 definition since they say it should point to a "Function object that creates and initialises objects" – HTMLDivElement and friends are not such functions. If they were you would be writing "new HTMLDivElement()" instead of "document.createElement('div')". So Firefox is stretching the definitions a little bit IMO.

    I believe I didn't file a bug. Sorry

    No problem. Honestly it would likely be lying around with a lowish priority anyway – until it started breaking Google Maps.

  3. I don't know. I'm sure not many people will agree with me but if a bug report should be filed, then it should filed to Google Maps. As was stated – Opera does nothing wrong, Opera follows specification (so where is the bug?). On the other hand Google Maps do NOT follow specification, Google Maps assume something that just doesn't have to be true.Also, this is not a reason for me to have an enormous HTML 5 "I contain everything" specification. There will ALWAYS be things that will not be covered by any current version of specification. Some will be known and important and those will be covered in later (sub)versions, some will be so insignificant that no one will ever bother to specify them. But it will never be possible to have a "complete" specification. Which means it doesn't matter whether it is in one piece of document or in many places. So DOM 2 HTML doesn't specify constructors for ECMAScript binding (it also doesn't specify C++ bindings at all – is that a bug?), so what? Is that a serious problem? If so, let's specify it in the next version. If not, well then sites just mustn't rely on unspecified and/or untested behavior.BTW, I would go even further. I don't think it's true that DOM 2 HTML says anything about ECMAScript objects HTMLBodyElement, HTMLAnchorElement, HTMLDivElement, HTMLParagraphElement and so on. It only says that there must be objects that implement these interfaces, in an extreme implementation those objects could be named dog, cat, car and aircraft and it would still be an implementation following the specification. After all, Node is an interface from DOM Core and as far as I know there is no Node object in IE's implementation of DOM Core.

  4. After all, Node is an interface from DOM Core and as far as I know there is no Node object in IE's implementation of DOM Core.

    IE's DOM is terribly incomplete and flawed. Their DOM to javascript binding is very limited and uncompliant with the ecmascript spec. That's one of the reasons why writing javascript for IE is a nightmare.

  5. kangax writes:

    > Yes, I've filed a bug..on changing Opera's behaviour. Hallvord, is there a public link to this bug that you filed?

  6. @kangax: No, the bug tracking system is not public. Only employees and a select few have access.@hallvors: I agree with the criticism of the FF implementation. I actually thought I should be able to do "new HTMLAnchorElement()" and I tried doing that, too, when I was testing these out.

  7. I have not been in touch with Google Maps yet. I'm not absolutely sure we shouldn't simply align with Firefox instead. Here's my perspective:On the Web we're sort of used to "found" features, where web developers discover something that wasn't necessarily meant to be that way but still may be valuable. This is a social as well as a technical process – one of discovery and information sharing – and it is a valuable one. These findings subsequently teach standards bodies and browser makers what new tools web developers need.There are easy workarounds. Google Maps could most likely do tricks with insteanceof instead. But perhaps .constructor is one of those "found" and useful features we should accept and standardise?

  8. Haven't even bothered testing because I assume Google wouldn't push out a new Maps version if essential features were broken in Chrome :-p

  9. From the forum:Originally posted by fearphage:

    Safari – HTMLDivElementConstructorFF & Chrome – HTMLDivElementIE – undefinedOpera – Object

  10. The thing is that just about any value *except* Object will keep Google Maps happy :-o. So both Safari and Chrome will still work (though it is interesting that they are different. I suppose it is inevitable that there will be differences that web developers have to cater to at some point).

  11. Originally posted by xErath:

    IE's DOM is terribly incomplete and flawed. Their DOM to javascript binding is very limited and uncompliant with the ecmascript spec. That's one of the reasons why writing javascript for IE is a nightmare.

    That's actually beside the point, whether this is or isn't true (I've never had much problem with the core part of DOM in IE, I've had much worse experience with for example Konqueror in the early 3.x series). The point is that there doesn't have to be an object called Node and it still can be a compliant implementation.What I actually find more worrying is that no specification at all says which ECMAScript object should/must implement the Document interface. So it doesn't have to be an object called "document", it could be called "doc", "Document" or "haydenPanettiere" and it'd still be following all the specifications. 🙂 Of course luckily all browsers used the name "document" but purely from standards' point of view that's only a coincidence.

  12. Nice article. I think part of the problem with splitting the spec up is maintenance: if different working groups work on the specs separately, HTML6 won't be released in one piece–the specs will float in several years apart. Not saying the W3C has difficulties publishing a recommendation in a short amount of time, but asking half a dozen working groups to publish recommendations simultaneously is just asking for trouble.How has Opera and/or Google worked to solve the specification problem you talked about in your post?

  13. On our side we have published a browser.js patch for Google Maps.I know that the issue has been brought to the attention of the right people at Maps but I don't know what they will do about it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s