- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 06 Mar 2013 13:00:10 -0500
- 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 UTC