

Why we broke BBC's iPlayer site - middric
http://my.opera.com/sitepatching/blog/2011/09/12/why-we-broke-2

======
user24
One thing I didn't see addressed was why it's a good idea to add in site-
specific patches at all? I understand that taken as a whole there's no real
fixed language that website used - it's all some of html5, some html4, some
just totally broken stuff etc etc. But I cannot see why sitepatching can ever
be a scalable solution to that problem. It just reeks of hackery to me.

edit: looking into it, it seems that the tech behind this is
<http://www.opera.com/docs/browserjs/>

~~~
Indyan
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...](http://my.opera.com/ODIN/blog/2009/11/05/the-lengths-to-go-to-to-get-
a-site-fixed)

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.##

~~~
smackfu
Incidentally, this is the same argument Microsoft makes for the various
compatibility modes in new versions of Windows. If Vista breaks an app, and
it's due to poor app coding, the users are still going to blame Vista.

------
sesqu
> The underlying bug is that if you through the DOM append a SCRIPT tag
> loading an external script, Opera's parser will pause until that script has
> loaded.

How is this a browser bug? I expect all script tags to execute when they are
parsed, and make sure to trigger DOM-touching scripts only after the DOM
reports being ready.

~~~
pornel
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_.

------
al_james
Reading articles like this makes me wonder my Opera bothers having their own
HTML engine at all (at least for desktop). Why not use webkit and help develop
that? I cant see any advantages from Opera's point of view, just a big bunch
of problems, and _another_ set of browser specific bugs for web developers
everywhere.

I mean, how many man-hours were wasted (for Opera and the BBC) as a result of
this bug alone?

~~~
Lagged2Death
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?

~~~
seabee
Only MS can improve and fix the Trident engine, for a start.

~~~
Lagged2Death
Yes, which is an advantage, if you're of the opinion that the existence of a
variety of engines (and the corresponding existence of a variety of bugs) is a
hassle that's hurting the web.

That's not my opinion, mind you.

