Re: Pointer Events Recommendation delayed by a Formal Objection

On Thu, Feb 5, 2015 at 10:01 AM, <chaals@yandex-team.ru> wrote:

> We are the member who submitted the formal objection. It is currently
> under active discussion with the director.
>

Chaals, thanks for providing some public information. I'm wondering if
Yandex is willing to publicly post the formal objection that was submitted,
as I've heard many developers asking about this.

Our basic concern is that W3C recommending pointer events sets up a long
> and painfully costly fragmentation between it and the existing touch/mouse
> events - which may be architecturally inferior, but seem unlikely to
> disappear any time soon, and in particular not in favour of pointer events.
>

I don't think the transition is nearly as long or painful as you might
expect. Developers seem to be clamoring for Pointer Events. For example, the
issue to implement Pointer Events in Chrome
<https://code.google.com/p/chromium/issues/detail?id=162757> has 330 stars,
which may not seem like a lot on its own but it puts it in the top 99.96%
of all issues (open and closed). There have been multiple polyfill
implementations and a lot of interest from developers to switch to Pointer
Events exclusively even before there's native support everywhere. Even
before Pointer Events existed, many developers were already avoiding using
Touch Events directly by using gesture libraries such as Hammer
<http://hammerjs.github.io/>. Popular frameworks like jQuery Mobile even
provide their own abstraction to avoid working directly with Touch Events.

jQuery UI, jQuery Mobile, and Dojo all have plans to use Pointer Events
exclusively and rely on the PEP polyfill <https://github.com/jquery/PEP>
until there is native support everywhere. I would expect more developers to
choose Pointer Events via a polyfill over the headaches of Mouse Events +
Touch Events, even if they're not using one of the popular libraries that
relies on the polyfill anyway.

We would be interested to see a small Rec that basically covers the
> pen-type info like pressure and angle, e.g. extending touch events. Except
> in InkML those things aren't available as a specified standard for the Web
> platform and we're no more optimistic about InkML as the way to do them
> than we are about pointer-events.
>
> We would like to see pointer-events clearly documented (we have to use
> them in certain cases), but we don't think it is helpful to have two
> competing Recommendations, and perhaps unfortunately we believe that the
> market has made its decision.
>

I don't think that's true. Just because the only option that has existed
has become widely used doesn't mean that the market is happy with that
option.

We believe a lot of energy will be needed to teach developers another
> approach and modify the workflows and toolchains across the web.


There is considerably less to learn about Pointer Events than Touch Events;
the transition from Mouse Events is much more obvious. I think it's safe to
say that developers as a whole do not yet know how to properly work with
Touch Events. I'm not sure what workflows or toolchains would need to
change. Can you elaborate on that point?