[Touch events] identifiedTouch (was: createTouchList should probably take a sequence, not an IDL array)

Along a somewhat similar vein (of v1 goal being documenting existing
implementations), how do we plan to resolve the issue with
TouchList.identifiedTouch()? As a reminder, the identifiedTouch() method is
implemented in Firefox and Opera but not in WebKit. Should we, for example,
consider making the method optional?
- Cathy.

> -----Original Message-----
> From: Barstow Art (Nokia-CIC/Boston)
> Sent: Friday, January 04, 2013 1:52 PM
> To: Sangwhan Moon
> Cc: public-webevents@w3.org
> Subject: Re: [Touch events] createTouchList should probably take a
> sequence, not an IDL array
> 
> 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).
> >>
> >>
> >
> >
>