It's obvious that Apple slowed down innovating the web since the core of their business is iOS and apps. They shouldn't have any interest in a fast innovating web that gets on par with native apps which is their main lock-in for iOS, just like Microsoft 15 years ago. They only speed up their rendering engine and JS core but don't try to help on standards improving the web experience.
BUT: I doubt this pointer event thing is a good example for their reluctance because it's really just a nice-to-have feature for the Surface and the Note series which is for my taste a too small target to justify a standard.
A good example for Apple reluctance to innovate the web is CSS Flexbox. CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit.
Another example is their reluctance to make WKWebview fully workable, since months there is still a bug which prevents WKWebview loading local files, the bug was already fixed in an early beta of iOS 8 but then they put it again in. WKWebKit is way more performant than UIWebview and can produce butter smooth HTML5 apps with Cordova/Phonegap but this one bug makes it hard (people already build local web servers to work around this problem).
EDIT/ADDITION:
A third and probably the most obvious indication that Apple doesn't want innovation in the browser space is their ban on 3rd party browsers on iOS. Benjaminjackman articulated this well in this thread below: "And yet here we are 15 years later and the iOS platform is doing just that, Apple is embracing this Microsoft strategy and extending it to a whole new level by flat out banning 3rd party browsers and so we all run the risk of having this great renaissance in browser application innovation extinguished into a second dark age."
It's obvious that Apple slowed down innovating the web since the core of their business is iOS and apps
No, it's not at all obvious, and the objections you've raised do not support your view at all.
CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit
That's a really pedantic objection — prefixing CSS standards which aren't actually finished is exactly what prefixing is for. It's hardly an anti-web move to keep it prefixed, and anybody who wants to use it can already do so with minimal additional effort.
Another example is their reluctance to make WKWebview fully workable
I find that argument very suspect, since Apple could easily just not have released WKWebView in the first place if they wanted to prevent it's use.
No, it's not at all obvious, and the objections you've raised do not support your view at all.
One could argue that the browser has matured to a point where, technically, they slowed down the innovation of Safari on all platforms. If you look at the amount of features introduced in every new version of the last few years, it is less. iOS7 Safari is a notable exception but Safari has not kept up with innovation that they once had.
prefixing CSS standards which aren't actually finished is exactly what prefixing is for.
Pedantic is Apple purposely lagging behind over said unfinished standards when the rest of the industry has moved on. Vendor prefixes are tedious for web developers to keep up with and tools such as Autoprefixer were forced to be developed b/c of them. Webkit has been unprefixed for ~6 months now and Safari and iOS have both seen updates since then without this change. This should be unacceptable and if there are still reasons to include it Apple needs to be way more transparent.
I'm not anti-Apple by any means, sitting here writing this on my MacBook Pro, but pressure on Apple to get their act together is absolutely warranted and needed to promote standards based design and development which will make a better User Experience for all.
Apple's finite is larger than every other company out there (to quote an article from earlier this week). I'm pretty sure that any issues Safari is encountering is not due to Apple reaching a "finite" limit of any kind.
EDIT: Many of your responses posit Apple as some kind of underdog, struggling to make it in this industry. Given Apple's size and talent, this viewpoint is all but indefensible.
If having an industry leading browser it was a priority for Apple, it would get done. That it's not getting done indicates either that the developers are incompetent, or that the developers' efforts are genuine but being sabotaged due to politics. I'm inclined to believe the latter.
I believe politics is the reason here too, their strategy appears to be to hinder the browser on their iOS platform to encourage native app development which locks developers into their platform which then locks users of those developers' software into their platform.
This is demonstrated by making certain features of application development on their devices only accessible by writing native software.
The simple workaround would be to write your own browser and put it on their platform. That is expressly verboten or else I'd already be using an iPhone running Firefox, instead I use and android that runs firefox and which has extensions since it's what it's users want vs what the payers of the browsers developers salaries want.
So the strategy MS used to buy years of revenue for win+office was to bundle a default browser to control the web platform and strategically hinder it whenever it threatened their core income centers. The default opt-out required momentum plus the fact that netscape did themselves no favors led to a dark age of web platform innovation as MS corruptly controlled the space and acted as negligent stewards.
What is totally insane to me is that a large portion of the Microsoft anti-trust trial revolved around them simply providing a default browser, it is hard to imagine even they would have blocked netscape software from running on their platform outright.
And yet here we are 15 years later and the iOS platform is doing just that, Apple is embracing this Microsoft strategy and extending it to a whole new level by flat out banning 3rd party browsers and so we all run the risk of having this great renaissance in browser application innovation extinguished into a second dark age.
> I believe politics is the reason here too, their strategy appears to be to hinder the browser on their iOS platform to encourage native app development which locks developers into their platform which then locks users of those developers' software into their platform.
Well, this is expected from a business perspective. Apple can't profit from the web as much as they do from the App Store, the only way to "convince Apple" is either by dropping their sales, or by regulation.
Depends on your definition of "size." I can find the reference, but I believe Apple has under a third as many developers as Microsoft, and certainly fewer than Google.
While they have money, their pay scale isn't famous for being extravagant. People work there mostly for prestige, but you can get money and prestige working for a startup.
Cook has said publicly that their biggest challenge is talent retention. They're obviously short-handed on OS releases, and willing to reallocate when necessary. So it is not surprising to me at all (but deeply disappointing) that Safari improvements would take a backseat.
They're aiming to increase their total number of Cupertino employees from 16k to over 24k in 2016. For any organisation, absorbing another 7k+ employess is no mean feat.
Apple is experiencing unprecedented success and fantastic growth. But sure, that's trivial to manage. You could do it in your sleep. Maybe you should drop Tim Cook an email.
> ... the objections you've raised do not support your view at all.
No reason to get emotional.
> That's a really pedantic objection —
Pedantic? Positioning elements is the most important feature of a layout system and CSS is totally broken in this regards, just try to vertical center something. Flexbox is godsend and finalized—every vendor removed the prefix. Wondering who is pedantic.
> Apple could easily just not have released WKWebView
The pressure they got for five years that they offer just the 10x slower UIWebview and give Safari the WKWebkit was the main reason and maybe they just released WKWebview to make the impression that they play along. This one bug makes WKWebview utterly useless.
However, would love to keep the tone in this discussion on a friendly level.
Vertical centering has been relatively easy since CSS 2.1 (Table model); flexbox of course offers much more than that. Flexbox may be finalized and unchangeable, if only because so many browsers already support it unprefixed (as support for such properties is almost never removed) – however, like much of the CSS3, flexible box model is not yet a W3C Recommendation, and is, in theory at least, subject to change. With proper tools, a prefix here and there is not a huge burden.
The reason why many browsers rush to unprefix CSS3 is not that it's perfect, but because of the lazy web developers who only prefix stuff for WebKit. This may or may not bite the community in the future.
Who is just prefixing stuff for Webkit? Mixin libraries have been pretty standard for at least three years, and now Autoprefixer is starting to do the heavy lifting.
People only initially prefixed for Webkit because webkit was the only browser that had a lot of these properties. The problem was that nobody went back and updated their prefixes, which really only further illustrates one of the big problems with the whole idea of vendor prefixes.
It's not hard, really: just use absolute centering [1]. That's actually what "margin: auto" is there for in CSS 2.1; it's a shame they were bad at evangelizing it.
using display: table-cell; is a hack and has quite a few gotchas. However it was a very useful hack none-the-less for a feature which most designers would never expect would be such a challenge.
Flexbox is awesome and has been available to use in Safari for years. Prefixing is not an impediment to the adoption of web standards.
This one bug makes WKWebview utterly useless.
No it doesn't – it does harm PhoneGap/Cordova or whatever, but there are known workarounds, and this bug is likely to be fixed soon in any case (see http://trac.webkit.org/changeset/174029/trunk for the actual commit that adds the required support)
bonn1, regarding your issues with CSS and positioning, you may find the Fayde project interesting as it addresses the problem you describe. Ignore the part about silverlight as that is only a comparison -- but fayde does support rich applications in the browser without plugins, CSS, or HTML: www.fayde.io
>CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit.
Flexbox has been unprefixed in WebKit r173579[1][2]. Presumably, it will be available when Apple release the next version of Safari. Reading the Bugzilla, the reason of not unprefixing the feature seems to be lack of contributors on WebKit's part than anything.
> Presumably, it will be available when Apple release the next version of Safari
How do you know? It's was unprefixed already ~3 months ago, so why should it happen with the next release? And when does the next release come? And why do their release cycles are not as short as those from Chrome or Firefox?
Because it's not their core business.
> ... to be lack of contributors on WebKit's part than anything.
Exactly what I wrote: Apple is focussing on other stuff than the web because—again—it's not their core business. They have two browsers, mobile Safari and desktop Safari and none of them got this important upgrade yet. A fast innovating web isn't in Apple's favor.
> How do you know? It's was unprefixed already ~3 months ago, so why should it happen with the next release?
It was unprefixed ~6 months ago.
Their latest Safari release tracks WebKit release 600 which contains all changes until July 2014[1]. The latest WebKit release is 601, which contains all changes until September 2014[2], including the flexbox unprefixing. Safari normally update WebKit to the latest release in a non-maintenance update (e.g. Safari 8.1) so it should be available with the next release.
Another thing to note is that their Web Inspector (which is built with HTML+CSS+JS) already uses the unprefixed flexbox in trunk, so if they want to ship the updated Inspector, they will eventually have to ship the feature anyway.
The first link you referenced contains a chromium dev stating the flexbox spec was stable as of summer 2012. This is an example of a secretive Apple not being transparent about why they lag behind the rest of the industry. This behavior helps no one.
Sorry, I'm not sure I get your point, are you referring to this comment:
2012-08-31 Tony Chang <tony@chromium.org>
Remove ENABLE_CSS3_FLEXBOX compile time flag
https://bugs.webkit.org/show_bug.cgi?id=95382
[..snip..]
Everyone is already enabling this by default and the spec has stablized.
If so, as a honest question, I'm not sure how is this comment related to, or why should it be an example for Apple not being transparent about why they lag behind. Can you clarify?
> It's obvious that Apple slowed down innovating the web since the core of their business is iOS and apps. They shouldn't have any interest in a fast innovating web that gets on par with native apps which is their main lock-in for iOS
I worry about this regarding Google as well. Both Apple and Google benefit from App lockin. :/
NOTE: You can downvote me, but web apps are secondary on mobile -- remember all those Chrome apps people have on the desktop, they are not treated the same as Andriod Apps on mobile, even though they could be.
Google seems to play both sides - they embrace the web, but also the "app" and marketplace model. With Chrome OS, Chrome Browser running Chrome Apps - is that sill the "open web"?
It is quite simple. I have a few friends who work for Apple and they are exhausted. They don't have time to fix everything and they don't simply hire in mass because they believe in quality. A lot of these issues will not get fixed anytime soon at this rate. So you are right. Safari is starting to get neglected but it is not for the reasons you think.
> BUT: I doubt this pointer event thing is a good example for their reluctance because it's really just a nice-to-have feature for the Surface and the Note series which is for my taste a too small target to justify a standard.
This is inaccurate. The pointer events standard allows you to avoid the 300ms delay mobile / touch screen browsers have and is useful across all devices. Without it you have to continue using hacks to prevent the delay.
Your 93% market number is perhaps accurate in the entirely hypothetical world where most Android devices actually get swift upgrades to new versions, but not in reality.
BUT: I doubt this pointer event thing is a good example for their reluctance because it's really just a nice-to-have feature for the Surface and the Note series which is for my taste a too small target to justify a standard.
A good example for Apple reluctance to innovate the web is CSS Flexbox. CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit.
Another example is their reluctance to make WKWebview fully workable, since months there is still a bug which prevents WKWebview loading local files, the bug was already fixed in an early beta of iOS 8 but then they put it again in. WKWebKit is way more performant than UIWebview and can produce butter smooth HTML5 apps with Cordova/Phonegap but this one bug makes it hard (people already build local web servers to work around this problem).
EDIT/ADDITION: A third and probably the most obvious indication that Apple doesn't want innovation in the browser space is their ban on 3rd party browsers on iOS. Benjaminjackman articulated this well in this thread below: "And yet here we are 15 years later and the iOS platform is doing just that, Apple is embracing this Microsoft strategy and extending it to a whole new level by flat out banning 3rd party browsers and so we all run the risk of having this great renaissance in browser application innovation extinguished into a second dark age."