Re: Answers to questions in new points.js polyfill

On Fri, May 24, 2013 at 6:48 PM, Rick Byers <rbyers@google.com> wrote:

> Shoot I just realized I never finished sending my reply to this (I
> blame Google I/O craziness) - sorry for the delay.


No worries - was flattered to see Points.js on your slides!

I'd also suggest updating your 'performance' section based on this
>
discussion.


Good idea - done. Thanks for the detailed explanation, it's very useful.


> Other than the issue with the targeting model (events not firing if
> you start on an element which doesn't have a handler), are there other
> areas you see for improvement in the Polymer polyfill?


The interpretation of touch-action. You stated earlier that pointer events
'should always fire up until the point a browser action
starts (at which point you should get a pointercancel event)' - in the
Polymer polyfill, elements with a touch-action="auto" attribute don't
receive events at all, which means you can't detect pointerdown on
scrollable elements. That's probably okay in a lot of situations, but by no
means all.

(I realise it's cheeky to point this out when Points.js makes no attempt to
deal with touch-action!)

Maybe it's not unreasonable to ask developers to indicate somehow
> (perhaps just a pointerdown handler - even if it's empty, or maybe
> there should be a separate 'enable-pointer-events-touch' flag) which
> parts of the page the want to allow touches to start on and eventually
> become pointer events.  Developers can always set this on the entire
> document if that's what they want.  But it would be nice to push this
> trade-off to the app developer.


That's definitely worth exploring. There'd still be room for confusion
around (for example) touch events that originated outside the designated
zone but ended up inside it, though I guess that's just a question of
decent signposting.

In the same spirit of allowing developers to make informed choices, maybe
offering a choice of performance-first (the Polymer approach) versus
spec-first (the Points.js approach) is the proper thing to do, as long as
developers are made aware of what they're choosing between.

As an aside, there's a significant overlap between a) times I would have
liked to use pointer events and b) times I didn't care about scrolling
performance, because scrolling was disabled anyway. I'm talking about
(excuse gross over-simplification) 'apps' rather than 'documents' - the
'hello world' finger painting app being an example of where you don't care
about scrolling performance, but see also games, dashboards, interactive
data visualisations, etc, etc.


> I'm excited to see interest in
>
 polyfills in the community - hopefully we can work together to get to
> the point that we have one (or more) that we can highly recommend for
> use in production (while acting as a faithful step towards native PE
> implementations).
>

You bet! Devs are chomping at the bit for this stuff.

Cheers,

Rich