W3C home > Mailing lists > Public > public-webevents@w3.org > January to March 2013

Re: createTouch uses undefined interface AbstractView

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 06 Mar 2013 13:00:10 -0500
Message-ID: <5137842A.9060301@mit.edu>
To: Arthur Barstow <art.barstow@nokia.com>
CC: ext Dimitri Glazkov <dglazkov@chromium.org>, public-webevents@w3.org
On 3/6/13 12:43 PM, Arthur Barstow wrote:
> If the type is changed to [WindowProxy], it would create a new
> dependency on HTML5 and that can lead to an issue when moving the spec
> to Recommendation, unless we have data/evidence WindowProxy's definition
> is stable and interoperably deployed. Do we have such data?

To turn this around, do we have such data for AbstractView?

For example AbstractView doesn't even exist in Gecko.  Our 
implementation of createTouch just uses WindowProxy in practice.

I think the existence of WindowProxy and the fact that it represents the 
"window", which is all that this spec really needs, is stable and 
interoperably implemented.

I sympathize with the concerns about being able to advance, and it may 
be that the W3C process is broken enough that you can't reference 
WindowProxy directly and still take this spec to REC.  In that case, I 
would recommend that for now you ask the html5 folks to add:

   [NoInterfaceObject]
   interface AbstractView {};
   Window implements AbstractView;

or some such nonsense to at least get us to a point where the IDL here 
is valid.  That's assuming that this would be enough for process 
purposes, of course (though it it is, accepting a WindowProxy should be 
fine too).  I'm sorry this is all such a process mess.  :(

> Boris - are there any other issues with the IDL in the [LC] spec?

Hmm.  I'd never taken a comprehensive look at the IDL here.  Looking at 
https://dvcs.w3.org/hg/webevents/raw-file/v1/touchevents.html the 
following are issues:

1)  Touch.target is an EventTarget in the IDL but an Element in the 
prose.  Which one should it be?  If it's always an Element, might be 
worth having it be an Element in the IDL.  If not, then the prose needs 
to accurately describe it.  Given that createTouch takes an EventTarget, 
I would assume the prose is wrong.

2)  The TouchList interface does not define the set of supported indices 
(presumably 0 through (length-1)).

3)  The TouchList.item() method claims to never return null, which I 
suspect is wrong.  I can't tell, because the behavior of the method for 
out of range indices isn't actually defined anywhere.  Sorry we didn't 
raise this issue when implementing the WebIDL for this; Gecko's claims 
to be able to return null and does so for out-of-range indices.

-Boris
Received on Wednesday, 6 March 2013 18:00:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 March 2013 18:00:41 GMT