Safari Suddenly Updating Won’t Change Anything for Web Developers

There was some recent buzz recently in the web community about a post from Nolan Lawson entitled “Safari is the new IE6”. Then there was a counter argument, that the problem is a lack of browser competition on iOS. The reality is more nuanced, and the solution is “That’s just how web development is, use a polyfill and move on.”

Lawson mentions CanIUse.com, a resource that web developers (such as myself and Nolan) frequently reference to see how supported the latest browser features are.

My interpretation of the Can I Use data is a bit different from Mr. Lawson’s.

I m going to look at the technologies mentioned specifically in the post:

  • IndexDB
  • Shadow DOM
  • Web Components
  • Service Worker
  • Web Manifests (Offline Web Apps)

First, there was a lot of talk around IndexDB and the broken implementation in Safari 8.3.

Can_I_use____Support_tables_for_HTML5__CSS3__etc

And while it would be nice for Safari to support the feature, even if Safari suddenly supported the spec fully tomorrow, according to this graph, you have a larger number of Android Users (Android Browser 4.3 and below and UC Browser for Android) that don’t support the feature at all.

Looking at the Shadow DOM:

Can_I_use____Support_tables_for_HTML5__CSS3__etc

Its supported by Chrome, Android and Desktop Opera (Which is using Chrome’s Blink rendering engine, so it gets it for free). Again, if Safari implemented this, you would still be missing IE, Firefox, and UC Browser or Android, and Android Browsers below 4.4 (This is sort of a pattern from here on out, so I will only just put the screenshots).

Can_I_use____Support_tables_for_HTML5__CSS3__etc

Can_I_use____Support_tables_for_HTML5__CSS3__etc

“Web Manifests” are a special case in that Can I Use doesn’t actually list “Web Manifests” or “Manifests”, but when I search for “Manifest” I get a single result, “Offline Web Apps” which is actually mentioned by Lawson. What does this browser support look like?

Can_I_use____Support_tables_for_HTML5__CSS3__etc

Wait…so Safari actually supports this technology? but not “web manifests”? So we Google “web manifests” and the w3c has a Working Draft. It has a big red warning on the page.

Manifest_for_a_web_application

So, there is already a way to do this in Safari, but Chrome does it differently, and the spec is still unstable. As a matter of fact, Service Worker, Web Components, and Shadow DOM are also in a state of W3C Working Draft.

As a matter of fact, Custom Elements (another way to say “Web Components” and Shadow DOM both have this warning across the bottom of their working drafts:

Custom_Elements_and_Pull_Request__333__Bugfix_bulk_removing_favorites_-_POLITICO_Stash

 

The only item on our list that is in the state of W3C Recommendation is IndexDB, which hit that state in January of this year.

I have been a web developer for 15 years, and polyfills, shims, and abstraction layers are par for the course, especially when dealing with features at the cutting edge of the web. Hell, I still have to support IE8 in almost all of my projects! Scroll back through those graphs, and you will see IE8 and 9 are red in all of them.

It honestly feels more like Lawson just wishes Safari was Chrome. This isn’t an attack on Lawson. He actually wrote a follow up post in which he says

I tend to write about weird esoteric stuff like IndexedDB and WebSQL, maybe throwing the normals a bone with something about CSS animations.

Its important to note that when he writes about “esoteric stuff” and “normals” he means esoteric and normal among web developers. Layman “normals” are not reading about CSS animations. He is an admittedly bleeding edge developer lamenting that he doesn’t have the latest toys in Safari like he does in Chrome, and it was all taken out of context. He writes Android and web apps and probably writes his apps in Chrome first (So do I, and Chrome isn’t even my default browser) and is probably annoyed when things don’t work properly in the other popular mobile browser. (Although it probably doesn’t work on a large percentage of Android phones either)

Apple has never been a company to implement a cutting feature unless it will massively improve the user experience (like killing flash and pushing web apps for iOS). Remember that they took the wait-and-see approach for 3g, LTE, NFC, Large Screens, the list could go on and on. But just like hardware, Apple isn’t going to implement a new browser feature immediately because it’s new. It will generally wait until the tech is mature, it can manage battery life, know that the spec is stable, and browser speed and then implement.

The one place where I do think Apple can do better is in sending representatives to the W3C to influence the specs. When you look at the Specs and Working drafts mentioned above, you will notice that Google has people on every single spec (sometimes they are the only author), so of course Google is implementing the working draft spec, they wrote it! But that’s not Google’s fault. Apple should be in there as well, writing the spec they want to see with them.

**As a side additional note, the UC Browser on Android proves that opening up the iOS browser eco system is not a solution, you could just as easily wind up fragmenting the iOS rendering engine even more winding up with several users on iOS that don’t support features that are implemented in Safari.

One Reply to “Safari Suddenly Updating Won’t Change Anything for Web Developers”

  1. Great post! A few minor comments.

    1) The Android stock browser is definitely still a problem. So is IE. But in my book, zero support for IndexedDB is better than broken support. I remember when iOS 8 came out, and the other shim authors and I (Matt McPherson of LocalForage and Kyaw Tun of YDN-DB) were scrambling to figure out how to detect Apple’s broken IndexedDB and downgrade to WebSQL. In the end, we all settled on user agent sniffing, which is a drag. On old Android, we can simply check for window.indexedDB to know when we need to downgrade to WebSQL (which is super stable on both Safari and Android, BTW).

    2) Web Manifest is indeed a working draft, but it is shipping in Chrome as of v38 (https://developers.google.com/web/updates/2014/11/Support-for-installable-web-apps-with-webapp-manifest-in-chrome-38-for-Android) and is no doubt inspired by the manifest format that Firefox OS has had for a few years now (https://developer.mozilla.org/en-US/Apps/Build/Manifest). It’s also under development in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=997779). My point wasn’t that it’s available now, but that both Chrome and Firefox are pushing for it. Opera too BTW.

    3) I did pick some bad examples of JS APIs. A more useful measurement, as mentioned in this post (http://www.technicaldetails.org/blog/2015/7/6/apple-can-help-the-web-without-hurting-mobile) is the percentage of all new JS APIs that are implemented by each browser (http://caniuse.com/#cats=JS%20API). You can see from the chart that Safari will be dead last once Edge comes out.

    4) You’re right; I’m a bleeding-edge kinda guy who is really interested in the future of browsers. So if I could go back and re-title my post, I might say “Safari is _becoming_ the new IE,” rather than “is the new IE.” If you’re developing for the web of 2012-2014 (ish), then Safari might not pose many problems for you. But if you watch what the standards folks are doing and keep an eye on emerging APIs, the pattern becomes clear. I hope based on my article, though, that Apple will turn things around before that happens. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *