I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

Tired of Safari

Yesterday, in reaction to pointer events becoming a W3C recommendation, Tim Kadlec published an important piece about Apple’s huge influence on the mobile web.

I agree with him to the extent of writing this extended Me-Too entry. It is increasingly becoming necessary to do something about Apple, its absolute refusal to talk to anyone, and its dickish way of bending the mobile web to its desires. Personally, I became tired of Safari quite a while ago, and I wouldn’t mind taking Apple down a notch.

So let’s do it.

What went before

Quick summary: Pointer Events, invented by Microsoft, are very likely to help us confront the web of devices, since they are not specific to one input mode. They are designed to work with mouse, pen/stylus, and touch, and it will be fairly easy to add other input types once these become sufficiently supported.

It’s possible to argue that touch events are better than pointer events, but oddly enough I’ve never seen anyone claim that. (Pointers appreciated.) But technical excellence doesn’t matter any more: pointer events are becoming leverage in a tug of war between Apple and the open Web. I know which side I’m on.

W3C has specifications for both pointer events and the Apple-created touch events which were the default for the last six years. W3C threw in with the pointer events quite a while ago: the touch events spec hasn’t been updated since 2013, while the pointer events one has. W3C knows which side it’s on as well.

Developer woes

The pointer event spec was temporarily delayed by an objection from Yandex (read entire thread). Representative Charles McCathie Neville argued that creating a second bunch of events to do essentially the same as touch events would put undue pressure on web developers, since they would now have to code to two standards.

Although he is right in a literal sense, I do not think we should exaggerate the problem. Clueless web devs will be clueless (and they’re mostly blinded by iFever anyway), but one or more clever ones will write a tool that will automatically convert one set of events to the other. We have a super-abundance of tools, after all, so what’s one more between friends? Therefore I respectfully reject this argument.

(Incidentally, I feel this tool should convert pointer events to touch events, so that eventually the performance hit from using it will affect Safari alone.)

Browser vendor woes

There’s a corrolary to this argument: browser vendors, too, must expend a lot of extra time in supporting two sets of events. Although that, again, is true, one way out would be to essentially cease further development of the touch events. Just don’t implement new stuff; don’t fix bugs. You’ll still have to maintain the current level of touch event support, at least for the next two years or so, but you’ll be spared the ordeal of improving both touch and pointer events.

One push to implement the pointer events would be enough, and after that the pointer events are assigned the maintenance and extension dev time that touch events used to get.

The counterweight

Still, as Tim points out, doing double work is but one of the two fundamental points in this discussion. The other is that Apple is creating its own standards.

It is customary to insert a quick paragraph about how Safari was important in the early stages of the mobile web and blah and blah, but fuck that. I’m done with being fair to Safari. (Besides, when did Apple last create truly novel and useful web stuff?)

Apple’s paranoid approach to developer relations, and, I assume, relations with other browser vendors (and, in fact, relations to anything outside itself) is becoming a serious liability to the open Web. That is the issue we must confront.

Let’s look at the problem from a political angle. Apple has a huge following and essentially could do as it pleased for the past seven years or so. In order to forcibly educate Apple to become a responsible web citizen, it is necessary to create a counter-weight; to find a company that will support the open Web and has enough market share to force even web developers who’d prefer to work in iOS only to pay attention to pointer events.

That company is Google. There is no other candidate. Firefox essentially doesn’t exist on mobile, mobile IE is too small, as are the minor browsers such as BlackBerry and UC.

In that light, Google’s refusal to implement the pointer events is a victory for Apple. Now I don’t know about the high-level politicking going on, and I certainly don’t want to argue that the Chrome team intends to increase Apple’s hold on mobile web dev, but that will be the net result of their actions anyway.

So we have to put pressure on Google, so that in the future Google will effectively pressure Apple to become a good web citizen. (Fat chance, I know, but we have to try.) If you want to help, please star this issue in the Chromium bug tracker and make some noise. Better still, if you’re fluent in both sets of events, create a real-world test case where pointer events are clearly superior to touch events. Google is sensitive to this sort of data-driven argumentation.

This approach may not be entirely fair to Google, but it’s the only course of action available to us. And Google did promise to implement pointer events and then changed its mind.

So. Let’s address this issue, shall we? It’s past time to do so.