Is Apple stifling progress in Web standards?

http://timkadlec.com/2015/02/apples-web

by w1ntermute • 11 years ago

292 144 11 years 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• 11 years 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?

streptomycin2• 11 years 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-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.

CSMastermind• 11 years ago

Apple is singled out because they're the driver behind all of this. Touch Events was born from Apple's initial work to touch-enable Safari on the iPhone. W3C moved to standardize it but Apple declined to be involved in the effort. Then they blocked the WC3 from releasing it as a standard using their patents, which they were unwilling to offer a royalty free grant for users of the spec.

Pointer Events was first proposed by Microsoft as an alternative solution. It was also a more general specification; while Touch Events was designed for touch and touch alone, Pointer Events allowed developers to use similar code to handle touch, stylus/pen, and mouse inputs. Pointer Events also addressed certain problems with Touch Events, such as a 300 millisecond delay before responding to taps in order to disambiguate between single and double taps.

Then the patent issue was resolved — W3C determined that Apple's patents didn't cover Touch Events anyway so they could release a Touch Events spec. All this time work on Pointer Events continued in parallel, backed not just by Microsoft, but also by Mozilla, jQuery, and Google.

Mozilla Firefox and Internet Explorer both implement Pointer Events. In 2012 Microsoft contributed code to WebKit, the rendering engine then used by both Chrome and Safari. While Apple never enabled the code, Google offered its support, and this continued even after Google forked WebKit to produce its Blink engine. It looked as if three of the four major browsers were on track to support the specification.

Then Google pulled support in August. Their stated rationale was that because Apple was unlikely to ever support Pointer Events and Apple is the dominate force in the mobile web; Touch Events would always be required. It's a decision that hasn't gone over well with web developers, just look at the comments on the Chromium bug tracker.

syoc• 11 years ago

only Google supports that You should read the other HN post about this issue. http://www.quirksmode.org/blog/archives/2015/02/tired_of_saf...

I just hope that Mozilla will get a proper implementation of Pointer Events so I can use that. It's sad to see Apple leveraging it's market share like this, but I can't say I'm surprised.

Alphasite_• 11 years ago

I would say Mozilla refusing to implement h254 support was a similar issue, although their reasons were much clearer.

bphogan• 11 years ago

Or Mozilla and MS refusing to implement Web SQL Databases because IndexedDB and NoSQL was better, even though one works on all mobile phones since 2010 and the other is wonky and has a terribly designed API.

No need to single anyone out. They're all equally guilty.

dragonwriter4• 11 years ago

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.

eridius3• 11 years ago

That could easily just be a justification for not supporting it that sounds better than "we'd rather not support two separate models for touch/mouse events". Especially if they really would rather not support it but feel that they would have to if Apple did jump on board.

TazeTSchnitzel2• 11 years ago

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.

towelguy3• 11 years ago

It's a Microsoft-backed spec

So it's a case of Not Invented Here? or more accurate: Invented By the Enemy?

dlib• 11 years 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• 11 years 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• 11 years 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.

sly010• 11 years ago

It's not in Apples interest to advance the web. They want less web and more native. Unfortunately.

No one will use a standard that's not available for 30% of the users, the point is to unify things, not to make yet another useless standard. Also unfortunately.

So we like it or not, Apples participation is kind of important here. I would risk that its more important than the quality of the standard itself.

kevincennis• 11 years 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• 11 years 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

matthewmacleod3• 11 years 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• 11 years 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.

matthewmacleod3• 11 years 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?

pcx2• 11 years 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?

mbel2• 11 years 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.

idonthaveaname• 11 years ago

Can you prove the quote was not spin to make Google appear to have the moral high-ground here?

5424583• 11 years ago

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

https://code.google.com/p/chromium/issues/detail?id=162757#c...

https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2...

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

coldtea• 11 years ago

As a BS excuse?

Touche4• 11 years ago

They released IndexedDB several years after everyone else (I believe at least 3 years) and major bugs.

They have shown no interest in Web Components.

They have shown no interest in WebRTC.

They have shown no interest in Service Workers.

They have very little ES6 support.

Let's not focus on the one example given in the article, this is a pattern.

kenferry• 11 years ago

Have you seen the WebRTC code? It's 1.1 million lines of gnarly C++. It's cool in terms of features, but that's the essence of bloat. One of the reasons Safari was built off of khtml in the first place was manageable code size.

matthewmacleod3• 11 years ago

I specifically didn't focus on the one example given.

Safari is now the "third best browser" behind Chrome and Firefox, looking at this through the prism of adopting web standards. That's irritating, especially when Webkit did so much to push standards forward.

I don't disagree at all about Safari lagging behind — like I just said. It also seems like this has got worse lately — but I suspect a lot of that is down to the Blink fork, and the subsequent reorganisation that is taking place.

I expect this will get a little better soon, otherwise it's a valid point that web developers will start complaining more and harder.

teamhappy• 11 years 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.

UnoriginalGuy• 11 years 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-m...

randomfool• 11 years ago

The security issue noted appears to be 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• 11 years 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.

