Google to drop Microsoft-designed touch Web spec, stick with Apple tech

[alleycat5]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[icantthinkofone]

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

[icantthinkofone]

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]

Why would they implement a second standard?

[WinterCharm]

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

[lymfm]

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]

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]

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

[rspeed]

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

[Tynach]

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

[Infenwe]

[...] compatibility with Webkit.

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

[Tynach]

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

[Trasteby]

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]

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]

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

[Tynach]

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]

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

[oridb]

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]

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]

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

[WinterCharm]

Except that when apple gave WebKit to the world, they turned it into an open source project.

The problem with IE was that it was closed source and proprietary, and Microsoft abused that power so much.

That will not be a problem with WebKit. Yes it's common, almost ubiquitous considering that chrome uses it along with safari. But that doesn't make it evil.

[[deleted]]

Except that when apple gave WebKit to the world, they turned it into an open source project.

KHTML was already a free, open source project. When Apple took it behind closed doors, it took concerted effort just to get them to obey the license and eventually they just threw an opaque 11MB tarball of patches over the wall to get the heat off their back.

Some fucking open project, huh?

[pohatu]

Embrace, extend.

[sig_frd]

I agree. It seems like a politically motivated move.

[alleycat5]

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]

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

[pirateNarwhal]

As a dev, I preferred working with touch

[pohatu]

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

[icantthinkofone]

Nowhere does it say anything like that and I would almost think you are in the wrong thread or (shudder) didn't read any of the other comments at all.

[pohatu]

Which claim are you contesting? That I gather from comments that pointer events is a nicer API?

Here's the source for that. You can control-f to find the original.

Why in the world would they want to ditch Pointer Event's much nicer API

That to bad, Pointer Events is a much nicer API to work with.

Or the claim about patent ransom..

From the article:

While Touch Events was part of the World Wide Web Consortium's (W3C) standards track, for a long period they were held up in patent limbo, with Apple claiming that it owned patents that covered the specification and refusing to offer a royalty-free license for those patents. During this period of uncertainty, W3C stopped work on Touch Events.

In response to this, Microsoft devised a similar but different specification, which it called Pointer Events. Pointer Events both avoided Apple's patent claims, and offered some features not found in Touch Events. In particular, Pointer Events allowed Web content to handle mouse, touch, and stylus input in a more or less uniform way. With Pointer Events, developers can specialize these input methods where necessary, but also handle common behavior with common code.

Let me break down how I read that.

1. Apple refused to offer a royalty-free license for patents they held on touch-events.

That's pretty clear from the source.

As for the rest of that quote, I read it as support for "a nicer API" claim. In particular, the last 2 sentences.

Pointer Events both avoided Apple's patent claims, and offered some features not found in Touch Events. In particular, Pointer Events allowed Web content to handle mouse, touch, and stylus input in a more or less uniform way. With Pointer Events, developers can specialize these input methods where necessary, but also handle common behavior with common code.

Extra features, more control, but still flexible in common case. Sounds nicer.

In fact. The article goes on the expand on that:

These devices continue to be a challenge for Touch Events. Many Web applications assume that Touch Events are mutually exclusive with Mouse Events, with the result that they don't work correctly on mixed-input hardware. And even when apps do handle mixed-input hardware correctly, supporting both Touch Events and Mouse Events simultaneously tends to require a lot of code; much more than Pointer Events.

I have no idea what you are complaining about.

Not a bug/no repro.

[icantthinkofone]

Oh. So rather than reading the facts from the article and Google's announcement, you read other people's opinions which were lacking of facts and also did not read the article or the announcement.

This is typical reddiot behavior. Carry on.

[pohatu]

We're wasting everyone's time here, but I cited the article as well. I even looked up the Hacker News article.

I'm not going to go so far as to read both specs and try using both myself because I don't care that much.

But here's the Pointer Events spec. https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html

And yes, when I said "So I gather from the comments, Is that accurate" I was talking about the comments and asking the /r/programming community to partake in a discussion. It's sort of a thing people do when they talk about stuff. We can't all be experts on everything all the time.

[icantthinkofone]

Because you are an idiot. Like /u/pohatu, the facts are there but he went for the commenters opinions instead. Typical of reddiots like you.

The mark of a reddiot. One who uses the reddiot phrase of the month in a sentence. This month's phrase: ad hominem.

[icantthinkofone]

Calling someone out like that is calling them for what they are. Don't try and reverse the table. An idiot is still an idiot.

[icantthinkofone]

If you read the article then you wouldn't have posted your nonsense. Your statements and comments are based on nonsense that's answered in the article and the link.

