W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2014

Re: Blink does not plan to implement pointer events

From: François REMY <francois.remy.dev@outlook.com>
Date: Wed, 20 Aug 2014 23:08:45 +0200
Message-ID: <DUB130-DS232AC0EE7848164E18B774A5D20@phx.gbl>
To: "Arthur Stolyar" <nekr.fabula@gmail.com>, Scott González <scott.gonzalez@gmail.com>
Cc: "Rick Byers" <rbyers@chromium.org>, "Olli Pettay" <olli@pettay.fi>, <public-pointer-events@w3.org>
>> So the assumption here is that developers will continue to
>> choose native over web because of the .3ms spent on hit
>> testing during pointer movement? I think that's really far
>> fetched. I've met many many developers who prefer
>> Pointer Events over Touch Events, but less than a handful
>> of developers who prefer Touch Events over Pointer Events.
>> I can't imagine that many developers are concerned about
>> the performance hit in this area over developer ergonomics.
>
> It would be good to have
> element.setPointerCapture({ trackBoundaries: false });
>
> I understand position of Blink here, but PointerEvents are
> already here and they have this 3ms problem. I think it
> absolutely should be fixed.

The hit-testing cost is already removed for pointer-events if you do set a 
'normal' pointer capture. The hit-testing cost is only incurred if you don't 
set a pointer capture (because it has to compute the element owning the 
event at every single pointer move, like it currently happens for the mouse 
events in all desktop browsers).

Additonnally, any sane gesture library will definitely set a pointer capture 
for you, so this isn't something you really need to worry about.

------

An interesting idea to ponder would be to allow auto-capture to be 
expressable in CSS using "touch-action: trap-pointer", so that you don't 
even have to register an event handler to disable hit-testing on swipe. 
Another good thing would be to specify the hit-testing should be limited to 
the current node and its children, like "touch-action: trap-pointer-inside", 
to specify you only intend your drag to span a reduced set of your document. 
To make this system complete, we could add another property like 
"touch-action: trap-pointer-outside" which would make sure the hit-testing 
during pointer move event do not consider all the children of an element 
independently.

With this, it would be super-efficient to create a drag and drop between two 
columns:
- the container would have "touch-action: none, trap-pointer-inside"
- the column containers would have "touch-action: trap-pointer-outside"
- the column containers would have pointerenter and pointerleave registered
- the items in the columns would have pointerdown registered (and it would 
register pointerup on the global container) 
Received on Wednesday, 20 August 2014 21:09:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:10 UTC