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

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

From: Rick Byers <rbyers@google.com>
Date: Fri, 4 Jan 2013 15:21:44 -0500
Message-ID: <CAFUtAY_Ks8SLAh0aQfC3Ns+frb4bwxAV6sbcjXtCwbKFNPT2Ug@mail.gmail.com>
To: Cathy.Chan@nokia.com
Cc: public-webevents@w3.org
On Fri, Jan 4, 2013 at 2:19 PM, <Cathy.Chan@nokia.com> wrote:

> 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?
>

Also as another reminder: I agreed to implement this is WebKit, but we
realized this would have no effect on iOS (since their touch support is in
a private fork, as far as I can tell) so it's not sufficient to satisfy our
goal of the spec defining interoperability.  Perhaps we should just remove
it from v1 (and leave it in TEv2) if we're changing the spec anyway?


> - 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).
> > >>
> > >>
> > >
> > >
> >
>
>
Received on Friday, 4 January 2013 20:22:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 4 January 2013 20:22:35 GMT