W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2013

Re: Answers to questions in new points.js polyfill

From: Rick Byers <rbyers@google.com>
Date: Fri, 24 May 2013 13:48:18 -0400
Message-ID: <CAFUtAY8HM5RiGp59mJvwrfdmHyoVzsb=Pe=en_CYfJZ68SJT_w@mail.gmail.com>
To: Rich Harris <richard.a.harris@gmail.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Shoot I just realized I never finished sending my reply to this (I
blame Google I/O craziness) - sorry for the delay.

On Fri, May 17, 2013 at 6:17 AM, Rich Harris <richard.a.harris@gmail.com> wrote:
> Rick - many thanks for reaching out and for the clarifications. I've updated
> the readme with your responses. Great to learn that we can look forward to
> experimental support in Chrome soon.

Thanks Rich!

I'd also suggest updating your 'performance' section based on this
discussion.  You talk about the extra hit test in your approach, which
I agree is negligible and necessary for proper semantics.  But you
don't talk about the fact that your approach destroys threaded
scrolling for the whole page - that's the real performance issue here
(and as Daniel says, why he switched away from using that approach).
You can see the effect of this in action in a contrived example here:
http://www.rbyers.net/scroll-hit-test.html, and a wrote a bunch about
the issue here:
https://plus.google.com/u/1/115788095648461403871/posts/cmzrtyBYPQc.

> Daniel - it would be great to work towards a single polyfill, and it makes
> sense for that work to happen under the Polymer/Toolkitchen banner. Let me
> know what I can do to help.

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?  I haven't
looked at it in depth myself yet.  This perf/semantics trade off is
tricky, but I hope we can come to a reasonable compromise in most
cases, and then give the best of both worlds on chrome once we support
touch-action natively.

> You're right about the tradeoff being less than ideal. Ultimately I settled
> on that approach because I wanted something reasonably future-proof, and I
> find pointer(over|out|enter|leave) as defined by the PE spec more useful
> than what you get from proxying touch events - the performance penalty being
> the price you pay for using a browser that doesn't support PE. But your
> counter-argument is persuasive. I don't think there's a way to get the same
> effect without window-level touch handlers, but I'd love to be proved wrong!

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.

By the way, none of this should be taken as criticism of the great
work you've done with Points.js.  I think we (as the PE WG) should
make polyfills more of a priority - it's going to take a lot of
experimentation to come up with the right set of tradeoffs to both
push adoption of the standard forward and also be a practical useful
tool for web developers today.  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).

Thanks!
  Rick
Received on Friday, 24 May 2013 17:49:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC