11 ms·

Is Apple stifling progress in Web standards?

292 points by w1ntermute 12y ago

UnoriginalGuy 12y ago
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-microsoft-decided-to-put-webgl-into-internet-explorer-1167110 http://www.techradar.com/us/news/software/applications/why-m...
- randomfool 12y ago
  The security issue noted appears to be https://blog.mozilla.org/security/2011/06/16/webgl-graphics-memory-stealing-issue/ https://blog.mozilla.org/security/2011/06/16/webgl-graphics-..., from June 2011 (FF bug was actually fixed May 26th, 2011). It was a Firefox issue, not a spec issue. AFAIK, Microsoft never explicitly detailed what their security concerns were.
- greggman 12y ago
  That's quite the spin there. I wouldn't say that's why ms originally decided to bash WebGL. It's far more likely they wanted to both scare users away from browsers supporting WebGL and at the same time try to prevent an OpenGL like API from gaining any traction vs directx as targeting directx makes your app ms platforms only. It was only later they finally caved and implemented WebGL in ie. If they truly were only concerned about security but otherwise ok with WebGL they would have joined the WebGL committee and cooperatively influenced the spec.
- deleted 12y ago
  [deleted]
- shmerl 12y ago
  Not applicable here. Apple just want to retain the usage of their patented API in this case[1]. I.e. they are simply being greedy jerks who don't care about the Web. 1. http://arstechnica.com/tech-policy/2011/12/is-apple-is-using-patents-to-hurt-open-standards/ http://arstechnica.com/tech-policy/2011/12/is-apple-is-using...
- malchow 12y ago
  "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.
- chc 12y ago
  It's hard to imagine that battery concerns are the reason for their extremely spotty ES6 support.
TazeTSchnitzel 12y ago
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.
- mootothemax 12y ago
  Are they really? ... It's a Microsoft-backed spec that only Microsoft supports. Exactly, you've hit the nail on the head. It seems a bit strange to single out Apple when there are plenty of other vendors also not implementing it. That said, I know very little about the history of mobile browser development; have Apple historically dragged their feet on mobile Safari?
  - streptomycin 12y ago
    have Apple historically dragged their feet on mobile Safari? Yes. Here's another example: http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-Broken-Bad http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B... Every other browser supports IndexedDB for years, then Apple finally releases support for it and it's completely broken in multiple unfathomably bizarre ways. Still hasn't been fixed.
    - anon1385 12y ago
      That's hardly exclusive to Safari. IndexedDB seems to be a buggy mess in all browsers: http://pouchdb.com/2014/10/26/10-things-i-learned-from-reading-and-writing-the-pouchdb-source.html http://pouchdb.com/2014/10/26/10-things-i-learned-from-readi...
      - streptomycin 12y ago
        No, it's very exclusive to Safari. Add up all the other bugs in all the other browsers and it's about 0.1% as bad as Safari. It's almost unfathomable how huge and severe the bugs are in Safari. That's why the PouchDB solution was to simply not use IndexedDB on Safari: http://pouchdb.com/2014/09/22/3.0.6.html http://pouchdb.com/2014/09/22/3.0.6.html Here's my experience from building a fairly complex app that VERY heavily uses IndexedDB. If you follow the IndexedDB spec, you'll wind up with something that is 99% working in Firefox and Chrome. If you happen to run into that 1%, you'll find that Firefox and Chrome devs are very responsive and want to make it work. IE is a little buggy and is missing a couple features, but it's not impossible to work around them. Unfortunately the IE dev team is less responsive and it's not clear if/when they will fix things. But to support Safari, you'd have to do things that are utterly horrifying. It's basically not worth even trying.
dlib 12y ago
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 12y ago
  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.
antimagic 12y ago
"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 12y ago
  > 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 12y ago
    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 12y ago
      Say what's wrong, but don't call it "that fallacy". Those "appeals to fallacies" are really what destroys useful Internet discussions.
