Re: Blink does not plan to implement pointer events

On 08/15/2014 06:45 PM, Rick Byers wrote:
> We've discussed on our conference calls the progression of the blink team's thinking around pointer events as it developed over the past year and a
> half (with conclusions mostly recently <http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0118.html> after the web-input
> face-to-face).  But I realized I should send a clear announcement to this list for people that haven't been following the meeting notes.  I've now
> officially marked support for pointer events in blink <https://code.google.com/p/chromium/issues/detail?id=162757> as WontFix with the below note.
>
> I apologize that we didn't have the foresight to see where this would lead when we started down this pointer events journey together 2 years ago.  The
> main shift in thinking for us has been from a position of a desktop-dominated web evolving slowly to enable mobile scenarios, to the realization that
> phones/tablets will soon dominate Internet usage and that the web is loosing to native mobile platforms.  I've tried hard to be completely transparent
> on our thinking as it evolved, and I really value all that we've learned and the relationships we've built.
>
> I plan to continue to participate in the working group, as the problems we're trying to solve are essentially the same regardless of the specific form
> of the API and we have at least the touch-action API in common.  I hope it goes without saying that this decision reflects only a difference in
> technical opinion about what's best for the long-term health of the web platform. The blink team continues to be deeply committed to evolving the
> platform only through the collaboration of multiple browser vendors and the web standards process.  We have deep respect for the work Microsoft has
> done here, and I'm optimistic that we will find a way together to leverage the advancements in input API design without the drawbacks of introducing a
> new event model (I'll start a discussion of one possible path on the public-touchevents list shortly).
>
> Thanks,
>     Rick
>

Curious, did blink folks evaluate the API sanity at any point. To me the model pointer events API has is way better and simpler than the
awkward model touch events API has (with its various touch lists etc.)


(It is also surprising to me that the hit testing is so heavy in blink that (2) in the bug report matters.)


(1) is a bit frustrating. We shouldn't have "XXX first web", but just web where things should, as far as possible, just work on
all the devices. It is possible that we'll end up now to a situation where mouse events need to be mapped to touch events on desktop, and vice versa
on mobile. That model is complicated and error prone. ( I could have imagined pointer events to be the model in 5 years or so. )




-Olli


> ---
> After tons of debate and discussion, with lots of great input from our friends on the IE, Firefox and Safari teams, we've decided that incrementally
> extending our existing input APIs (see issue 404128 <http://crbug.com/404128>) is a better path forward for blink (and, we believe, the web) than
> adopting pointer events.
>
> See a summary of our position here:
> https://docs.google.com/a/chromium.org/presentation/d/1qRqLKQjOnGgrM-UkMAb2RH6mQCFQHk8R01s5qvjm2Po/edit#slide=id.g355c5631f_134
>
> Very briefly, pointer events has 3 main drawbacks relative to the alternative:
>
> 1) Mobile-first web:
> Pointer events would likely never supplant touch events on the web (especially without support from Safari).  Since touch events are here to stay,
> supporting another largely redundant input model has a high long-term complexity cost on the web platform.
>
> 2) Performance:
> The hit testing model required by pointer events imposes a non-trivial performance penalty (hit test on every movement event) that neither Android,
> iOS or touch events has.  We're not willing to add any feature that increases the web's performance disadvantage relative to native mobile platforms.
>
> 3) Richness:
> Pointer events requires that scrolling and event handling are mutually exclusive.  This precludes some UI effects which are common on on mobile
> platforms (eg. pull to refresh).  Recently strong developer feedback has lead us to change Chrome in the opposite direction here - enabling event
> handling while scrolling (see  issue 293467 ).
>
> We're committed to working in the web standards community to improve input on the web, and we especially value the relationship we've recently built
> up with the IE team here.  Despite this difference in technical opinion on what's best for the web, I'm optimistic that we'll still make good progress
> together.
>
>

Received on Friday, 15 August 2014 16:48:58 UTC