Re: Answers to questions in new points.js polyfill

As the primary author of the Toolkitchen PointerEvents polyfill, I'd be
delighted to pool my efforts into a grand unified polyfill. I think
points.js is a great start, and I applaud the author for leaping into the
fray, but there is room for improvement.

One big tradeoff that points.js makes is that it installs touch handlers on
the window. This will generate all the events for touch-action: auto the
way Rick expected for his demo, but can disable optimizations for
composited scrolling on all scrolling regions (at least in Blink).
For Toolkitchen, I opted to break compliance there for the sake of being
able to install the polyfill in any arbitrary document (or in a Web
Component that resides in said arbitrary document), and not degrade
scrolling performance on regions not interested in Pointer Events.

Another point to note is that currently, no polyfill other than Toolkitchen
will work with ShadowDOM. This is because our team is working heavily on
Web Components, and polyfills thereof, but it stands to reason that a
unified polyfill should support ShadowDOM as much as possible to be future
proof.
Perhaps that goes without saying, but I felt like I needed to state it :)





On Wed, May 8, 2013 at 10:53 AM, Rick Byers <rbyers@google.com> wrote:

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