- From: Rick Byers <rbyers@google.com>
- Date: Sat, 9 Feb 2013 12:29:03 -0500
- To: public-pointer-events@w3.org
I know we've talked about the extensibility of pointerType (eg. http://www.w3.org/2012/12/11-pointerevents-minutes.html), but I'm concerned we haven't really thought through the implications. I just finished the EdgeConf input session (http://edgeconf.com/), and (in addition to general support for pointer events) two big takeaways for me are: 1. There is excitement around potential future input technologies and mapping to pointer events (eg. leap motion) 2. People see the emulation of mouse events from touch as a huge pain - often going as far as to say "it's a complete failure", and "the browser shouldn't lie to me". I like to think that pointer events solves this problem going forward (although looking back we still have to emulate mouse and probably touch events). But working through the details, I'm frightened that we may still end up repeating the same mistake. Eg., imagine there's some new input type which developers really need to distinguish from touch/mouse/pen for some reason - it would send pointer events with a new pointerType string, and perhaps add some new fields to the events. But do we really think this is going to work well enough with existing code deigned, eg. for touch/mouse? Jacob, have you tried using existing pointer-event sites with a new pointerType value to see how they respond? I'm concerned that when the time comes, implementors will find that the only reasonable option is to use one of the existing pointerType values for maximum compatibility with existing code. Eg., a 3-d motion tracker may want to set pointerType="touch" so that ALL touch-based websites can be used. Then maybe they'll feel compelled to repeat the pattern again of dispatching a new event type that sites can opt into when they really want to know about the new input type. This has happened twice already (once for touch, once for pointer) and is already a huge pain and implementing a browser that handles the full combination when N=3 is going to be hard and incomplete. If we cause this to happen AGAIN (raising N to even just 4), I think we will have made a HUGE mistake for the web. Maybe we could mitigate this with some sort of compat knob that allows a site to indicate the pointer types it supports (eg. if the site says it supports 'depth-cam' then use that pointerType, otherwise lie and use 'touch' for compat). But this will break down in composition scenarios (libraries, perhaps iframes, etc.). Another option would be to replace the pointerType value with an extensible collection of booleans. Eg., maybe a 'isPointerType' function that takes a string and returns a bool. Depth-cam aware code would be written like: if (e.isPointerType('depth-cam')) { ... light up additional 3-d features } else if (e.isPointerType('touch') { ... definitely a non-depth-cam touch device } Thoughts? Rick
Received on Saturday, 9 February 2013 17:29:51 UTC