matthewmacleod 12y ago
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.
- ddlatham 12y ago
  Did you see Google's comment quoted in the article? No argument that PE is more elegant. If we had a path to universal input that all supported, we would be great with that, but not all browsers will support PE. If we had Apple on board with PE, we’d still be on board too.
  - matthewmacleod 12y ago
    I did see that – but it's a pretty nonsense argument, isn't it? Surely the only way to put pressure on Apple to implement PE is to go ahead and do it regardless, like all of the other vendors?
- pcx 12y ago
  > 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 12y ago
    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.
    - 12y ago
teamhappy 12y ago
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.
jasonsync 12y ago
Safari still doesn't fully support Blob URLs ... https://github.com/eligrey/FileSaver.js/issues/12 https://github.com/eligrey/FileSaver.js/issues/12
taf2 12y ago
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 12y ago
  They have conflicting interest with a better web: Apple Store.
deleted 12y ago
[deleted]
Kiro 12y ago
Why do you need touch events at all? Can someone give me an example? I thought mousedown etc worked for touch as well.
- towelguy 12y ago
  Multitouch events perhaps?
nilsbunger 12y ago
Did non-wwbkit browsers really support WebKit css prefixes as this article claims?
guardian5x 12y ago
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.
tkubacki 12y ago
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.
mkozlows 12y ago
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.
- realityking 12y ago
  To be fair, if you compare IE11's with other browsers at the time of its release, they have stellar support. There is still no other stable browser that supports let, and the only other browser with support for const is Firefox 36 (released yesterday). For better or worse, Internet Explorer has a far longer release cycle. But right after release IE is often ahead of the other browsers in some regard (CSS calc and the ECMA Internationalization API come to mind). Safari hasn't done that in a while.
  - cwyers 12y ago
    The kindest thing you can say about IE is that they seem to be well aware of the problems with their release cycle, and are taking steps to remediate this -- they refactored out large amounts of compatibility code from Trident to make EdgeHTML, and I think they plan to up the release cadence of updates to EdgeHTML significantly once they release Spartan. Apple doesn't seem to be doing much of anything to keep up with Firefox and Chrome on those charts. Which isn't even the problem! Apple will not allow Firefox or Chrome's rendering engines onto iOS. Even in the darkest days of the IE/Netscape war, Microsoft never even contemplated not letting users install Netscape. It's the combination of "lagging behind standards" and "wholly locked-down platform" that threatens to stagnate the web, and it's only Apple that's in that position.
atacrawl 12y ago
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 12y ago
  The author is cherrypicking here. See what Google actually said: https://code.google.com/p/chromium/issues/detail?id=162757#c64 https://code.google.com/p/chromium/issues/detail?id=162757#c... They make a compelling technical and business argument against it; a reason the author acknowledges and dismisses because doesn't align with his thesis.
frou_dh 12y ago
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.
- Touche 12y ago
  Really? That was 7 years ago.
  - frou_dh 12y ago
    And yet it was only a few weeks ago that YouTube started serving HTML5 video by default on the desktop (yes I know there was a flakey cookie-based opt-in earlier). There and elsewhere I was/am STILL having to spoof my desktop user-agent to pretend to be a phone to get around "Flash is REQUIRED to view this content" roadblocks. Ideally Flash needs a bullet to the head, but I credit Apple with the best strike on it so far.
    - Touche 12y ago
      You miss my point. You're saying we should forgive Apple of their current transgressions because they did something nice 7 years ago? Give me a break.
      - frou_dh 12y ago
        I said "I" not we, and nothing about forgiveness. Flash not being on iOS was not a point in time, but a continuous good thing.
- ytpete 12y ago
  Do you think perhaps the same motivation could have been at play there - stifling web competition to their native app store?
  - frou_dh 12y ago
    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.
integraton 12y ago
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 12y ago
  s/fast enough/at all/
  - integraton 12y ago
    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.
