
Is Apple stifling progress in Web standards? - w1ntermute
http://timkadlec.com/2015/02/apples-web
======
mkozlows
People are getting really bogged down in specific standards, but you don't
need to talk about pointer events or flexbox or indexeddb or whatever, you can
look at this at a macro level.

Here's the ES6 support table: [http://kangax.github.io/compat-
table/es6/](http://kangax.github.io/compat-table/es6/)

Safari and IE were laggards, but future IE is going to be very solid while
future Safari is still going to be terrible.

Here's the HTML5 support table:
[https://html5test.com/results/desktop.html](https://html5test.com/results/desktop.html)

Safari and IE are laggards, and both continue to lag.

Safari used to be a Chrome/Firefox-level "modern" browser, while IE was the
consistent laggard, with its slow release cycles and bad standards support.
The most optimistic thing you can say about Safari now is that it's on IE's
level; and realistically, it's even worse than IE -- certainly the IE team is
a lot more transparent about future plans than the Safari team is.

~~~
frik
> you don't need to talk about pointer events or flexbox or indexeddb or
> whatever

But missing functionality is a deal breaker.

* WebRTC - web peer to peer connection: Chrome & Firefox yes, IE 11 incompatible by design (bought Skype for 11b, based on it), Safari no (would be Facetime competitor)

* WebSQL - web relational database: Chrome & Safari (also 95% of all smartphones) yes, Firefox & IE no (declared dead by Oracle and MS devs (biggest SQL vendors), in favour of complicated NoSQL API IndexedDB on W3C mailing list)

* IndexedDB - complicated NoSQL API: Chrome & IE 11 yes, Firefox yes but slow (implemented on top of SQLite, refused to implement WebSQL API, FirefoxOS is the only smartphone OS with no SQL API), Safari yes but buggy

* WebGL - OpenGL 3D accelerated graphics: Chrome & Firefox & Safari(since iOS8) yes, IE 11 barely (old 0.9 instead of 2.0 API, few extensions)

* CSSRegions - desktop publishing stylesheet features like Adobe InDesign/MS Word: Safari & Firefox yes, Chrome yes but removed again, IE 11 yes but older draft

* ContentEditable/HTML editor - a bug free implementation would make MS Word WebApp & Google Docs obsolete: IE 11 yes (invented, based on Frontpage, old HTML4), Firefox & Chrome yes but bugs, Safari barely useable (especially on iOS)

So basically every browser vendor is guilty to some extend. Apple protects its
AppStore walled garden, FaceTime and "Pages" word processor, Microsoft its
Skype/Lync, Office and DirectX/XBox eco-system, Google its GoogleDocs and
Hangout, Mozilla community has some sponsored devs from companies with their
own agenda (e.g. against WebSQL API, while using SQLite in Firefox to
implement NoSQL API IndexedDB).

~~~
bad_user
WebSQL is SQLLite and making that a standard is very hard without including
SQLite's bugs and non-standard behavior.

Mozilla had really good reasons for shooting it down. Calling them out on it
is meaningless without specifying why you think they've been wrong. You can
say anything about IndexedDB, but at least it has a spec.

~~~
frik
* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature. SQLite is in public domain, so every company can use it (even Microsoft products already use it!)

* Also the argument of them that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).

Nowadays with the rise of NewSQL movement of people who burnt their fingers
with NoSQL, one can only hope someone gives some love to Web SQL.

To sum up, NoSQL has it's place and SQL has one too.

We had this discussion already this week, hopefully W3C board members and
Mozilla devs read this:
[https://news.ycombinator.com/item?id=9082847](https://news.ycombinator.com/item?id=9082847)

~~~
dragonwriter
> The argument that WebSQL was tailored to a specific SQLite version is
> nonsense.

No, the idea that WebSQLDB _was not_ tailored to a specific SQLite version is
nonsense. See Section 5 of the last version of the WebSQLDB spec [0]:

 _User agents must implement the SQL dialect supported by Sqlite 3.6.19._

> SQLite supports the official SQL92 standard

SQLite version 3.6.19 does not support all of, or only, the SQL92 standard.
WebSQLDB did not mandate support for the SQL92 standard, or any other standard
version of SQL, it specified the dialect supported by SQLite 3.6.19.

[0]
[http://www.w3.org/TR/webdatabase/#databases](http://www.w3.org/TR/webdatabase/#databases)

~~~
frik
Everyone knows the "Web SQL Database W3C recommendation" document should be
re-evaluated, better formulated and improved. Richard Hipp, the creator of
SQLite, stated that the dialect won't change (removing syntax) in SQLite v3
during the WebSQL W3C standardization in the mailing list.

About 95% of all mobile devices already support WebSQL (iOS & Android &
WindowsPhone (via official Microsoft sponsored extension)). And all desktop
Chrome, Safari, Opera support WebSQL too. The only missing browsers are IE 11
and Firefox/FirefoxOS.

~~~
dragonwriter
> Everyone knows the "Web SQL Database W3C recommendation" document should be
> re-evaluated, better formulated and improved.

Everyone does not _know_ this. Some people _believe_ this, other people
_believe_ it should die in a fire. But whatever one things about the current
state of the abandoned WebSQLDB spec, that is what WebSQLDB is, and you can't
talk about -- honestly, at least -- it and pretend that it specifies SQL-92 as
the required SQL dialect when, in fact, it specifies "the SQL dialect
supported by SQLite 3.6.19".

You are essentially arguing that WebSQLDB should not have been abandoned based
on the content of an imaginary WebSQLDB spec that never existed. If WebSQLDB
had specified a (explicit, well-defined, use-case appropriate, single-user
subset of) SQL-92 that would be different than what it actually specified, and
the discussion would be different.

------
UnoriginalGuy
Honestly, not yet.

Apple might one day be fairly accused of holding up web standards, but so far
they're still at least 80/20 implementing new proposals. It might be unpopular
but it is actually the responsibility of browsers to somewhat govern what
standards do or do not move forward.

For example when IE decided not to do WebGL due to security concerns and then
successfully got the standard altered as a direct result [0]. That was what
browsers are meant to do. That's what Apple does in some cases too, however
their primary focus appears to be battery not security.

[0] (end of article)
[http://www.techradar.com/us/news/software/applications/why-m...](http://www.techradar.com/us/news/software/applications/why-
microsoft-decided-to-put-webgl-into-internet-explorer-1167110)

~~~
malchow
"it is actually the responsibility of browsers to somewhat govern what
standards do or do not move forward"

An underappreciated point. Browser developers incl. Apple also have a
responsibility to recognize that it's a mobile world. A compute cycle might
look like it's getting cheaper, but a mobile CC is vastly more expensive than
a desktop CC because of the cost of energy.

We might have three monitors plugged into 100A mains, but the typical end user
has a 1900mAh battery and 7.5 seconds between Starbucks and the car door to
send log in to the school's website to approve a field trip permission. It
will be a while before mobile web standards can progress in the blue sky
fashion we'd prefer.

------
richtr
What is difficult to argue against, and I'm surprised isn't mentioned in this
article, is that Apple have completely eliminated market competition from
happening around web standards on the iOS platform.

It is impossible to ship e.g. Chromium on iOS right now. We just collectively
buy the arguments put forward by Apple to support that position without
appreciating the ramifications of not allowing market forces to drive healthy,
competitive development.

In that process we made Apple the gatekeeper of web standards development.
They can ship whatever they want, when they want and there is no way to build
or work around it (e.g. 'Download this alternative browser!').

All we can do is wait, hope or complain. Apple knows the power it wields. I
figure Google understands that too hence their position wrt Pointer Events.

~~~
millstone
To be fair, it's also impossible to ship Firefox on ChromeOS.

~~~
magicalist
Actually, it would take quite some work to port Firefox, but you could run a
NaCl-compiled browser just fine.

~~~
pcwalton
Not realistically. The NaCl APIs to support dynamically-generated code have to
revalidate every time, so they're too slow to support the heavily self-
modifying nature of compiled JavaScript.

------
kolbe
This article's title got me thinking that Apple, as a company, could actually
be interested in suppressing the advancement of the web. Their apps are a
shockingly effective alternative to the internet, and the store becomes more
comprehensive by the year.

Even at this point, Apple's apps can replace all but some long-tail usages.
So, despite the fact that suppressing the progress of the web will hurt the
user experience of its own web browser users, that affects users of all
operating systems fairly equally. But in the meantime, Apple can keep
improving their OS, the app development process, &c; and they could steadily
crowd out the web until iOS becomes the primary (or, if Apple gets it way, the
solitary) source of networked information distribution/consumption. And after
a while, all of what are currently thought of as web or web 2.0 companies
would all be at the mercy of Apple. They would, for all intents and purposes,
privatize the web.

~~~
Demiurge
This can't possibly happen because regardless of how big Apple is, it is tiny
compared to the Internet and everyone who depends on the open Internet, from
Amazon, Facebook, Google, Netflix to whitehouse.gov and data.nasa.gov

~~~
munificent
> it is tiny compared to the Internet

This depends entirely on how you measure scale. If you do it just by number of
apps/sites, sure, the vast majority of web URLs don't have a matching iOS app.

However, if you scale each app by the total amount of time users are on it,
you'll find that most of humanity is spending their time on a very heavily
weighted small slice of the Internet.

From that breakdown, the fraction of human-hours that is covered by sites that
also have native iOS apps is much larger.

If the next version of iOS didn't even have a browser, you would be astonished
at how little that impacted most users. As long as they can still run
Facebook, Instagram, Threes, etc., they'd be fine.

~~~
smhg
> _If the next version of iOS didn 't even have a browser, you would be
> astonished at how little that impacted most users._

If time spent in an application is your criterion, true.

But that way you hugely underestimate the importance of, for instance, that
daily (or even weekly) Google search the average user performs in their
browser. It takes little time compared to your average social feed, but
definitely impacts their lives. Just one quick example: a local business'
phone number lookup.

------
tarkin2
Isn't the Web a competitor to the App Store? Especially when web apps start to
catch up with native apps (and Santa tracker and the rest of Google's Polymer
apps seem to suggest this is only a year or so away, and FirefoxOS has
certainly made huge strides in this direction) and offline support with web
workers is ubiquitous?

My experiences with Web Components, at least, do seem to suggest they're not
very proactive and/or dedicated in the standards department, at least. They
did put Shadow DOM into their spec at one point, but then removed it. The
template tag is in at least, but that is a very, very simple tag (inert
content until added to dom).

(I also found IE11 to play much nicer compared to Safari as compared to bug in
my apps, not standard support, although that is really an indication of IE11's
quality rather than Safari's laggardly standard support.)

------
TazeTSchnitzel
Are they really? Other browser vendors also refuse to implement things
sometimes. IE has taken its sweet time on certain technologies, entirely
deliberately. Google have tried to force standards with their marketshare.

Pointer Events is an odd case. It's a Microsoft-backed spec that only
Microsoft supports. Apple won't implement it, Google won't, Mozilla's
implementation is unfinished. Touch Events is also weird: only Google supports
that.

~~~
dragonwriter
> Pointer Events is an odd case. It's a Microsoft-backed spec that only
> Microsoft supports. Apple won't implement it, Google won't, Mozilla's
> implementation is unfinished.

Google, per the Chrome rep quoted in the article, prefers PE from a technical
perspective, and only doesn't support it because it won't be universal because
of Apple's resistance.

Unfinished means WIP, it doesn't mean that Mozilla doesn't support it the way
Apple doesn't. Apple is the only barrier to adoption here.

~~~
TazeTSchnitzel
> Google, per the Chrome rep quoted in the article, prefers PE from a
> technical perspective, and only doesn't support it because it won't be
> universal because of Apple's resistance.

See below: the Chrome team have other (performance) objections.

------
dlib
Playing the devil's advocate but isn't Apple hindering web standards a
strategy to keep people using the apps from the AppStore. On mobile, where the
iOS market share is huge and it's impossible to use any other rendering engine
it would be hugely beneficial to stifle progress as native apps and thus the
lock-in they provide, will keep the upper hand.

~~~
captainmuon
If I look at what features are provided and what are not in HTML5 (especially
on iOS), I also get the impression that some features are "conveniently"
missing, with the consequence that certain things can only be written as
native apps.

Notably: \- Network access. You can't write a BitTorrent or IMAP client in
HTML. You could have with Java or Flash, but those have been axed (Apple was a
major contributor to that). Of course there were good technical and security
reasons for that, but it is a "convenient" side effect. \- Last time I checked
at least, touch input and rendering (WebGL/Canvas) was inferior to native.

Now, I'm not convinced there is a concious decision to keep HTML apps limited,
but I do believe it plays a role when it comes to Apple supporting certain
features and disallowing others.

------
Transfinity
It's not just browsers. I work in storage, and their NFS client (a 25 year old
protocol) is without question one of the worst we've seen. The number of hoops
we have to jump through and spec violations we've implemented just to get the
server to play nice with Macs is a little disgusting.

------
taf2
I can't help but wish this was about WebRTC instead of pointer events. I can
see so many applications using WebRTC but not so many using pointer events...
Still I loath Safari, for locking so many features out of the mobile web.

~~~
omeid2
They have conflicting interest with a better web: Apple Store.

------
alessioalex
IE is the only browser that STILL doesn't support EventSource, the simplest
realtime technology one can use with browsers:
[http://caniuse.com/#feat=eventsource](http://caniuse.com/#feat=eventsource)

How come nobody rants about that? (genuine question)

------
teamhappy
I've noticed recently that Apple removed support for the High Resolution Time
API (performance.now and friends) in iOS Safari 8.1. It was fully supported in
iOS Safari 8.0. Not sure if I've ever seen a vendor _unimplement_ a (HTML5)
feature before.

------
antimagic
"Apple has shown no interest"

Um, that's an assertion, without which the rest of the piece makes no sense. I
would have expected a little evidence to back the assertion up, or are we all
supposed to get our pitchforks out on Tim's say-so?

That being said, let's assume that Tim is actually right, and that Apple are
being capricious and trying to hold back the Web, because they can. Apple are
within their rights to decide to not implement a standards-proposed API. If
that API is the greatest thing since sliced bread, web developers will start
using it, and Apple will be forced to follow suit or be left behind. If that
API is rejected by web developers, then why should Apple waste time
implementing it?

Obviously if Apple throw their weight behind an API, that makes developer
support much more likely, but I don't see why they should be obliged to expend
resources championing an API they don't like, and which is not yet being used
by developers. Let browser implementers that see the value in the API do the
experimental work, and if it turns out to be popular, Apple can follow along
later. I don't see that anybody is being harmed or "stifled" by such a course
of action.

~~~
kevincennis
> Um, that's an assertion, without which the rest of the piece makes no sense.
> I would have expected a little evidence to back the assertion up...

How, exactly, would you expect the OP to present evidence of Apple _not_
showing interest? What would that "evidence" look like?

I can't provide evidence that my golden retriever _doesn 't_ have an advanced
understanding of quantum mechanics, but I don't think that would get him a job
at CERN.

~~~
lordbusiness
The parent makes a solid point, and you're employing this logical fallacy,
which is why I am down voting you.:

[http://en.wikipedia.org/wiki/Appeal_to_ridicule](http://en.wikipedia.org/wiki/Appeal_to_ridicule)

~~~
heinrich5991
Say what's wrong, but don't call it "that fallacy". Those "appeals to
fallacies" are really what destroys useful Internet discussions.

------
anon1385
The dream of the modern web is the concept of a single standard/platform that
is used for all user facing software. This is a flawed idea and this article
demonstrates one of the biggest reasons for that. By definition, features only
become part of open web standards if all the main players agree to them. All
the players have financial and political incentives to block various things.
Corporations can block something that you want to use even though you have no
relationship with that corporation. In a capitalist system you have very
little leverage against a corporation that you have no financial relationship
with. What are you going to do: stop buying the [Apple/Google/Microsoft]
products that you already don't use? What's left is people writing angry
impotent blog posts against companies that don't care about them in the least.

The list of proposed standards that have been blocked/delayed by one of more
of the big browsers is huge. Blocking proposed standards isn't uncommon, if
anything it's the norm. mathml, websql, pointer events, h264 video, nacl,
flexbox, webgl, jpeg2000, webm, mp3, ogg vorbis, theora, webp etc etc.

Because of its origins as a way of displaying untrusted documents the web has
no 'escape hatch'. It's a very tight sandbox. Flash and Java used to fulfil
that role but they are on the way out. The web has a very basic trust model -
all pages are untrusted and there is no other level of trust available. So if
what you want to do hasn't been blessed by all the browser vendors then you
are screwed. Does one of the main browser vendors compete with your product?
It's quite likely that they do. Yet you want to give them full control over
how your code can run all on all users machines?

If you don't like the idea of a corporation being able to veto a web standard
then you need to seriously ask yourself if you actually like the idea of open
web standards at all. Political vetoing is integral to the idea of open
standards created through consensus and it isn't going to go away no matter
how much people fantasise about it.

------
atacrawl
How is this from Google...

 _" If we had Apple on board with PE, we’d still be on board too."_

... anything else but a lame excuse? It's deeply unfortunate that Apple won't
budge on this because I think PE is a step in the right direction, but Google
using Apple as a crutch is just as ridiculous.

~~~
542458
The author is cherrypicking here. See what Google actually said:

[https://code.google.com/p/chromium/issues/detail?id=162757#c...](https://code.google.com/p/chromium/issues/detail?id=162757#c64)

They make a compelling technical and business argument against it; a reason
the author acknowledges and dismisses because doesn't align with his thesis.

------
rblatz
Mobile development is tricky, you have to support the most common devices and
browsers that are out there. That means Safari on iOS, and Chrome and the
bundled browser on android. Since a large percentage of users will not seek
out an alternate browser we have to support the bundled browser. In my
experience, we've been limited by Android as a platform than we have by iOS.

First iOS devices tend to upgrade their software more often, and are more
likely to be running a recent version of the web browser.

Second support for features may exist on Android, but we have been unable to
use those features because they did not perform in an acceptable manner for
what we were attempting to accomplish. We've had a lot of issues with things
like 3D/2D CSS transforms. In fact we've had to sniff out Android user agents
and provide a substandard experience for certain features due to the abysmal
performance.

Apple may be moving slower than the cutting edge on Android, but the cutting
edge is so far removed from the reality of what we have to support and work
with that it's basically irrelevant.

------
shmerl
Apple are too sick with lock-in mentality, so of course they'd sabotage any
effort if that helps them retaining some grip on the market. The fact that
they ban competing browsers on their mobile systems clearly demonstrates the
point. And their negative attitude to free codecs is known as well. They are
too stuck in their petty hate for interoperability.

------
tkubacki
Apple is not going to support Web Components (Shadow DOM) as well.

FF is working on it and even MS has "under consideration" status.

Even if there were some issues with driving Shadow DOM standardization by
Google I suspect that not supporting it by Apple is more defending iOS walled
garden than real tech issues with specs.

------
jpea
WebRTC is a huge one that comes to mind. With the App Store and Facetime in
the same wheelhouse, there's no compelling reason to develop this area for
Apple. It would be a HUGE win for the general web if they did, but there's
zero reason for them to pursue it.

------
guardian5x
Maybe once Apple brings the rumored iPad Pro with Stylus support, we will see
them supporting it. I guess at the moment they just have no reason for it.
Maybe they think they would help MS with the Surface, which would benefit from
widespread PE support.

------
matthewmacleod
The answer is a gritty, in-your-face "no".

 _We have a recurring situation where all vendors (save for Apple) show
interest in standard, but because Apple does not express that same interest,
the standard gets waylaid._

That is literally not true – Google, by some metrics the biggest vendor, has
also shown no interest in PE.

Frankly, I don't see that much of a problem with Webkit and its' adherence to
standards. Broadly speaking, it adopts new features and standards somewhat
later than FF and Chrome, primarily I expect because of the slower release
cycle, but it does seem to eventually come on-board.

~~~
pcx
> If we had Apple on board with PE, we’d still be on board too.

You entirely missed this quote in the article. How do you explain that?

~~~
mbel
It seems worth noticing that this is more political than technological
argument. Google _choose_ not to implement Pointer Events and used Apple as a
scapegoat.

I'm not happy with Apple's decision, but I'm even less happy with Google using
Apple as some kind of feature implementation oracle.

~~~
fpgeek
This isn't Google using Apple as a feature implementation oracle, this is
Google looking at pointer events using both their "web developer" and "browser
developer" hats and reaching a disappointing conclusion.

As a web developer, Google would have to use Touch Events because that's all
that Apple supports. Chrome already supports Touch Events. That covers the
overwhelming majority of their touch-enabled users, with code they already
have. Rewriting that to use a newer modern standard everywhere is one thing,
but writing a second implementation with no path to sunsetting the first is
much harder to justify.

Coming full circle, if Google's web developers aren't going to use Pointer
Events for the forseeable future, it is hard to justify Google the browser
developer putting them high on their priority list.

~~~
mbel
Thanks for the reply, honestly I haven't thought about Google as web
developer. Another point that I unfortunately missed is that if Apple
implemented Pointer Events in WebKit, then the changes could probably be
ported very quickly to Blink (I guess both code bases are still largely
similar).

------
datashovel
Just thinking out loud here:

What if we had a "meta app" which encapsulated individual browsers and created
a specification allowing developers to define which browser type to use when
opening their web page?

Not saying this can't be done today, but where the transition was seamless.
I'm unaware of anything that allows us to do this today. I do recall a project
that allowed one to do something similar (IE tabs in Chrome), but I think it
wasn't the same in terms of seamless transition, and there was no way for the
developer to control the transition.

------
jasonsync
Safari still doesn't fully support Blob URLs ...

[https://github.com/eligrey/FileSaver.js/issues/12](https://github.com/eligrey/FileSaver.js/issues/12)

------
barneybooroo
The whole "developer relations as Bigfoot" trope doesn't ring true when it
comes to WebKit, in my experience. I've had Apple developers reach out to me
when I've mentioned WebKit bugs on Twitter. They're very happy to talk about
efforts towards standards, and I actually find it to be one of the least
cynical parts of Apple's business.

~~~
hober
Thanks :)

------
xyby
I saw windows applications come and go. I saw ActiveX come and go. I saw Java
applets come and go. I saw Flash come and go.

To me, iOS apps don't feel like a threat. Apple does not even have a monopoly
like Microsoft had.

------
ndesaulniers
It's interesting; when Google worked with Apple on WebKit, they were able to
pull Apple forward. Now that Google has forked WebKit into Blink, Apple is on
their own to keep up.

------
hackaflocka
Go ahead and do it anyway. May be just what Apple and Google need to be
disrupted.

Not too long ago, Microsoft used to display similar arrogance. Look where they
are now.

------
Kiro
Why do you need touch events at all? Can someone give me an example? I thought
mousedown etc worked for touch as well.

~~~
towelguy
Multitouch events perhaps?

------
integraton
Microsoft significantly stifled progress on the web for a decade. Now, after
WebKit's progress wrestled away Microsoft's dominance and eventually forced
Microsoft to spend years trying to catch up, Microsoft wants everyone to get
out the pitchforks because Apple isn't supporting Microsoft's latest pet
standard fast enough.

~~~
towelguy
s/fast enough/at all/

~~~
integraton
You can't predict the future, the standards process is messy, and Apple hasn't
actively taken a public position, so at this time your comment is
disingenuous.

------
nilsbunger
Did non-wwbkit browsers really support WebKit css prefixes as this article
claims?

------
urda
As always folks, Betteridge's law of headlines [1] is in play here.

The answer? No.

[1]
[http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines](http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

------
frou_dh
As far as I'm concerned, Apple still have a bit of time left to bask in the
afterglow granted for mortally wounding Flash by keeping it off of iOS.

~~~
ytpete
Do you think perhaps the same motivation could have been at play there -
stifling web competition to their native app store?

~~~
frou_dh
Hard to say to what extent. Remember, at least in the early days before there
even was a native SDK, they were very pro-webapp for iOS.

