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

Spec feedback

From: Alex Russell <slightlyoff@google.com>
Date: Tue, 12 Feb 2013 15:27:45 +0000
Message-ID: <CANr5HFW=yc6xZjOkgdt-wB8JviSPhWUu89K0Hcf_XYh4cqzsYQ@mail.gmail.com>
To: public-pointer-events@w3.org
Cc: Rick Byers <rbyers@google.com>, Tab Atkins <tabatkins@google.com>
Hi all,

I had a chance to sit down with Rick Byers while he's been visiting London
and review the current draft of the spec from a JS/layering perspective.
What follows is are non-linear comments from the discussion.

   - The spec should lead with examples, i.e., move Section 9 to where
   Section 2 is now.
   - pointerId is very strange. 3.1 suggests that mouses must have an ID of
   1, but there's no other reasonable scenario for using integer values (what
   does zero mean? 30?). Having an opaque object instead feels like it'll
   satisfy the needs for identity comparison and for passing through to
   - I'm concerned about the extensibility storay (see below for a related
   discussion of the layering question): if someone plumbs a new, exotic type
   of input device through an OS and browser to the page, it's natural for
   pre-standards additions to the ecosystem to want to pass extra metadata
   along. The current spec doesn't have an advertised slot for "extra metadata
   goes here!". This is dangerous in the long-run as it suggests that the
   objects/events either shouldn't be extended (likely wrong) or extended on
   the event object directly, creating naming collision hazards later. I'd
   like to see an extraData slot specified on these event objects,
   defaulting to null, that can be used for this. When new pointer types
   become prevalent, this group can observe fields from these objects and
   standardize them in the primary event object.
   - The buttons field is painful as bitfield math is anything but natural
   in JS. That it's pre-existing on MouseEvent seems the only virtue.
   Consider this a note that users are likely to cringe, not an objection or
   - The new touch-action CSS property seems to have conceptual overlap
   with the pointer-events
   If nothing else, the naming (and explicit callout to "touch" in the naming)
   creates huge ambiguity. Anyone who wants to allow some clicks through, but
   not dragging, is likely to find themselves wading through multiple
   properties who interaction is ambiguious at best. I haven't though hard
   enough about this to know if the properties can (or should) be merged, but
   it seems like an exercise the WG should attempt, if only to identify a
   strong argument against merging them.
   - navigator.maxTouchPoints seems deeply touch-specific. Also, is it
   dynamic? If I plug in a touchpad that support 5 or 6 (and I've only had 1
   or 2 before), what (if anything) happens? Also, isn't this a fingerprinting
   risk? Why not make this a property of the events to solve both?
   - Section 8 makes me terribly nervous that, for all the clarity in the
   introduction about the event funnel in the introduction, the WG does not
   have  firm conceptual model for wether or not the spec is describing a
   high-level or low-level event source. In particular:
      - Synthesizing mouse events, while possibly a reasonable thing to do
      in an event sink like the implicit controller that Pointer
Events defines,
      seems to imply that mouse events are not a lower-level event type out of
      which pointer events are created.
      - The hover generation in 8.2 is particularly disturbing. If pointer
      events are conceptually a high-level synthesis of lower-level
event sources
      (a filter, if you will), then perhaps there is room to generate
      (synthesized) mouse events, but the MouseEvent spec conflates very
      low-level events (down, move, up) with high-level synthesized events
      (click, enter, out). To get some sanity here, splitting mouse (and other
      types of pointer) events into low-level synthesized events and
      how pointer events layer into this world seems like the only reasonable
      thing to do.
      - We may need to continue to specify that pointer events syntesize
      other sorts of events, but it should be possible to generate low-level
      events in JS and have Pointer Events synthesize these events for them too.

Received on Tuesday, 12 February 2013 15:28:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:24 UTC