Since it split away from the WebKit render engine to create Blink, Google has been free to pick and choose what gets implemented. Now we have the news that it has decided to ignore the W3C spec for touch events.

If you thought that W3C standards were there to ensure that browsers worked in the same consistent way, then you might not like the news that Blink is siding with WebKit about which touch events API to use. 

This is another one of those Apple versus Microsoft with Google somewhere in the middle arguments.

Apple implemented the Touch Events API in WebKit. This was on its way to being the W3C standard, but some problems with patents occurred and the whole process was derailed. Microsoft stepped in with its own Pointer Events AP, which wasn't in any danger of having patents interfere. As a result the W3C made Pointer Events a standard, even though it became clear that the patents would not have been a problem for Touch Events. 

Microsoft's Pointer Events are more sophisticated than Touch Events because they are designed to handle all types of input - touch, stylus, mouse etc - using the same framework. From a programmer's point of view being able to write to a single API irrespective of the type of input device is clearly desirable. 

The Blink rendering engine already has Touch Events and the issue for both Apple and Google is whether or not to implement the W3C standard. Of course you could say that they don't really have a choice and a standard is a standard but.. in the real world the standard is what the majority of browsers implement. Mozilla is hard at work implementing Pointer Events in Firefox and of course Microsoft already supported Pointer Events in IE. So that makes two out of four big browsers going with the standard, with Apple supporting its own Touch Events and Google with a real choice. 

We now know that the voting is evently split at two two as Google has now opted not to implement Pointer Events, despite it being a W3C standard. You could even say that the voting is 2.5 to Touch Events as Opera is also using Blink. It will be interesting to see if Mozilla continues to work on Pointer Events.

So what are Google's reasons?

The blog post that announces the decision says:

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

Basically this says that, as Apple isn't going to support the standard, the chances of Pointer Events replacing Touch Events is zero and we only need one API for the job. Apple refuses to work with W3C on any input standards so it does seem likely that Safari will stick with Touch Events. 

This seems to be the main reason because the two technical reasons don't seem strong enough to cause anyone to drop a standard.  The argument is that Pointer Events hit performance because they require hit testing on each movement. 

"We're not willing to add any feature that increases the web's performance disadvantage relative to native mobile platforms."

The second objection is that Pointer Events require a static non-scrolling screen and that handling events while scrolling is something that has proved necessary.

Google seems to have a plan to extend its support for Touch Events in a way that makes it possible to create a polyfill library that smooths over the differences between Touch and Pointer Events. 

So it seems that in place of two APIs we are to look forward to three and who knows how many polyfill libraries. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info