Answers to questions in new points.js polyfill

The new points.js polyfill Jacob mentioned (
https://github.com/Rich-Harris/Points#readme) looks very interesting.  I
like that he's attempting to better conform to the semantics than the
existing polyfills (both hand.js and the ToolKitchen one failed for me in
different ways for a very simple demo I was trying to do -
http://jsbin.com/ucixot/2/edit).

The one downside to this polyfill is that he makes no attempt to support
touch-action (which is a major part of the spec IMHO).  He makes a good
argument though - that there's no good way so it's better not to try and
only get halfway.  On a related note, we as browser implementers really
need to figure out how to allow CSS polyfills - eg. allowing JavaScript to
somehow get access to or modify the behavior of the CSS parser.  I'd be
interested in discussing this separately (probably with CSSWG) if anyone
else wants to do some brainstorming here.

FWIW, I think a conformant high-quality polyfill is going to become
increasingly important in our attempt to get PE supported broadly across
browsers.  I'd like to chat more about this in our next call.

Anyway, in the points.js readme he asks the following questions of us.
 I'll reach out to him on Twitter and ask him to join this thread.  I've
 briefly put my understanding of the answers to his questions below, but
feel free to chime in with corrections / better explanations.  Perhaps
these also represent opportunities to improve the wording/clarity of the
spec (sorry I'm not making specific proposals here)?

> Can touch-action: auto override a touch-action: none property applied to
an ancestor?

touch-action isn't inherited, so it's not necessary.  A child automatically
gets touch-action: auto behavior for itself.

> Should pointer events fire at all in a touch-action: pan-x situation, or
should they only not fire if the user is in fact panning horizontally?

Pointer events should always fire up until the point a browser action
starts (at which point you should get a pointercancel event.  So for pan-x,
I'd expect to see pointerdown when the finger touches, some number of
pointermove events, then if the user moves far enough in the x direction to
trigger a pan, a pointer-cancel.  Instead if the user moves in another
direction I'd get all pointer events (and no panning).

> It's not at all clear how you're supposed to listen to button changes.
The spec says 'Pointer Events do not fire overlapping pointerdown and
pointerup events for chorded button presses ... Instead, chorded button
presses can be detected by inspecting changes to the button and buttons
properties'. Inspect how?

The spec says that pointermove must be fired when the button state changes,
so that's where you can detect a change.

Rick