W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: IE Team's Feedback on the XHR Draft

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 25 Feb 2008 21:33:46 +0100
To: "Sunava Dutta" <sunavad@windows.microsoft.com>, "Charles McCathieNevile" <chaals@opera.com>, "Chris Wilson" <Chris.Wilson@microsoft.com>
Cc: "public-webapi@w3.org" <public-webapi@w3.org>, "Gideon Cohn" <gidco@windows.microsoft.com>, "Zhenbin Xu" <zhenbinx@windows.microsoft.com>, "Marc Silbey" <marcsil@windows.microsoft.com>, "Ahmed Kamel" <Ahmed.Kamel@microsoft.com>
Message-ID: <op.t63kqkgt64w2qv@annevk-t60.oslo.opera.com>

On Sat, 09 Feb 2008 05:09:07 +0100, Sunava Dutta  
<sunavad@windows.microsoft.com> wrote:
> For interoperability, if a test does fail on all browsers (right now 32  
> fail on 4 major browsers using the incomplete existing suite. See  
> bottom) I would say it would be useful to have a plan for a default  
> given that this is an existing feature that’s been on the web for a  
> decade? Otherwise it may become an academic exercise and create  
> confusion. Either way, we recommend resolving these deltas to determine  
> behavior and LC may be an appropriate time to do this. We appreciate the  
> effort the authors have put in here creating the test suites and we'd  
> also be more than glad to create a local copy of the test so we can know  
> where IE fails. Would it be possible once the tests are relatively  
> stable to package them (including reference files) and send us a copy?

It seems that most of the "universal" failures are in event ordering and  
dispatching of events in general. Each individual bit of such a test is  
most likely aligned with a particular implementation, but the whole event  
sequencing that is being tested is not. Some of these tests would also  
pass in some browsers once acknowledged bugs are fixed.

In order to move forward it's probably best to also suggest what the  
specification should say instead, if you consider a particular testcase  
failure problematic. In the end the idea is that all browsers fix a set of  
bugs and authors get a consistent API. It might be that we want to make  
some changes to the API as currently proposed and those suggestions are  
certainly welcome.


> Reemphasizing what Chris mentions, we do believe that detail is good as  
> long as it's readable and easy to assimilate. I humbly suggest removing  
> or in the minimum mentioning which parts are UA implementation details  
> that are not necessarily binding, especially if those areas achieve the  
> same end result to users.

As I mentioned in my previous e-mail on this I have a hard time  
understanding what you consider to be an implementation detail because as  
far as I can tell the specification is not mentioning any. I personally  
believe specifications should not mention implementation details.


> I have heard points in the contrary mentioning that the content is  
> suitable for the audience but I do feel while plenty of web developers  
> are very technical, the web developer community at large could benefit  
> if the content is better delineated/factored. The existence of XHR  
> developer guidelines on the web today does not mean having a section in  
> this W3C spec for developers would be unnecessary. A W3C spec is  
> universally acknowledged to be official, has process and authority and  
> is therefore different from those tutorials. These are our thoughts and  
> may be dismissed or addressed if deemed appropriate at LC.

What exactly do you want? An informative section explaining the API for  
authors and a normative section explaining the processing model for user  
agents? I suppose that would be doable.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Monday, 25 February 2008 20:29:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 25 February 2008 20:29:10 GMT