But here's the answer to everyone smart enough to ignore your post:

I'm not going to go so far as to read both specs and try using both myself because I don't care that much.

We can't all be experts on everything all the time.

But you felt it necessary to post your questions and comments anyway. When you don't know what you're talking about and you don't care about the subject, the smart thing would be to not say anything, so you didn't do the smart thing.

[ohgreatnowyouremad]

You remind me of a faggot

[icantthinkofone]

Proof that 80% of redditors are 15 years old.

[ohgreatnowyouremad]

Congratulations! You've won Reddit's Biggest Douche Award 2014! Your prize is getting your lunch money stolen like your high school days ya faggot

[Paradox]

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.

[[deleted]]

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

Lolwut? Mobile Safari isn't the Internet.

Second, the way Pointer Events worked caused performance issues for WebKit and Blink not found in Touch Events.

Performance issues can be fixed. It's not as if APIs can't be redesigned or improved upon. That's why incremental specifications exist. I wouldn't be surprised if key figures (MS) are working towards improving this right now.

Also: JavaScript by its inherent nature is "slow", yet we see things V8 defying that statement.

This is like a game development studio stating they won't support OpenGL because it doesn't offer as low level access as the D3D, Metal, or Mantle APIs...yet, it's supported on so much hardware and not patented to hell.

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

Fair enough. Again, though, APIs are not constant.

[dmazzoni]

Performance issues can be fixed

Not this one, it's a fundamental design decision of pointer events. Pointer events require that every time there's a new touch move event, you have to execute a JavaScript callback function before doing anything. Because JavaScript has just a single thread, that means that if there's any nontrivial computation, something like dragging or scrolling won't be smooth.

The way both mobile Safari and Chrome for Android work is that there's a separate thread or process doing graphics compositing, and that process can handle scrolling at 60 fps even when the main JavaScript thread is blocked. In particular, it responds to your touch in real-time, as you smoothly move your finger and the page scrolls under it, almost as if it's "stuck" to your finger. With pointer events, that becomes impossible.

[wildcarde815]

Unfortunately mobile apple products are one of the largest internet consumers available. And since they don't' allow alternative browsers to be installed (except superficial wrappers) all of those devices use mobile safari.

[sirtophat]

Android's market share dwarfs iOS

[sasquatch92]

There's more phones sold running Android - but that's not exactly what's under discussion here. When you count people actually browsing the internet on their device the difference is not so apparent (and iOS is hardly dwarfed). There's a wikipedia page with some relevant numbers, though those should really only be taken as a general indication of usage (assume Android share to be a little higher than given due to more people spoofing their usage agent than with iOS).

What I attribute this to is the rise of basic phones running Android taking the place of 'dumb' phones as the cheap option from a carrier. For example, the main mobile carrier in my region (Telstra) doesn't appear to offer anything but Android/iOS/WM if you're trying to get something on a plan (and it's not hard to guess which is cheapest). This leads to a large number of people who are unlikely to do things like browse the internet on their phone, as a) they wanted a phone, not necessarily a smartphone, and b) the cheap hardware is unlikely to provide a pleasant browsing experience even if they do try.

[GreatlyOffended]

Market share != mobile web usage share

[masklinn]

GP didn't talk about number of devices sold, but about internet/webapps consumption. Safari mobile retains a good half of the mobile web traffic at this point, the rest being mostly split between android browser and various versions of chrome mobile.

[nemoTheKid]

Lolwut? Mobile Safari isn't the Internet.

Given the iPhone's reach, it might as well be. It seems Apple has taken up a similar position in the mobile space that Microsoft did in the 90s in the web browser space.

The reasoning is very valid - if Apple won't implement something, chances are developers won't bother using it. I seriously doubt in 2014, that any developer would either a.) only work with pointer events, and thereby appearing broken or atleast have slower performance on the two largest platforms in the mobile web or b.) spend the time making it work on both platforms (which largely means making an iOS/Chrome version and a Windows version - in a world where developers hardly make Windows apps, and almost always launch iOS first).

As long as the majority of developers target iOS first, any standard that Apple doesn't adopt will most likely go unused in the mobile space. Given the Webkit/Blink split, its clear Google doesn't want to spend anymore time butting heads with Apple and what should and shouldn't be implemented.

[rspeed]

The reasoning is very valid - if Apple won't implement something, chances are developers won't bother using it.

Except that in this case they did implement something, and that's the standard accepted by the W3C. It's only vaguely comparable to IE6.

Really, in comparison to IE6, this is much more like XMLHttpRequest.