Re: Answers to questions in new points.js polyfill

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

Performance, I think. Better for developers to discover their app
doesn't behave as it should, and consciously make the performance
trade-off for correct behaviour, than to give their users a jankier
experience unnecessarily.

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

Very true, though I think CSS parsing needs a health warning as it can
fail in ways that are hard to debug (with Hand.js I got stuck because
my CSS had a touch-action property that was commented out... boy did I
feel dumb when I realised!)

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

Sounds like that should pretty much nail it, bar one small quirk (the
spec says pointerenter and pointerleave events should accompany
pointerdown and pointerup - they don't in Polymer). I don't think
there's anything wrong with redefining addEventListener.

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

No time like the present! Should underlying mouse/touch events have
their defaults prevented if preventDefault is called on a fake pointer
event? For example with Polymer, on an iPad, if I tap-hold on an
element that has touch-action='none' and a pointerdown handler that
calls preventDefault, the copy-paste helper appears because the
underlying event doesn't have its default prevented. Should it appear?
I'd expect it not to, even if the element doesn't have a 'user-select:
none' style, but I could be totally wrong about that.

>  It's probably only the browser native behavior we need to really worry about being perfect :-).

Yes! No point trying to solve the unsolvable, I agree that getting a
PEWG-approved 'good enough' polyfill is a more important goal.

Thanks,

Rich

Received on Saturday, 25 May 2013 14:27:44 UTC