W3C home > Mailing lists > Public > public-webevents@w3.org > July to September 2012

Re: TouchList.identifiedTouch method in Touch Events v1

From: Scott González <scott.gonzalez@gmail.com>
Date: Tue, 7 Aug 2012 12:45:19 -0400
Message-ID: <CAO8i3ifWGT5TjzrB_nKTfq7xKpnE17Kn4+W0J57ccqU753CtGA@mail.gmail.com>
To: Matt Brubeck <mbrubeck@mozilla.com>
Cc: "public-webevents@w3.org" <public-webevents@w3.org>
If this does turn out to be an issue, I think dropping it from the v1 spec
is fine. I ran into this issue when working on the experimental event
normalization for jQuery UI and just implemented the function myself. It's
only about 5 lines of code and could presumably be polyfilled via
TouchList.prototype (I just created a local function since jQuery doesn't
modify native prototypes).


On Tue, Aug 7, 2012 at 12:35 PM, Matt Brubeck <mbrubeck@mozilla.com> wrote:

> For Touch Events v1 to become a Recommendation, it needs least two
> interoperable implementations. When we created Touch Events v1, our goal
> was to specify only features that already have interoperable
> implementations [1].
>
> As far as I can tell, the identifiedTouch method of the TouchList
> interface is implemented only in Gecko [2] and BlackBerry OS [3]. This is a
> risk for the v1 spec.  If either Gecko or BlackBerry fails to conform to
> the spec in some other way, then it does not have two complete
> implementations.  In particular, I worry that RIM is no longer active in
> the working group, and may not be ready to update BlackBerry OS to fix any
> conformance issues we find as we complete the test suite.
>
> It might be a good idea to remove identifiedTouch from the v1 spec; this
> would fit the spirit of specifying only what is already interoperable
> today.  Unfortunately we did not identify this as a "feature at risk" in
> our Call for Implementations.  If its removal is considered a "substantive
> change" then removing it would mean returning the spec to the working group
> [4].  I apologize for not identifying this risk sooner.
>
> Another way to mitigate the risk is for another vendor to add support for
> identifiedTouch (along with any other changes needed to conform to Touch
> Events v1).  Are any other vendors planning to implement this method?
>
> [1]: http://dvcs.w3.org/hg/**webevents/rev/2d830a098494<http://dvcs.w3.org/hg/webevents/rev/2d830a098494>
> [2]: https://developer.mozilla.org/**en-US/docs/DOM/TouchList.**
> identifiedTouch<https://developer.mozilla.org/en-US/docs/DOM/TouchList.identifiedTouch>
> [3]: http://blackberry-webworks.**github.com/WebWorks-API-Docs/**
> WebWorks-API-Docs-Smartphone-**Payment-1.5/view/TouchList.**html<http://blackberry-webworks.github.com/WebWorks-API-Docs/WebWorks-API-Docs-Smartphone-Payment-1.5/view/TouchList.html>
> [4]: http://www.w3.org/2005/10/**Process-20051014/tr.html#**return-to-wg<http://www.w3.org/2005/10/Process-20051014/tr.html#return-to-wg>
>
>
Received on Tuesday, 7 August 2012 16:45:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 August 2012 16:45:47 GMT