W3C home > Mailing lists > Public > public-webevents@w3.org > January to March 2013

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

From: Sangwhan Moon <smoon@opera.com>
Date: Tue, 08 Jan 2013 14:41:20 +0900
Message-ID: <50EBB180.7010500@opera.com>
To: Arthur Barstow <art.barstow@nokia.com>
CC: public-webevents@w3.org
Sorry for the delayed reply - Japan's business year started yesterday
and was going through a huge backlog of mails.

Bottom line - Opera's implementation will have to be "fixed" when this
change is made. I don't think we'll have issues changing it though.

We'll hopefully implement it so sequence<Touch> and variable parameters
are both supported. At the moment we only support a Touch instance
parameter when there is only one, consequential parameters will be

Best regards,

On 1/5/13 3:51 AM, Arthur Barstow 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.
> -Thanks, Art
> [Issue-27] <http://www.w3.org/2010/webevents/track/issues/27>
> [1]
> <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>
>> ^Process <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 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).
Received on Tuesday, 8 January 2013 05:42:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:34 UTC