Re: Answers to questions in new points.js polyfill

Yeah, I think touch-action auto is a pretty easy add.
As for enter/leave, they're in sort of a half finished state right now. I
was proving out the concept before I/O, but never got around to finishing
it.
The only problem with addEventListener hook is making sure the polyfill
runs before anything else calls addEventListener.
The contextmenu probably should be prevented in touch-action: none. I'm not
100% sure that all the proper hooks are provided, but shouldn't be too hard
to investigate.


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

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