Re: [Touch events] createTouchList should probably take a sequence, not an IDL array

On Fri, Jan 4, 2013 at 1:51 PM, Arthur Barstow <art.barstow@nokia.com>wrote:

> Sangwhan - for Touch Events v1, do you support making this API change as
> captured in [Issue-27]? What is the impact of the proposed change on
> Opera's implementation(s)?
>
> As mentioned below, AFAIU, the proposed change will not affect WebKit
> implementations (although it would be good for Rick and/or others to
> verify) and in [1], Matt expressed willingness to update Gecko/FF
> accordingly.
>

Yes, WebKit expects a variable argument list of Touch objects.  Eg. see the
following links for the test that validates this, and the V8 binding code
that implements it for Chrome:

https://code.google.com/searchframe#OAMlx_jo-ck/src/content/test/data/layout_tests/LayoutTests/fast/events/touch/script-tests/document-create-touch-list.js&exact_package=chromium&q=createTouchList&type=cs&l=17
https://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/v8/custom/V8DocumentCustom.cpp&exact_package=chromium&q=createTouchList&type=cs&l=119


>
> -Thanks, Art
>
> [Issue-27] <http://www.w3.org/2010/**webevents/track/issues/27<http://www.w3.org/2010/webevents/track/issues/27>
> >
> [1] <http://lists.w3.org/Archives/**Public/public-webevents/**
> 2012OctDec/0050.html<http://lists.w3.org/Archives/Public/public-webevents/2012OctDec/0050.html>
> >
>
>
>
> On 12/9/12 10:33 AM, ext Arthur Barstow wrote:
>
>> Hi All,
>>
>> If we decide this bug (now issue-25) is a "must fix" for v1, then since
>> the change could affect an implementation of the December 2011 CR, the spec
>> would need to go back to Working Draft although it could be a Last Call WD.
>>
>> When the new LCWD review period is over, _if_ we already have interop
>> data that satisfies the CR's exit criteria, then (assuming there are no
>> substantive changes as a result of the LC review period), the process would
>> permit us to skip a new CR and go straight to a Proposed Recommendation
>> (this is often called a "zero-length CR"; see ^Process). Note the
>> publication of a LCWD would start a new 60-day Call for Exclusion period
>> (^CfE).
>>
>> As I understand it, the proposed API change would affect implementations
>>  as follows:
>>
>> * Webkit - no change  needed (the proposed change  aligns  with WebKit,
>> one of the agreed requirements for v1)
>>
>> * Gecko - would need to change. Matt, Olli - is this true? Are you
>> willing to update your implementation and if so, what is the timeframe?
>>
>> * Opera - I don't know. Sangwhan?
>>
>> * Others? - are there other implementations to consider?
>>
>> Cathy - if this change is agreed, how much work will be requiredto update
>> the test suite? (Fairly trivial?)
>>
>> I don't feel real strongly here but if we are going back to WD, I would
>> like to do so as soon as possible.
>>
>> -AB
>>
>> ^CfE <http://www.w3.org/Consortium/**Patent-Policy-20040205/#sec-**
>> Exclusion<http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion>
>> >
>> ^Process <http://www.w3.org/2005/10/**Process-20051014/tr.html#last-**
>> call <http://www.w3.org/2005/10/Process-20051014/tr.html#last-call>>
>>
>>
>> On 12/6/12 5:21 PM, ext Rick Byers wrote:
>>
>>> On Thu, Dec 6, 2012 at 5:06 PM, Matt Brubeck <mbrubeck@mozilla.com<mailto:
>>> mbrubeck@mozilla.com>> wrote:
>>>
>>>     On 12/6/2012 12:59 PM, Rick Byers wrote:
>>>
>>>>     Since the goal for the V1 spec is interoperability, I'd vote for
>>>>     changing the spec and adding this form to the Gecko
>>>>     implementation - but I don't know what that means for the spec
>>>>     (do we have to go back to WD?).  I filed
>>>>     https://www.w3.org/2010/**webevents/track/issues/27<https://www.w3.org/2010/webevents/track/issues/27>to track.
>>>>
>>>     Yes, I think we would have to go back to WD.  I agree that
>>>     correcting the spec (and Gecko) to match WebKit is the right thing
>>>     to do, as long as we think it's worth the effort.
>>>
>>>
>>> Thanks Matt.  I don't have a strong opinion on whether it's worth the
>>> effort (I guess I don't have a good idea of how much effort that entails).
>>>  I'll defer to you guys.  Sorry I didn't raise this issue as soon as I
>>> realized that WebKit didn't match the spec (at the time, I thought the
>>> right thing to do was just fix WebKit).
>>>
>>>     For what it's worth, when we were considering changing
>>>     createTouch/createTouchList for Touch Events v2, we were not able
>>>     to find any uses in the wild (outside of test code).  We also
>>>     planned at one point to drop these methods in v2 and replace them
>>>     with DOM4-style constructors.  But for now, having an
>>>     interoperable createTouchList would definitely be beneficial for
>>>     use cases like automated testing (especially since the v2 work is
>>>     abandoned).
>>>
>>>
>>>
>>
>>
>
>