Re: Blink does not plan to implement pointer events

On Fri, Aug 15, 2014 at 12:47 PM, Olli Pettay <olli@pettay.fi> wrote:

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

Absolutely.  'rationality' is one of our three pillars
<https://docs.google.com/a/chromium.org/presentation/d/1WwS5wPfZAJuWmhULVhTBRZV4UaBShslPlUnoR8AwWco/edit#slide=id.g1d70d4b6a_063>
(along with performance and richness) for how we're trying to improve input
behavior.  There's some debate on whether touch lists or independent
touches are better (if you recall I think the Yandex folks argued that the
pointer event model was a step backwards in this regard), but I personally
tend to agree that the independent model is saner.  More importantly
though, the pointer event spec does a very good job of precisely defining
all sorts of behavior that's left implementation-defined by touch events.
 This is the biggest barrier to rationality as far as I'm concerned - not
something that libraries can easily paper over.  This is one of the main
reasons this debate has taken so long - rationality and multi-vendor
co-operation on their own provide a lot of justification to do pointer
events.  But ultimately we felt the rationality problem was something we
could adequately (though not perfectly) address if there was any interest
in continuing work on the touch events spec.

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

It's not just that it's heavy (talking with Jacob it appears we have about
the same hit testing costs as IE - roughly 2% of the 16ms frame budget).
 There are certainly ways we could improve it, but at the cost of
additional complexity that could be spent on improving perf elsewhere.
 Developers tell us that performance is the #1 reason they choose native
mobile platforms over the web (which is the #1 problem we're trying to
tackle).  As such we're essentially unwilling to make any new design
choices which put the web at an inherent performance disadvantage relative
to Android and iOS native platforms.

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

The principle we're trying to follow is to extrapolate from today's trends
that show touch screen devices (mainly phones) are beginning to dominate
internet usage.  We may be wrong, but we imagine that in 5-10 years from
now mouse* events (but not higher level events like "click" etc.) will be
largely irrelevant.  I.e. the mouse scenario should be 2nd class to the
touch one, not the other way around that we have today (and which pointer
events is, to some extent, designed around).


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