- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 20 Mar 2013 12:47:18 -0400
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: public-webevents@w3.org
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