jpea 12y ago
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.
tarkin2 12y ago
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.)
alessioalex 12y ago
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)
richtr 12y ago
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.
- eridius 12y ago
  Why is it impossible? If you want JavaScript support you have to use Apple's JavaScriptCore, but I don't recall any rule that prohibits using a custom web rendering engine paired with JavaScriptCore. So if anyone wants to build a version of Chromium that uses JavaScriptCore instead of V8, you could presumably ship that.
  - air 12y ago
    https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/ "Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
    - eridius 12y ago
      Huh. I haven't actually read through that document in a while. I thought it just had the prohibition against scripting languages other than the iOS JavaScriptCore (i.e. WebKit Javascript). I wonder why it now states that you must use the WebKit framework as well?
      - shmerl 12y ago
        > I thought it just had the prohibition against scripting languages other than the iOS JavaScriptCore (i.e. WebKit Javascript). Which is already close to prohibiting other browsers (like Firefox for instance).
barneybooroo 12y ago
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 12y ago
  Thanks :)
anon1385 12y ago
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.
shmerl 12y ago
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.
kolbe 12y ago
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.
- xyby 12y ago
  > apps can replace all but some long-tail usages Yeah some long-tail usages like everything those 90% of phone and tablet users do that are not on iOS. And 100% of what desktop users do. And 100% of what laptop users do.
  - kolbe 12y ago
    Are you kidding me? 90% of what people do in iOS is in an app. Email (app), chatting (apps), Facebook (app), dating (app), Instagram (app), Twitter (app), news (app), games (apps). I could go on for quite a while until I start to encounter things that aren't in an app (e.g. Hacker News).
    - sbochins 12y ago
      There are some pretty nice HN apps on iOS.
    - mcintyre1994 12y ago
      To be fair, the actual claim was "Apple's apps can replace all but some long-tail usages." which is blatantly false. I'm not an iOS user so I might be a little off - but of your list Apple's apps do Email, chatting (for their protocol anyway), maybe they have a news app? You can do pretty much everything outside the long tail with apps - usually with the better experience (outside of the long tail again) but they're mostly not Apple's apps.
xyby 12y ago
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.
deleted 12y ago
[deleted]
urda 12y ago
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
Transfinity 12y ago
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.
hackaflocka 12y ago
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.
rblatz 12y ago
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.
ndesaulniers 12y ago
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.
datashovel 12y ago
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.

292 points by w1ntermute 12y ago

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-microsoft-decided-to-put-webgl-into-internet-explorer-1167110 http://www.techradar.com/us/news/software/applications/why-m...

randomfool 12y ago
The security issue noted appears to be https://blog.mozilla.org/security/2011/06/16/webgl-graphics-memory-stealing-issue/ https://blog.mozilla.org/security/2011/06/16/webgl-graphics-..., from June 2011 (FF bug was actually fixed May 26th, 2011). It was a Firefox issue, not a spec issue. AFAIK, Microsoft never explicitly detailed what their security concerns were.
greggman 12y ago
That's quite the spin there. I wouldn't say that's why ms originally decided to bash WebGL. It's far more likely they wanted to both scare users away from browsers supporting WebGL and at the same time try to prevent an OpenGL like API from gaining any traction vs directx as targeting directx makes your app ms platforms only. It was only later they finally caved and implemented WebGL in ie. If they truly were only concerned about security but otherwise ok with WebGL they would have joined the WebGL committee and cooperatively influenced the spec.
deleted 12y ago
[deleted]
shmerl 12y ago
Not applicable here. Apple just want to retain the usage of their patented API in this case[1]. I.e. they are simply being greedy jerks who don't care about the Web. 1. http://arstechnica.com/tech-policy/2011/12/is-apple-is-using-patents-to-hurt-open-standards/ http://arstechnica.com/tech-policy/2011/12/is-apple-is-using...
malchow 12y ago
"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.
chc 12y ago
It's hard to imagine that battery concerns are the reason for their extremely spotty ES6 support.

TazeTSchnitzel 12y ago

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.

