- From: Rick Byers <rbyers@chromium.org>
- Date: Mon, 30 Mar 2015 19:31:54 -0400
- To: Doug Schepers <schepers@w3.org>
- Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <CAFUtAY8P4w4m8T_r-38QO+zZ8nsKXMe3XjF45QraXN0WvQmErQ@mail.gmail.com>
Never mind, I see it now. Must have been a caching issue. On Mon, Mar 30, 2015 at 6:08 PM, Rick Byers <rbyers@chromium.org> wrote: > Quick question. I see http://www.w3.org/TR/pointerevents/ still links to > the PR version. Shouldn't that link be updated to point to the REC? > > On Tue, Feb 24, 2015 at 2:34 PM, Doug Schepers <schepers@w3.org> wrote: > >> Hi, folks– >> >> I'd like to thank and congratulate everyone who contributed to the >> Pointer Events specification. As you probably know now, Pointer Events has >> now been published as a W3C Recommendation [1][2]. >> >> Scott González (jQuery Foundation) and Jacob Rossi (Microsoft) published >> some good blog posts on the publication [3][4]. >> >> These blog posts address a serious issue: the lack of universal >> interoperability, and competition with the Touch Events technology (also >> published by W3C). We hope that with work and developer interest, this will >> change over time. >> >> This same issue was the basis for some valid concerns and a Formal >> Objection by Yandex, on behalf of developers, a point which I'm sure we all >> appreciate; we are all trying to improve the experience for users and >> developers. W3C's Director took this feedback seriously, but ultimately >> decided that publication of Pointer Events as a Recommendation was the best >> path forward. Here is an excerpt of the Member-only decision: >> >> [[ >> In considering this objection, we note […] that the Pointer Events >> specification provides application access to additional data for some >> devices (e.g. pen) that is not provided by the Touch Events specification. >> The lack of an Recommendation for access to these devices is an impediment >> to developers whose applications wish to use these devices to the full >> extent of their capability. >> >> While in general having one technology design per feature is often >> better, it has never been a criterion for W3C that two Recommendations may >> not cover common features with different techniques. In this case both >> sets of interfaces have been implemented in the market and we believe that >> it is in the best interest of the Web Platform at this time to allow >> developers to innovate on both Pointer Events and Touch Events. >> ]] >> >> Again, thanks to you all, and it's been a pleasure to work with you in >> this working group! >> >> >> [1] http://www.w3.org/TR/2015/REC-pointerevents-20150224/ >> [2] http://www.w3.org/blog/news/archives/4430?pk_campaign= >> feed&pk_kwd=pointer-events-is-a-w3c-recommendation >> [3] http://blog.jquery.com/2015/02/24/getting-on-point/ >> [4] http://blogs.msdn.com/b/ie/archive/2015/02/24/pointer- >> events-w3c-recommendation-interoperable-touch-and- >> removing-the-dreaded-300ms-tap-delay.aspx >> >> >> Regards– >> –Doug >> >> On 2/5/15 10:58 AM, chaals@yandex-team.ru wrote: >> >>> Hi folks, >>> >>> [I got the core of our objection onto the public list now, so we can >>> continue the discussion there if you like] >>> >>> 05.02.2015, 18:39, "Doug Schepers" <schepers@w3.org>: >>> >>>> Hi, Patrick– >>>> >>>> On 2/5/15 9:45 AM, Patrick H. Lauke wrote: >>>> >>>>> On 05/02/2015 14:29, Arthur Barstow wrote: >>>>> >>>> >>> In principle, what's the process here? Do we get a chance to >>>>> respond to the objection? >>>>> >>>> >>>> Just to let you know the process: >>>> >>> >>> [sensible process as far as I can tell] >>> >>> 3) No formal decision by the Director has been made yet, but it >>>> will be made and announced soon. At this point, the Director is >>>> making another attempt to find a mutually acceptable path forward. >>>> I expect this to be resolved (one way or another) in the next >>>> week. >>>> >>>> I apologize for the delay, and the lack of clarity thus far. I'm >>>> somewhat hampered in what I can say because of member and team >>>> confidentiality. >>>> >>> >>> Yup. Sorry. >>> >>> At the same time, however, it's important that we treat Formal >>>> Objections (from anyone) seriously, and try our best to find a >>>> mutually acceptable path forward, even if it causes a short delay. >>>> >>> >>> Agreed. >>> >>> I can see an argument for this whole process to be more open and >>>> transparent, with a notification to the WG about the Formal >>>> Objection right away. >>>> >>> >>> That's really an argument about process, not one for this group, but >>> I would have been fine with that - and it might have pushed my >>> priority stack in a way that would have made life better for people. >>> >>> However, that would invite an even lengthier discussion, and we >>>> hoped that an initial call with objector and the Director might >>>> make that unnecessary. Unfortunately, that did not happen, putting >>>> the publication on hold until a final decision has been made. >>>> Because of that, at this point, Art appropriately decided to let >>>> the WG know why the spec wasn't published. >>>> >>>> (Personally (e.g. not an official W3C stance), I think Formal >>>> Objections, and the meeting with the Director to discuss them, >>>> should all be done on the public record. But that's not my decision >>>> to make; it's up to the Advisory Committee.) >>>> >>> >>> Noted for the process task force and the AC. But my personal position >>> is that this won't always fly, and I would prefer to prioritise the >>> input over transparency if it really came down to it. My experience >>> is that there has generally been a reasonable amount of transparency >>> provided "post hoc", without compromising the confidence that enables >>> frank input to be heard by the director and judged. >>> >>> cheers >>> >>> Chaals >>> >>> -- Charles McCathie Nevile - web standards - CTO Office, Yandex >>> chaals@yandex-team.ru - - - Find more at http://yandex.com >>> >>> >> >> >> >
Received on Monday, 30 March 2015 23:32:41 UTC