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: Sun, 19 Mar 2006 04:32:06 -0800
Message-ID: <441D4F46.8030005@sicking.cc>
To: Anne van Kesteren <annevk@opera.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>

Anne van Kesteren wrote:
> On Sat, 18 Mar 2006 14:36:34 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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 thing is that web browsers (as in Opera, Firefox, Safari, Internet 
> Explorer) are not the only browsers that will implement this 
> specification. For new implementations (SVG viewers for example) it 
> makes no sense to follow version 1.0 of the specification in the case 
> that version 2.0 would "contradict" it. Now that doesn't make sense to me.

I do agree that for other binding languages this is a problem. I don't 
even know what a Function would look like in the Java bindings.

However I think we should try to find a solution to this problem rather 
then giving up on writing a spec that tries to define what works today.

One solution might simply be that in version 2 we would simply add 
addEventListener (or rather make the XMLHttpRequest an EventTarget). 
That way there would be no collisions or incompatibilities.

> The specification should just state what should be implemented. If that 
> isn't the case in some implementations they simply have to be fixed. In 
> the end we need two conforming implementations anyway. (Or, whatever we 
> decide for CR exit critera.)

If that was our only criteria then I would say the spec should look 
vastly different. I still think our main goal with this spec is define 
something that shows what works today. Both from an implementor and from 
an authors point of view.

> Things like "UAs SHOULD support send() without arguments" are also just 
> no good for exactly those reasons. It's fine for UAs to be 
> non-conformant to every part of the specification. Those things are 
> called bugs. Bugs should not affect the specification imho, only some 
> non-normative appendix on authoring guidelines. (Sorry for not objecting 
> earlier.)

So if we want to do things the right way all parameters to send() and 
open() would be required since that's the only thing that'll work in Java.

As I've said before, conformance is not an issue to me. Claiming 
conformance is a pretty arbitrary thing anyway.

What matters to me is that we get a spec that tells implementors what to 
implement to support current content, and authors what to write so that 
they support current implementations.

/ Jonas
Received on Sunday, 19 March 2006 12:32:10 UTC

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