W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ISSUE-43: change to \"common baseline\"?

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 18 Mar 2006 05:36:34 -0800
Message-ID: <441C0CE2.4050803@sicking.cc>
To: Web APIs WG <public-webapi@w3.org>

Web APIs Issue Tracker wrote:
> During our F2F in Oslo we agree upon some sort of common baseline for
> XMLHttpRequest. This baseline was not entirely clear. In some situations we
> agreed upon a solution when it worked in the majority of UAs and in some
> situations we left it unspecified (or unspecified for a bit) because it didn't
> work in some UAs (send() for example).

My goal has pretty much always been that we make a spec that makes 
current implementations "mostly" conformant. Conformant enough that if 
authors stick to the spec things will work almost all the time except in 
a few edge cases, and so that if implementors stick to the spec they 
will work for most of the existing content (again, except for a few edge 

> This does not mean that we should document more features, like the load and
> error event. It does mean that the attribute onreadystatechange no longer
> accepts an EventListener so that implementors know what the this keyword
> references too (the event). Changing it from Function to EventListener in
> version 2.0 would mean an backwards incompatible change and given that this
> specification is likely implemented in SVG viewers etc. as well it is better
> that there is a common baseline that is actually correct from the start.
> So besides changing that back to EventListener the object that implements the
> XMLHttpRequest interface also has to implement the EventTarget interface.

I'm reluctant to do this since this isn't something that helps either 
goal stated above. If authors use this feature their content won't work 
in most UAs, and if implementors implement this feature it'll hardly add 
support for any more existing content.

Would it really break backwards compatibility for ECMA-script 
implementations to change onreadystatechange from being a Function to 
being an EventListener?

A function following the version 1 spec will not take any arguments. 
Such a function should work fine as an EventListener in version 2, it 
just would not get access to the Event object.

Or are you worried about other bindings?

> The idea behind this is that we _set_ a common baseline for implementors we can
> work upon in the future and don't have to break. The authoring issues can either
> be dealt with in an appendix or a separate authoring guidelines document.

I do think we should have a section no matter what that describes when 
current implementations deviate from the spec.

/ Jonas
Received on Saturday, 18 March 2006 13:36:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC