Re: pointerType extensibility

On Sat, Feb 9, 2013 at 12:29 PM, Rick Byers <rbyers@google.com> wrote:

> 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
> }
>

Since we probably only care about JavaScript, it's simpler and I think just
as powerful to define a set of boolean read-only properties on the event,
eg. PointerEvent.isMouse, PointerEvent.isTouch, etc.   Libraries should be
able to add their own for any events they synthesize, eg.
PointetEvent.vendorprefixDepthCamera


> Thoughts?
>    Rick
>