[public-pointer-events] <none>

Hi, Rick

I am developing Pointer Events polyfill for my library and this is also
very important for me.

As I understand, to get full control over element with pointer capture
(i.e. recive all pointermove events) element should have at least
touch-action: pan-[x|y];. Therefore UA has no perf problems with scrolling
and send pointemove events 'synchronously' (in terms of multi-tread
arhitecture, I think).

My propose is to add to the pointermove evebt default action which
implicitly is already -- hit testing. So, if pointermove 'll be cancelable
event, then any developer may prevent his testing by calling
preventDefault() on pointermove, at least when pointe capture is active.

Thanks


> I just wanted to update the list on this discussion. We've had a
> discussion with Jacob offline which I'd summarize as: 1) The blink team
> has been working very hard to get as much done as
> possible in our 16ms frame budget on finger move (especially on low power
> mobile devices). In one typical scenario the hit test costs us around
> 0.4ms (2.5% of the frame budget) and this is big enough to be a concern.
> 2) Pointer Events requires a hit test on every move, although it can be
> avoided if the developer is careful. Eg. they must call setPointerCapture
> AND avoid any pointerenter/leave handlers on the element with capture, and
> also avoid pointerover/out handlers on the element and all its ancestors.
> We are concerned that in practice developers will rarely be this careful.
> 3) Pointer Events is designed to allow UI elements to be activated by
> touching and lifting anywhere within their visible bounds, and combined
> with some pressed effect, is what requires a hit test on every move. Other
> mobile platforms (Andoid View and Cocoa) are designed (like touch events)
> not to require a hit test on every move, determining activation based on
> the motion alone (how the finger has moved, not what's underneath it).
> We're concerned that this difference means pointer events would put the
> web platform at a performance disadvantage relative to existing mobile
> platforms. 4) Other potential browser features (like snap points) could
> make some of
> the effects we're focused on much cheaper, but we believe there's a long
> tail of important custom effects which cannot be effectively baked into the
> browser. This issue isn't itself a deal breaker for Chrome's adoption of
> pointer
> events, but I do think it's a legitimate argument without any obvious way
> to address it. Note that this difference in UI activation philosophy is
> somewhat
> fundamental. Eg. should <button>s be activated by touching and dragging
> within their bounds then lifting on browsers that support both input
> models? I think they need to choose to either be inconsistent with
> application UI elements designed for the touch event model or those
> designed for the pointer event model. Again, existing native touch
> platforms are quite self-consistent in this regard. Rick


-- 
@nekrtemplar <https://twitter.com/nekrtemplar>