mootothemax 12y ago
Are they really? ... It's a Microsoft-backed spec that only Microsoft supports. Exactly, you've hit the nail on the head. It seems a bit strange to single out Apple when there are plenty of other vendors also not implementing it. That said, I know very little about the history of mobile browser development; have Apple historically dragged their feet on mobile Safari?
- streptomycin 12y ago
  have Apple historically dragged their feet on mobile Safari? Yes. Here's another example: http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-Broken-Bad http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B... Every other browser supports IndexedDB for years, then Apple finally releases support for it and it's completely broken in multiple unfathomably bizarre ways. Still hasn't been fixed.
  - anon1385 12y ago
    That's hardly exclusive to Safari. IndexedDB seems to be a buggy mess in all browsers: http://pouchdb.com/2014/10/26/10-things-i-learned-from-reading-and-writing-the-pouchdb-source.html http://pouchdb.com/2014/10/26/10-things-i-learned-from-readi...
    - streptomycin 12y ago
      No, it's very exclusive to Safari. Add up all the other bugs in all the other browsers and it's about 0.1% as bad as Safari. It's almost unfathomable how huge and severe the bugs are in Safari. That's why the PouchDB solution was to simply not use IndexedDB on Safari: http://pouchdb.com/2014/09/22/3.0.6.html http://pouchdb.com/2014/09/22/3.0.6.html Here's my experience from building a fairly complex app that VERY heavily uses IndexedDB. If you follow the IndexedDB spec, you'll wind up with something that is 99% working in Firefox and Chrome. If you happen to run into that 1%, you'll find that Firefox and Chrome devs are very responsive and want to make it work. IE is a little buggy and is missing a couple features, but it's not impossible to work around them. Unfortunately the IE dev team is less responsive and it's not clear if/when they will fix things. But to support Safari, you'd have to do things that are utterly horrifying. It's basically not worth even trying.

dlib 12y ago

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 12y ago
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.

antimagic 12y ago

"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 12y ago
> 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 12y ago
  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 12y ago
    Say what's wrong, but don't call it "that fallacy". Those "appeals to fallacies" are really what destroys useful Internet discussions.

matthewmacleod 12y ago

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.

ddlatham 12y ago
Did you see Google's comment quoted in the article? No argument that PE is more elegant. If we had a path to universal input that all supported, we would be great with that, but not all browsers will support PE. If we had Apple on board with PE, we’d still be on board too.
- matthewmacleod 12y ago
  I did see that – but it's a pretty nonsense argument, isn't it? Surely the only way to put pressure on Apple to implement PE is to go ahead and do it regardless, like all of the other vendors?
pcx 12y ago
> 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 12y ago
  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.
  - 12y ago

teamhappy 12y ago

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.

jasonsync 12y ago

Safari still doesn't fully support Blob URLs ... https://github.com/eligrey/FileSaver.js/issues/12 https://github.com/eligrey/FileSaver.js/issues/12

taf2 12y ago

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 12y ago
They have conflicting interest with a better web: Apple Store.

deleted 12y ago

[deleted]

Kiro 12y ago

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

towelguy 12y ago
Multitouch events perhaps?

nilsbunger 12y ago

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

guardian5x 12y ago

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.

tkubacki 12y ago

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.

mkozlows 12y ago

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.

realityking 12y ago
To be fair, if you compare IE11's with other browsers at the time of its release, they have stellar support. There is still no other stable browser that supports let, and the only other browser with support for const is Firefox 36 (released yesterday). For better or worse, Internet Explorer has a far longer release cycle. But right after release IE is often ahead of the other browsers in some regard (CSS calc and the ECMA Internationalization API come to mind). Safari hasn't done that in a while.
- cwyers 12y ago
  The kindest thing you can say about IE is that they seem to be well aware of the problems with their release cycle, and are taking steps to remediate this -- they refactored out large amounts of compatibility code from Trident to make EdgeHTML, and I think they plan to up the release cadence of updates to EdgeHTML significantly once they release Spartan. Apple doesn't seem to be doing much of anything to keep up with Firefox and Chrome on those charts. Which isn't even the problem! Apple will not allow Firefox or Chrome's rendering engines onto iOS. Even in the darkest days of the IE/Netscape war, Microsoft never even contemplated not letting users install Netscape. It's the combination of "lagging behind standards" and "wholly locked-down platform" that threatens to stagnate the web, and it's only Apple that's in that position.

