Dynamic Flash

Whilst reading Simon Willison’s latest post about how he’s sticking with Opera 9 as his main browser, I discovered something about Opera that I didn’t know before: it modifies the DOM and/or JavaScript of certain websites to make them compatible with the Opera browser. Opera calls this feature Browser JavaScript:

Browser JavaScript is a feature that allows Opera to automatically fix incompatible Web pages, out of date scripts, and pages that inadvertently block Opera.

The affected sites include some big names, including barnesandnoble.com, blogger.com and yahoo.com. The fixes range from small design tweaks to disabling browser sniffing code. In addition, a number of standard DHTML menu libraries are patched, regardless of the site they appear on.

Apparently this feature was included in Opera 8.01 but was turned off by default. It was enabled by default when Opera went ad-free, which was almost a year ago now. Given how long it’s been around, I’m surprised I haven’t heard of this feature before. Then again, I only use Opera for compatibility testing.

Some will day that this is no worse than Firefox adding undetectable support for document.all in order to support IE-only JavaScript. However, that was a passive fix that allowed non-standard code to go about its business; Browser JavaScript actively modifies the DOM and/or JavaScript of a site to make it work in Opera.

I’m not at all comfortable with Opera ‘fixing’ these sites in this way, even if they are doing so with the best of intentions. Who’s to say that the fixes created by the Opera engineers won’t break something else on another part of the site? And what happens when the site in question is updated? Are they going to test every area of every site regularly to check their fixes? Maybe, but probably not. You can be sure that the majority of users who complain about a broken site in Opera will do so directly to the site owner and not to Opera.

Incidentally, on the subject of good intentions, the quote from Opera above says that they’re fixing incompatible websites, not non-standards compliant websites. Does this mean that this is Opera’s solution to properly implementing CSS standards? I hope not.

The one saving grace here for us poor developers is that whenever a site is modified by the Browser JavaScript feature a message is posted to the JavaScript console. Still, if we find that Opera is causing a problem we have to email Opera and wait for them to fix it, which is less than ideal.

If you think Opera is modifying your page incorrectly or unnecessarily, or if you have removed the cause of the problems, please mail web-compliance@opera.com.

I can’t believe I’m the only one who’s concerned about this, but a quick google only turned up tutorials of how to write JavaScript for the Opera browser. Typical! I’d be interesting in others thoughts on this issue.

As of last month, JSON is an IETF RFC standard (4627). This is good news indeed. [via Darryl Llyons]

Somewhat in preparation for my joining Yahoo! later this month, I have been familiarising myself with the YUI Library, using it to build a small internal application that we need at Featurecreep.

One of the things this application needs to do is communicate with our SiteServer application using its XML API. Inevitably there were some issues, and having quickly tired of clicking my way though numerous alert() windows, I thought I'd take the YUI Logger component for a spin.

Unfortunately, no sooner had I integrated this into my mini application (a simple matter of including a few external JS files and adding 2 lines of code) than I hit a show-stopper of a problem: the YUI logger didn't attempt to escape any of the big 5 entities (<, >, &, " and ') before using innerHTML to inject the message into the logger entry list. This meant that Firefox treated my XML data as HTML elements it couldn't understand and silently skipped them, rendering my XML data unreadable. Bummer.

Never one to be defeated, I rolled up my sleeves and got stuck into the logger.js file. I needed to catch the message and replace the entities as the HTML string that will be injected into the document is being built. This is being done on lines 2024 to 2034 (or 1012 to 1017 if your line breaks aren't messed up like mine are):

Now, it's only actually necessary to encode two of the big 5 entities for the browser to show us the proper information, so all we have to do is change the last line of that statement to read:

A small change, but all of a sudden I can log messages that contain HTML or XML code, or any message that contains the encoded characters. Hopefully this'll get incorporated into the main YUI Library, but in the meantime feel free to download my modified logger.js files (logger.js, logger-min.js and logger-debug.js).