Why we broke BBC's iPlayer site

it probably isn't a scalable solution but it seems at least in some cases it is the only solution, when e.g. the page does browser sniffing, or relies on behaviour that is different in other browsers but not necessarily _wrong_ in opera.

Opera uses browserjs as a measure of last resort. They use it only on very popular websites after everything else has failed. Opera needs to do this due to the large number of popular websites, which don't stick to the standards, or test their code properly across different browsers. Have a look at http://my.opera.com/hallvors/blog and you will realise how big a problem browser sniffing really is. Take a look at the websites that Opera fixes using sitepatches. They are websites like Facebook, CNN, and Amazon. If popular websites like these didn't work in Opera, users aren't going to sympathetise with Opera just because its not Opera's fault. They will simply switch to a different browser. Opera doesn't really have a choice. Also relevant: i) http://twitter.com/#!/brucel/status/113529174316154880 ii) http://my.opera.com/ODIN/blog/2009/11/05/the-lengths-to-go-t...

This incident highlights an exceptional situation where the fault was Opera's. However, in most cases it is not so.

##Edited post to elaborate on my point.##

Opera loses users when high-profile websites don't work, and often getting websites fixed is impossible — authors respond (if you can reach them at all) "We don't support Opera, duh".

Some of the patches target common scripts (especially unmaintained ones like all those "hot" DHTML menus and WYSIWYG editors full of browser sniffing and hacks), so few lines of browser.js can fix thousands of sites.

Although it sometimes backfires, most often it offers a fix without the rewrite-engine—release—everyone-upgrades cycle :)

IE has a similar internal list of popular sites that must be rendered with one of its various compatibility modes to work correctly. http://msdn.microsoft.com/en-us/library/dd567845(v=vs.85).as...

I'm sure this has driven developers crazy when they can't figure out why the site works differently in IE on the production domain than on a test one.

At the end of the day its the job of the manufacturer to ensure that their product performs to the specifications they set. If the customer decides to use the product in an extreme environment, and the product fails to perform as desired, the customer will blame the manufacturer, even though the product was never designed to work in such a scenario.

From the manufacturers perspective, it could be deemed cheaper to write "single-purpose" fixes for such scenarios, versus responding to the backlash of consumers which decide to use the product in such scenarios.

Indeed, it's rather sketchy code asking for a race condition.

I guess Opera looks at it from "Hixie" perspective: if 3 out of 4 engines do this and sites rely on it, then that's the standard.

"Opera's parser will pause until that script has loaded"

I read this as working like IE6 loading a standard SCRIPT tag in HTML. When the parser hits it all HTML parsing stops, waits for the script to download, parse, and run, then resumes. While slow it works for inline HTML parsing.

Dynamically loaded scripts, such as what Opera is describing, shouldn't cause the HTML parser to pause while the script is downloading and parsing. IMO this is a pretty big bug considering how popular dynamically appending scripts has become (eg Google Analytics async loader).

Their entire business is based around this browser engine. The better the desktop version is, the better their mobile and embedded versions are. It's noticeably faster than webkit in resource-limited environments.

At one time a company spokesperson said that they'd considered open sourcing the engine, but they didn't think their development process or income model made it a viable choice.

You could make exactly the same argument about Webkit itself, or about any of the extant HTML engines, could you not? Why did any of them decide to complicate the web by multiplying the number of engine-specific bugs in the wild? Why didn't every browser project just start with the Trident engine in IE?