Re: createTouch uses undefined interface AbstractView

Touch Events Editors, All,

Below, Boris identifies some bugs with the Touch Events v1 spec's IDL. 
Please review his comments and propose how these issues should be addressed.

My proposed resolution to these bugs ...

* Touch.createTouch() - change the AbstractView type to WindowProxy and 
add [HTML5] to the references.

* Touch.target - the definition of Touch.target should replace Element 
with TargetEvent

* TouchList.item() - clarify the indices are 0 ... length-1

* TouchList.item() - clarify that it returns null if index is >= 
TouchList.length

* Since TouchList.item returns null if the index is >= length, change 
the signature to:

[[
getter Touch? item (unsigned long index);
]]

-Thanks, Art


On 3/6/13 1:00 PM, ext Boris Zbarsky wrote:
> 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 Monday, 18 March 2013 11:55:31 UTC