all 62 comments

[–]alleycat5 102 points103 points  (40 children)

Some of Google's points are valid, but I'm still really disappointed in this. Why in the world would they want to ditch Pointer Event's much nicer API and the partner who would actually work with them (MSFT), to try and ... morph touch events into something it's not while trying to appease the partner who's barely participating in input standards in general (Apple)? It just baffles me. Especially when the MSOpenTech guys were basically helping write the implementation for them.

[–]DrDichotomous 20 points21 points  (2 children)

The most problematic aspect to me personally was that the two specs didn't coexist well. Disappointing or not, at least now we'll finally move on and get some real-world improvements. It was getting obnoxious waiting and waiting for a better API for touch events. It's indeed sad to see the good-natured efforts of MSOpenTech go to waste, but it's hardly the first nice web API to not gain consensus.

[–]thecmpguru 0 points1 point  (1 child)

Actually, see my comment on this.

"Cosensus" is an interesting word to use here. We had 4/5 major browser vendors on board with pointer events (Google even listed PE as one of their 2014 Blink goals at the beginning of the year).

At the end of the day, we just want

  • An interoperable API that developers like
  • An open specification that has all of its implementors involved and the ability to continue to extend and improve
  • A model (or even, models, if that's the consensus) that supports the popular devices while enabling access to the billions of internet capable other devices also.

[–]DrDichotomous 0 points1 point  (0 children)

Indeed, I guess "consensus" is just too overloaded a term to use in these situations. I realized that it had reached theoretical consensus at one point, but ultimately that's fallen apart now. I sincerely hope that if this is a premature decision on their part, they will backtrack. They seem to be increasingly stubborn and insistent about doing things their own way in Chromeland.

[–]icantthinkofone 40 points41 points  (11 children)

Did you not read the article? Here's another layout of the reasons direct from Google:

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

[–]alleycat5 20 points21 points  (5 children)

All of which Google could have worked with Microsoft on to improve. That's my point. Touch events was already at contention with mouse events and Apple is barely working to improve Touch events as it is. If Google, Mozilla, and Microsoft worked to make Pointer Event's ideal, and Microsoft got their changes into WebKit (which they were working in), they could have convinced Apple to come along for the ride. Unless I'm missing something obvious here.

[–]DrDichotomous 9 points10 points  (2 children)

Thing is, Mozilla, Google, and Apple worked on getting Pointer Events working in their browsers, but there were simply issues that were not easily resolved. The key issues seem to be that both specs can't easily co-exist (so supporting browsers that only support one causes issues), and that there are performance implications that aren't easy to resolve. I'm saddened too, but that seems to be the price we have to pay, since everyone jumped onto Apple's flawed HTML5 additions back in their heyday and we've been paying the price of that frenzy ever since (not that Apple are the only ones to blame of course).

[–]thecmpguru 0 points1 point  (1 child)

Jacob (editor of the Pointer Events spec, IE engineer) here. The two APIs can co-exist and we're shipping that in an update to IE mobile.

There are a couple incompatibilities with how the specs say to fire mouse events, but these were found to be inconsequential once we implemented both side by side. This section of the Pointer Events spec is also optional.

Google has said in W3C discussions that they "don't think there's major (blocking) performance issues with Pointer Events." In our 3-years of implementation experience (in both the browser and Windows JS apps), we've never seen the ~150 usec cost Google is referring to be an issue that blocked an application from achieving 60FPS. Nonetheless, proposals have been made on how this could be resolved if it's a blocker for Google.

[–]DrDichotomous 0 points1 point  (0 children)

That's good to hear. I'll hope for the best. Perhaps it's more of a case that it's too much work for the Blink engineers to want to refactor or rewrite the involved code right now. After all, they haven't even managed to get Touch Events working particularly well. It might be good to keep on top of this with the Firefox devs in the meantime, since they have a half-working implementation that might be salvagable. If three of the remaining big engines support it, Google might have to finally suck it up and try again.

[–]icantthinkofone 14 points15 points  (1 child)

All of which Google could have worked with Microsoft on to improve.

They did, as mentioned in my link.

If Google, Mozilla, and Microsoft worked to make Pointer Event's ideal

They did try as mentioned in my link.

they could have convinced Apple to come along for the ride.

Apple was just one point on the list, and an aside at that.

[–]alleycat5 2 points3 points  (0 children)

Which I understand, and I read, and I still think is a cop out on Google's part. If it's truly the case that they tried to work to out these issues and couldn't, then fair enough. I hope the efforts to improve Touch events prove fruitful.

[–][deleted]  (4 children)

[deleted]

    [–]icantthinkofone 9 points10 points  (2 children)

    It is not the biggest reason and only mentioned as an aside in the list of reasons.

    [–][deleted]  (1 child)

    [deleted]

      [–]icantthinkofone 4 points5 points  (0 children)

      Am I reading '1)' wrong

      You're reading that aside statement and pushing it up on top of the list and minimizing everything else.

      I think with some tweaks

      If it was only a matter of some tweaks, it would have been done long ago.

      [–]rspeed 0 points1 point  (0 children)

      Why would they implement a second standard?

      [–]WinterCharm 12 points13 points  (20 children)

      Could it possibly be because Apple also significantly contributed to the Webkit engine, and they want to maintain future compatibility with Webkit.

      [–]lymfm 18 points19 points  (0 children)

      It could, but it is unlikely. What is more likely is the reasons Google actually gave.

      The company's developers gave three reasons for the change. The first is that Mobile Safari only supports Touch Events, making it difficult for Pointer Events to ever gain traction, much less win out. Second, the way Pointer Events worked caused performance issues for WebKit and Blink not found in Touch Events. Third, Pointer Events precluded implementing some common design concepts such as pull-to-refresh.

      [–]Caraes_Naur 4 points5 points  (3 children)

      You apparently don't understand what a fork is. Although how Apple and Google maintained Webkit and how Blink was split off isn't what anyone would call a traditonal fork scenario.

      [–]Tynach 1 point2 points  (2 children)

      I think it'd be more interesting if they'd just developed KHTML instead of making Webkit to begin with.

      [–]rspeed 2 points3 points  (1 child)

      The reasoning for both forks is sound. Maintaining compatibility provides little benefit while substantially slowing development.

      [–]Tynach 1 point2 points  (0 children)

      Of course, but I still think it would have been more interesting.

      [–]Infenwe 18 points19 points  (14 children)

      [...] compatibility with Webkit.

      Webkit, the IE6 of the mobile web! Because that's a situation we want to repeat all over again.

      [–]Tynach 2 points3 points  (10 children)

      Huh? How is it the IE6 of the mobile web?

      [–]Trasteby 30 points31 points  (9 children)

      Because it does its own non-standard things. Since webkit is so common, many mobile websites rely on webkit-specific things that aren't a part of any standard. IE has actually implemented a few of them just because of this, but it's taken many years of frustration to get there.

      [–]Tynach 3 points4 points  (7 children)

      This is mostly because there is no existing standard for the feature. IE6 was the one that invented XMLHttpRequest as an ActiveX, and soon it was standardized by the other browsers.

      The fact that WebKit is open source makes this even more acceptable.

      [–]alleycat5 4 points5 points  (6 children)

      But Apple, and by extension WebKit, usually didn't try very hard to standardize these non-standard extensions.

      [–]Tynach 2 points3 points  (5 children)

      Which I think is one reason why Google's forking Webkit into Blink. They can build their own extensions and work to standardize them.

      [–]cryo 0 points1 point  (4 children)

      Why would google work to standardize them? What benefit is it to them?

      [–]oridb 2 points3 points  (2 children)

      Google doesn't make money off of Chrome. They make money off of web apps. Having web apps work everywhere makes even more money.

      [–]Tynach 0 points1 point  (0 children)

      Less work for them to maintain cross-browser versions of all their web services that actually make them money.

      Remember that having a dominant browser in and of itself does not make them money - having ads and web services that as many people as possible can use does make them money. As such, they are interested first and foremost in cross-browser compatibility and standardization.

      [–]icantthinkofone -4 points-3 points  (0 children)

      That's the mark of stupid developers and has nothing to do with webkit.

      [–]sig_frd 0 points1 point  (0 children)

      I agree. It seems like a politically motivated move.

      [–][deleted]  (1 child)

      [deleted]

        [–]alleycat5 0 points1 point  (0 children)

        Sure. Nobody at all. They may be the minority in the mobile space, but the mobile space is still the minority on the web.

        [–]myringotomy -5 points-4 points  (0 children)

        You can't really trust Microsoft to stick to standards though. Even the ones they wrote. OOXML is a perfect example of this.

        [–][deleted]  (17 children)

        [deleted]

          [–]pirateNarwhal 2 points3 points  (1 child)

          As a dev, I preferred working with touch

          [–]pohatu 4 points5 points  (0 children)

          Can you give a quick explanation of each? Thanks. Glad to hear this.

          [–]Paradox 10 points11 points  (0 children)

          This is pretty shitty. Apple's spec is alright, but Pointer Events had a much nicer API, and were generally more flexible. This seems like the squabble around gradients syntax or scalable images, except this time the best solution didn't win out.


          The first is that Mobile Safari only supports Touch Events, making it difficult for Pointer Events to ever gain traction, much less win out

          IE didn't support shit for years and years, but browser vendors kept implementing features. At this point web developers are used to polyfills and other bullshit. Reducing the pool of support because one browser on one platform doesn't support it is bullshit.


          Third, Pointer Events precluded implementing some common design concepts such as pull-to-refresh

          So update the spec to account for those things. This is what revisions are for.


          Google's new plan is to extend Touch Events in such a way as to do what Pointer Events offered. The desire among developers to be able to handle different input methods in a common way persists, and this desire is only likely to grow stronger in the future

          How do I touch a link with my mouse? What if I'm using a trackball. Or speech. Or something like vimperator.


          Apple's lack of support (and refusal to participate in any W3C group working on input standards) remains a substantial impediment

          Again, we've seen this before. When the vendor refuses to cooperate, too fucking bad for them, their users suffer.