On Thu, 08 Sep 2011 23:15:48 +0200, Ian Hickson <i...@hixie.ch> wrote:
On Thu, 8 Sep 2011, Boris Zbarsky wrote:
On 9/8/11 4:41 PM, Hallvord R. M. Steen wrote:
> as far as I know Opera is currently the only browser that supports
> both script.onload and script.onreadystatechange, and this is causing
> us compatibility problems because many scripts set both and expect
> only one of them to run. For this reason, we plan to drop
> script.onreadystatechange support.
That will break still other sites. That's why it's been added to the
spec; it turned out that as long as script.onreadystatechange is not
undefined (which the spec currently requires because it defines all on*
attributes on all elements) there are sites that expect the event to be
fired. Where by "sites" I mean at least Yandex maps so far in Gecko's
experience of shipping this for a few weeks in nightlies.
The other obvious option here is to move onreadystatechange from being
on all elements to only being on some elements....
Yeah, that is rapidly becoming my conclusion too. A few exceptions like
this aren't going to kill us (per spec <marquee> already has a few
exceptions of its own), but I would like to keep it to a minimum if we at
all can. Having just one set of these event handlers that apply
everywhere
simplifies the platform quite a bit.
For implementors, yes, but it's not really helpful for authors. For
authors it would be more helpful to be able to detect if an event is
supported on a particular element (or document or window) by checking if
the event handler is supported. Currently if we introduce a new event on
an element that has the same name as an event used elsewhere, authors
can't feature detect support for the new event.
I'd like to study some of the pages that break if they have both, though,
to see if there's anything simpler we can do first.
--
Simon Pieters
Opera Software
