Re: Answers to questions in new points.js polyfill

On Sat, May 25, 2013 at 4:11 AM, Rich Harris <richard.a.harris@gmail.com>wrote:

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

Yeah, this has been a barrier  for me too.  Daniel, there's no reason why
we couldn't handle touch-action="auto" as well, right?  You definitely
still want people to opt-in, and we'd have to be clear that 'auto' has perf
implications for scrolling (but no worse than touch events do already).

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

Yeah, I don't see any other option (for today's browsers) really.  The
choice of default would be interesting though - do we make it easiest to
use the simple model with perf implications, or the fast model with
confusing over/out implications ;-).

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

Yeah.  And actually if we're really going spec-first, then the hand.js
approach to trying to support touch-action (downloading/parsing CSS etc.)
might also be warranted.  If the different approaches require enough
different code then this may be best achieved by recommending different
polyfills which each have different goals.  But hopefully we can get one
polyfill that covers a pretty broad set of the scenarios.

Eg., if we support touch-action=auto in Polymer, then putting
touch-action=auto on the document (to enable pointer events that start
there) should make its semantics pretty close to points.js (i.e. no
confusing over/out behavior since touch handlers are on the document),
right?  Or is the addEventListener hook still a problem?

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

Yes, that's a good sign.  It'll be easy to get caught up in the detailed
semantics issues (eg. we haven't even talked yet about how to get the
correct semantics of preventDefault on pointer events), but I think it's
clear there's already a lot of value to having polyfills that are just
"close" to the specified semantics.  In many common scenarios the
differences won't be noticed.  It's probably only the browser native
behavior we need to really worry about being perfect :-).

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
>