Re: createTouch uses undefined interface AbstractView

Boris - I updated the spec per your requests [1], [2].

For the purposes of Last Call comment tracking, would you please review 
the changes and let us know if the changes are OK or not. If the later, 
I would appreciate it you would please propose text that would satisfy 
your concerns.

   <https://dvcs.w3.org/hg/webevents/rev/67417356ff2a>
<https://dvcs.w3.org/hg/webevents/raw-file/v1/touchevents.html>

FYI, your comment (as well as the related one by Ms2ger) are tracked in [3].

-Thanks, AB

[1] 
<http://lists.w3.org/Archives/Public/public-webevents/2013JanMar/0064.html >
[2] 
<http://lists.w3.org/Archives/Public/public-webevents/2013JanMar/0069.html>
[3] <http://www.w3.org/2010/webevents/wiki/TouchEvents-LCWD-24-Jan-2013>


On 3/18/13 7:54 AM, ext Arthur Barstow wrote:
> 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 Wednesday, 20 March 2013 16:47:47 UTC