- From: Rick Byers <rbyers@chromium.org>
- Date: Mon, 20 Aug 2012 23:56:41 -0400
- To: Sangwhan Moon <smoon@opera.com>
- Cc: "public-webevents@w3.org WG" <public-webevents@w3.org>
- Message-ID: <CAFUtAY_CxbohxbgLLOug=pAHoKP0NmzR5ADv=71bK883_Y3CLg@mail.gmail.com>
Sorry for the delay guys, I missed this thread somehow. On Tue, Aug 7, 2012 at 12:57 PM, Sangwhan Moon <smoon@opera.com> wrote: > > On Aug 8, 2012, at 1:35 AM, Matt Brubeck 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? > > We can probably state we can implement it at this point. The fact that the > method exists shouldn't still > block interoperability with existing applications that use touch events, > which means there isn't substantial > risk in implementing this for most vendors - so I hope there are more > vendors that can commit to support this. > > We're also fine with getting rid of it, if interoperability is at stake - > although I'm a bit surprised that Blackberry > OS's implementation never seemed to make it into webkit trunk, as I > wouldn't imagine it being a really complicated change. > This looks easy to implement to me. As I mentioned in my later thread, I've filed http://code.google.com/p/chromium/issues/detail?id=142938 to track implementing this in WebCore / chromium. I don't anticipate any problems, but I sometimes can't predict the WebKit review process :-). I wasn't planning on doing this until our next milestone (eg. 4-6 weeks from now), but let me know if not having this sooner blocks anything and I'll find someone else on my team to get it done (assuming it is indeed easy). Thanks, Rick
Received on Tuesday, 21 August 2012 03:57:29 UTC