W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2013

pointerType extensibility

From: Rick Byers <rbyers@google.com>
Date: Sat, 9 Feb 2013 12:29:03 -0500
Message-ID: <CAFUtAY8T-BZqux0m0qX2mzxbqa6+8qWa0vFTVNtbRpvFX5GeaQ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:17:04 GMT