atacrawl 12y ago

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 12y ago
The author is cherrypicking here. See what Google actually said: https://code.google.com/p/chromium/issues/detail?id=162757#c64 https://code.google.com/p/chromium/issues/detail?id=162757#c... They make a compelling technical and business argument against it; a reason the author acknowledges and dismisses because doesn't align with his thesis.

frou_dh 12y ago

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.

Touche 12y ago
Really? That was 7 years ago.
- frou_dh 12y ago
  And yet it was only a few weeks ago that YouTube started serving HTML5 video by default on the desktop (yes I know there was a flakey cookie-based opt-in earlier). There and elsewhere I was/am STILL having to spoof my desktop user-agent to pretend to be a phone to get around "Flash is REQUIRED to view this content" roadblocks. Ideally Flash needs a bullet to the head, but I credit Apple with the best strike on it so far.
  - Touche 12y ago
    You miss my point. You're saying we should forgive Apple of their current transgressions because they did something nice 7 years ago? Give me a break.
    - frou_dh 12y ago
      I said "I" not we, and nothing about forgiveness. Flash not being on iOS was not a point in time, but a continuous good thing.
ytpete 12y ago
Do you think perhaps the same motivation could have been at play there - stifling web competition to their native app store?
- frou_dh 12y ago
  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.

integraton 12y ago

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 12y ago
s/fast enough/at all/
- integraton 12y ago
  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.

jpea 12y ago

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.

tarkin2 12y ago

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

alessioalex 12y ago

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)

richtr 12y ago

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.

eridius 12y ago
Why is it impossible? If you want JavaScript support you have to use Apple's JavaScriptCore, but I don't recall any rule that prohibits using a custom web rendering engine paired with JavaScriptCore. So if anyone wants to build a version of Chromium that uses JavaScriptCore instead of V8, you could presumably ship that.
- air 12y ago
  https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/ "Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
  - eridius 12y ago
    Huh. I haven't actually read through that document in a while. I thought it just had the prohibition against scripting languages other than the iOS JavaScriptCore (i.e. WebKit Javascript). I wonder why it now states that you must use the WebKit framework as well?
    - shmerl 12y ago
      > I thought it just had the prohibition against scripting languages other than the iOS JavaScriptCore (i.e. WebKit Javascript). Which is already close to prohibiting other browsers (like Firefox for instance).

barneybooroo 12y ago

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 12y ago
Thanks :)

anon1385 12y ago

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.

shmerl 12y ago

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.

kolbe 12y ago

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.

xyby 12y ago
> apps can replace all but some long-tail usages Yeah some long-tail usages like everything those 90% of phone and tablet users do that are not on iOS. And 100% of what desktop users do. And 100% of what laptop users do.
- kolbe 12y ago
  Are you kidding me? 90% of what people do in iOS is in an app. Email (app), chatting (apps), Facebook (app), dating (app), Instagram (app), Twitter (app), news (app), games (apps). I could go on for quite a while until I start to encounter things that aren't in an app (e.g. Hacker News).
  - sbochins 12y ago
    There are some pretty nice HN apps on iOS.
  - mcintyre1994 12y ago
    To be fair, the actual claim was "Apple's apps can replace all but some long-tail usages." which is blatantly false. I'm not an iOS user so I might be a little off - but of your list Apple's apps do Email, chatting (for their protocol anyway), maybe they have a news app? You can do pretty much everything outside the long tail with apps - usually with the better experience (outside of the long tail again) but they're mostly not Apple's apps.

xyby 12y ago

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.

deleted 12y ago

[deleted]

urda 12y ago

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

Transfinity 12y ago

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.

hackaflocka 12y ago

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.

rblatz 12y ago

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.

ndesaulniers 12y ago

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.

datashovel 12y ago

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.