Re: Last Call comments

>     On 3/18/13 5:22 AM, ext Charles McCathie Nevile wrote:
>
>         Hi, these comments are from people at Yandex who implemented
>         Pointer Events for our services...
>
>         The pointer system works well when you have only one input
>         device (one mouse, one pen or single-touch-capable screen) and
>         saves some code comparing to the Safari Mobile event model.
>         But if you have more than one input device, the
>         pointer-oriented code becomes far more complex and less
>         obvious compared to the touch-oriented code for Safari Mobile
>         because you have to deal with event streams on your own. We
>         should simplify the tough case (multi-touch), not just the
>         already simple one (single input device).
>
>
>     #1. RESOLUTION: an API to return active pointers is out of scope
>     for v1, but will be tackled in v2

My position is that (a) the current proposal makes working with multi-input unnecessary complicated (ES6 Map objects to count pointers? Are you serious?), (b) because working with gestures is out of scope, we are forcing the web-developers to write tons of redundant code until the gesture proposal is finally implemented.

In my opinion we should (a) provide the correct way for working with multi-input, or (b) put this proposal aside and discuss both pointer and gesture proposal simultaneously.


>
>         Why should the mouse have pointerId == 1? There is no need for
>         this, since we have a pointerType for detecting input device
>         type, and it makes it impossible to use two mouse devices
>         simultaneously.
>
>
>     #2. RESOLUTION: supporting multi-mouse is out of scope for v1,
>     will tackle in v2. The primary mouse having id 1 won't prevent this.
>

I can't see why we should include this requirement in a specification. No existing implementation breaks if we just omit this requirement.
I also can't understand why are to accept the proposal with obvious flaws instead of waiting for this "v2" specification.

>
> Note that many of us feel that having 1 be special is weird and
> unnecessary (i.e. the concern here is indeed legitimate in my view),
> but it doesn't seem to be enough of a problem at this stage in the
> spec to warrant making a substantive change.
>
>         The capturing system is a meaningless artifact of IE6, why
>         implement it again?
>
>
>     #3. We will reply separately about this point.
>
>
> I spoke with our web components experts about this (Dimitry Glazkov,
> Darin Fisher, Erik Arvidsson).  In particular I asked if they saw any
> issue with composability of components and preserving encapsulation in
> the face of an API like this that effective hijacked events that could
> otherwise go to other components (and referenced this thread).  Their
> response was essentially:  some form of capture is essential, and
> relying on capturing events on the document is a hack that's actually
> bad for composition.  True web components should never need to reach
> outside their scope and touch elements like document.  All three of
> them independently expressed that they preferred having the explicit
> capture API as part of pointer events.
>
> I also agree with Jacob's points that this API is much easier to use
> and read then relying on capturing events at the document.  I also
> think getting explicit lost-capture notification is valuable for
> composition (less likely to trigger bugs between components than
> relying on stopPropagation).

Accessing the document is, of course, bad for composition. But accepting the wrong designed feature instead is much worse.
I quickly read over jQuery code. The accidental capturing on the random node will completely break the following functionality:
- enter/leave events detection,
- $.live functionality,
- $.handle functionality.
Is this not enough? There is no way to detect such an unexpected intervention; there is also no way to prevent dead locks on capture setting.
And I still don't see any examples when "capture is essential", except the dragging one, which could be easily solved using standard DOM Events functionality.

> On the call yesterday we agreed that if Google's web components
> experts didn't have concerns with this API, then we'd plan to leave it
> as spec'd.
>
>         Tilt angles are very difficult to work with, why not use
>         standard spherical coordinates?
>
>
>     #4. RESOLUTION: keep tiltX/tiltY units as defined
>
>
>         Preventing browser reaction via a custom css property
>         contradicts both the css paradigm (css is not designed to
>         handle user input) and the DOM Event paradigm (preventDefault
>         is the normal way to prevent browser behavior); furthermore,
>         the idea that browser may have different reactions on mouse
>         and touch actions ruins the whole proposal.
>
>
>     #5. RESOLUTION: declarative-only control over browser default
>     action (touch-action property) will remain the only mechanism for now

We are forcing the developers to write dirty hacks (such as fake div atop of canvas) to produce perfectly legitimate and useful behavior instead of forcing the browser developers to improve the JS engine like Safari Mobile team did.
For me it's absolutely clear which way is more profitable for the web industry as a whole.

As a conclusion: the whole proposal tends to solve browser makers problems in exchange for lots of difficulties for web developers. We are forcing the developers to write redundant, potentially dangerous and unobvious code. I think we should engage more developers in this discussion, for example, jQuery or Sencha Touch ones.
And I really doubt that we should accept any proposal that obviously requires implementing other still-undeveloped proposals (e.g. this one is unusable without the gestures proposal) to write the correct code.