Re: Blink does not plan to implement pointer events

On 21/08/2014 01:29, Arthur Stolyar wrote:
> * Firefox plan to support both Touch and Pointer events.

I'm actually wondering now what the current and future status of this 
is. From what I remember, the plan was to only do this for Metro (or 
whatever the new canonical name for this is in Win8). If I'm not 
mistaken, Fx does not even support touch events yet (unless you enable a 
special about:config flag) on touch-enabled desktops/laptops.

Any official word from Mozilla on whether the Blink decision will also 
affect their plans?

> * IE on desktop (Win 8 +) support PointerEvents
> * IE on mobile (Win 8 +) support both Pointer and Touch events

Although I understand the rationale for not adding touch events to 
desktop (due to exactly the same problem that Chrome had of sites all of 
a sudden breaking on desktop/laptops, assuming touch-only and killing 
off mouse/keyboard support in the mistaken assumption that touch support 
means it's ONLY touchscreen, which lead to Chrome doing sniffing on 
startup to determine if there is indeed a touchscreen present, and only 
exposing the touch feature in that case), this to me is also a weird 
fragmentation in what is nominally the same browser. It's certainly 
going to be an interesting challenge to explain this rationally to devs 
("yes, you can now use touch events in IE. oh, but not on touch-enabled 
Win8, only WinPhone8...").

On the wider issue, I'm still having a hard time getting a full handle 
on the decision. From what I see:

- there is a lot of existing content out there using touch events
- developers won't update their old sites to use pointer events
- pointer events can't adequately be polyfilled on touch-events-only 
devices (in certain scenarios anyway, where no pointer capture is expected)

These arguments sound to me like they could be applied to ANY new 
technology. If those were the only ones driving a decision, we'd be at a 
technological standstill. For instance, try to apply those points to 
something like the new shiny ServiceWorker spec...

Then there are arguments related specifically to the spec itself and how 
it fails:

- there is a potential performance cost in implementing pointer events 
as currently specified, due to expensive hit testing/boundary checks
- making setPointerCapture opt-in rather than opt-out (see for instance 
[1] and [2] - whose tone does rub me the wrong way but has some nuggets 
of actual useful critique)

These could, in my mind, be ironed out by amendments/tweaks to the 
pointer events spec itself (maybe I'm just naive here?)

Which, to be honest, leaves me with the one rationale that can't be 
routed around:

- WebKit has no intention of implementing pointer events

which, due to iOS, means that most devs (at least those devs that aren't 
crazy enough NOT to support iOS) will still have to actually use touch 
events. And yes, at that point, it makes little sense from a development 
point of view to also do double-duty and replicate the same 
logic/handling in pointer events.

Sorry, just semi-ranting here. I'd still be interested in some offical 
Mozilla positioning on the matter.

[1] 
http://webreflection.blogspot.co.uk/2014/05/touch-events-for-ie-mobile.html
[2] http://webreflection.blogspot.co.uk/2014/08/pointerevents-no-more.html

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Thursday, 21 August 2014 09:36:03 UTC