Wednesday, 26. July 2006, 20:13:03
javascript, liveclipboard, coding, compatibility
...
liveclipboard is an interesting idea from Ray Ozzie. He's also blogged
the process and brainstorming behind it. This is great..
Unfortunately it doesn't work in Opera.
The reason appears to be a bug in FireFox regarding how it evaluates XPath expressions. The
document.evaluate spec states that the context node must belong to the same document as the method is called on. (The style is somewhat convoluted, I'm not 100% sure I've understood the phrase
If the XPathEvaluator was obtained by casting the Document correctly but I can't think of any other reading that makes sense).
So, if you call
document.evaluate( expression, someOtherDocument ...), Opera follows the spec to the t and throws an exception while
FireFox doesn't. The liveclipboard script relies on this FireFox bug.
The fix is simple: import the nodes to the current document before XPathing them. For example:
hCardXmlNode = domParser.parseFromString(hCardXmlString, 'application/xml');
should be
hCardXmlNode = document.importNode(domParser.parseFromString(hCardXmlString, 'application/xml').firstChild, true);
One of these cases where testing in multiple browsers will highlight your assumptions about web standards.
Wednesday, 21. June 2006, 17:30:04
browsers, coding, mozilla, Firefox
...
This makes me really annoyed: after fixing bugs and patching and in general trying hard to make things work, KLM's website is broken AGAIN. The navigation at the top does not unfold in Opera, making most of the site inaccessible.
The reason turns out to be an error happening here:
Navigation.prototype.open = function (e) {
if (e) if (e.originalTarget.innerHTML == "Home") return;
if (e) if (e.originalTarget.id == "navigation") return;
(from
this JS file )
What, I ask myself, is this
originalTarget property that we don't support? It's nowhere in the
W3C DOM events specification. Even a
Google search doesn't throw up much information. It's obviously a Mozilla-thing though.
So, we're again
playing catch-up with a new, unknown and badly documented extension to the standard. We have to reverse-engineer it with test cases to understand what is going on. Meanwhile, important sites will be broken because they insist on relying on non-standard code whatever we say. Users might abandon Opera because of it, or not switch to us in the first place.
You know Mozilla, this sounds an awful lot like the game IE has been playing with us for all those years. If anything you're worse than Microsoft because MSDN usually has at least a minimum of official documentation. And you still claim to be "an advocate for standards on the Net"?? Yeah, right.
Monday, 16. January 2006, 02:57:13
Firefox, coding, javascript, compatibility
...
Web developers like to complain about browser x or browser y being "difficult" to work with. Bah. Sure, there are really annoying bugs in any browser, but most of the time the one you test initially in and are used to will be easy. The others will present small or big surprises. A couple of times I have written pages that
only worked in Opera, because I happened to use both standardised features that are missing from Internet Explorer and IE-specific features supported by Opera but not others. A natural risk when one knows a specific browser's capabilities very well.
Here's a page I created recently that I thought was pretty standards-compliant (apart from event.offsetX and offsetY - perhaps I should ask
WHAT WG to standardise those?):
Japanese new year's breakfast..but whops, I did it again: it only appears to work in Opera. All the content is visible in any browser and I simply
like creating Opera DOM capability showcases, so I won't add workarounds - but it makes me rather curious that even old Opera 7.23 does a perfect job but new FireFox 1.5 fails. I know IE doesn't get the setAttribute('style', 'some css code') part, but I have no idea where FireFox stumbles.
Monday, 7. November 2005, 23:25:25
opera, ie, compatibility, Firefox
...
Readers will have noticed the
news about the new Microsoft portals
live.com and
start.com not being very interesting pages in Opera. They don't, in fact, do anything at all...
The sites are based on the same set of JavaScript libraries. One of these files is meant to be a "compatibility layer" for non-IE browsers. It basically "emulates" Internet Explorer JScript features so that the rest of the libraries can use such features without worrying about sniffing or browser compatibility.
To emulate JScript in such detail the authors
have stated that they need certain browser functionality. They use a Mozilla extension to the ECMAScript standard, the ability to define "getters" and "setters" for object properties. Opera does not support this functionality (mainly because it is non-standard - not in the ECMA specifications - and not widely used.)
On the other hand, Opera has worked hard on being compatible with many of
IE's extensions.
The irony! Microsoft's script library basically tells Opera "sorry, but you've spent all those years implementing the wrong standards violations! If you had copied Mozilla's violations rather than IE's we might make live.com and start.com work for you"..As an aside: if you who are reading this are a FireFox-lover and standards advocate, go ask the mozilla.org crew some serious questions about why it is considered OK to embrace-and-extend ECMAScript. Isn't this a standards violation by another name? Getters and setters are worse than FONT or document.all - there isn't even a backward-compatibility story here. One single getter or setter definition in an object literal and the whole JavaScript library is unusable in other browsers. And you claim you're writing a standards-compliant browser??
Friday, 14. October 2005, 13:29:22
browsers, websites, compatibility, Firefox
...
Coming soon to a screen near you!New software drama, Standards compliance victim, starring:
Question of the day is: why does the "news slideshow" on AOL's front page run ten times too fast in Opera?
Because
FireFox's implementation of DOM2Events has serious shortcomings, as I've
mentioned earlier. AOL.com is the latest and most high-profile site that has run into this problem so far.
On
AOL's main page the small "slideshow" runs much faster than it is supposed to, the "play/pause/next" buttons do not work, you get strange alerts about content not being available, and the whole page makes Opera use a lot of CPU resources. This is all because they use a capturing "load" event listener when they meant to use a non-capturing one.
It works in FireFox because it does not support capturing event listeners. It fails in Opera because we follow the spec.
I've written a couple of pages to show the difference. Try these in FireFox and Opera:
Since I have written the test cases, could someone do me a favour and make sure there is a Bugzilla report on the second issue? I know bug 235441 covers the former.
Thursday, 22. September 2005, 21:26:07
compatibility, Firefox, quirks, browsers
I've seen a particular mistake several times recently. It is a subtle ECMAScript spec violation that uncovers what browser engine was used during script development and testing: only Gecko-based browsers such as FireFox and presumably Mozilla allow it.
The error is to add a final comma inside an ECMAScript object literal:
var myObject = { property:'value' , }Last seen in
here and in an ad-hoc Chinese IME JavaScript demo (!) which I can't re-locate at the moment.
Try it out with the following bookmarklet:
javascript:try{eval("var a={a:'a',};");alert('Wrong behaviour!')}catch(e){alert('Correct behaviour!')}A first-class example of how a minor browser sloppiness creates a serious compatibility problem.
WIDGETIZE