shmerl5• 11 years 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...

malchow• 11 years 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• 11 years ago

It's hard to imagine that battery concerns are the reason for their extremely spotty ES6 support.

jasonsync• 11 years ago

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

https://github.com/eligrey/FileSaver.js/issues/12

taf2• 11 years 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• 11 years ago

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

Kiro• 11 years ago

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

towelguy3• 11 years ago

Multitouch events perhaps?

nilsbunger• 11 years ago

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

guardian5x• 11 years 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• 11 years 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• 11 years 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/

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

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• 11 years 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• 11 years 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.

smackfu• 11 years ago

Does Apple release HTML features updates to Safari in between OS releases? It feels like they freeze the features in July at WWDC, so they would be pretty out of date by February.

frik5• 11 years ago

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_user3• 11 years ago

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.

Tloewald4• 11 years ago

I've done a ton of work with contenteditable and it's not especially good on IE (it was especially bad on IE up to IE8) nor especially bad on Safari (it's kind of horrible, but it's horrible everywhere).

Tloewald4• 11 years ago

Seems like a weirdly anti-Safari summary, including assumptions about "future Safari" being inferior to "future IE".

wavefunction2• 11 years ago

I consider Safari to be the worst browser out there, especially when you include "Mobile Safari" in that assessment of Safari.

atacrawl• 11 years 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.

5424583• 11 years ago

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

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_dh4• 11 years 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.

Touche4• 11 years ago

Really? That was 7 years ago.

frou_dh4• 11 years 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.

ytpete• 11 years ago

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

frou_dh4• 11 years 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.

integraton2• 11 years 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.

towelguy3• 11 years ago

s/fast enough/at all/

integraton2• 11 years 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• 11 years 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• 11 years 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• 11 years 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

How come nobody rants about that? (genuine question)

richtr• 11 years 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.

eridius3• 11 years 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.

air2• 11 years ago

https://developer.apple.com/app-store/review/guidelines/

"Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"

millstone• 11 years ago

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

air2• 11 years ago

To be really fair, out of the four biggest browser vendors (MS, Apple, Mozilla, Google) only Google makes it possible to use the other browser engines on their mobile platform.

magicalist• 11 years ago

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

azakai3• 11 years ago

Preventing other browsers for technical reasons is very different than doing so for policy reasons. iOS prevents other browsers in both ways. ChromeOS (and FirefoxOS, and others) might limit you technically, but do not limit you by policy.

When the limitations are just technical, you can try to work around them, but when they are a flat policy, like Apple does, there is nothing you can do.

josteink• 11 years ago

It is impossible to ship e.g. Chromium on iOS right now. We just collectively buy the arguments put forward by Apple

No. Some people buy androids too. Quite a few, last time I checked.

Developers limiting themselves to support apple's modern msie are not allowing the market forces to drive healthy competition.

What? When androids browsers were lagging, locking them out from websites en masse was OK. By the same standards we should be locking out apple laggards this time around? Or are we going to be hypocrites about it?

shmerl5• 11 years ago

Why can't Apple be slapped with an antitrust lawsuit for that? MS was targeted for something very similar.

hyperpape• 11 years ago

Apple has a minority market share.

barneybooroo• 11 years 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• 11 years ago

Thanks :)

anon13852• 11 years 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.

shmerl5• 11 years 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.

kolbe4• 11 years 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.

Demiurge• 11 years ago

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

kolbe4• 11 years ago

That's not what I'm saying. Amazon, Facebook, Google and Netflix would be victims of this. People would still use their services, but they'd use their services through the dedicated iOS app, not through a browser. Then Apple will have become a necessary middle man for the consumption of the content that those companies distribute. And who knows what Apple would be able to get away with at that point. Charge Facebook $100mm whenever the push out an updated version of their app? All Amazon purchases must be made with ApplePay? Who knows.

munificent• 11 years ago

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.

r00fus• 11 years ago

I'd like to agree with you on a philosophical basis, but the reality is that Apple is 2x market cap of Exxon and iPhones recently outsold all Android in the US (calendar Q4 2014).

I don't think it's useful to downplay their influence.

xyby3• 11 years 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.

kolbe4• 11 years 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).

romaniv• 11 years ago

Their apps are a shockingly effective alternative to the internet

To some, very limited, parts of the Web.

I think this statement is very telling in terms of illustrating how people's perception of "The Internet" has shifted over the years, along with the notions about is its overall purpose. Ad frankly, I liked the old notion (the one that centered around communication, rather than "apps and services") much better.

fauigerzigerk• 11 years ago

That's not going to happen for multiple reasons.

First of all, iOS market share in 2014 was 15%. You can actually stop reading here if you like.

Second, we only use tens of apps, but most of us use hundereds if not thousands of websites per year, because most provide content, not applications. Installing an app for each of them does not scale.

And third, apps are currently uncrawlable and hence there is no way to search for server side content inside and across them. It's not unimaginable for the App Store to solve this one eventually.

xyby3• 11 years 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.

urda• 11 years 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

Transfinity• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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.

Is Apple stifling progress in Web standards?

Related Stories