> Sponsored by IE. Just saying.
I don't think that is undermines the importance of this post, but at least he is upfront about potential conflicts of interest.
Tired of Safari
21–30 of 125 posts
Re: Tired of Safari
#22Also, apple only allows using the UIWebView, so Chrome for iOS is just safari's engine with a better interface: https://developer.chrome.com/multidevice/ios/overview
And in previous iOS releases, the UIWebView had a significantly worse performance than safari: http://daringfireball.net/2011/03/nitro_ios_43
Both cases are explained as security measures. But they are coincidentally degrading web applications' performance, which benefits Apple's app store revenue.
Re: Tired of Safari
#23Repeating what I said in previous thread: There are real problems with the Touch Events spec, and we need a replacement. One issue is that it is under specified w.r.t its compatibility with mouse events. A concrete example: Should the touchmove event trigger the mousemove event? I believe it does in IE and Firefox, while it does not in Chrome and Safari. This isn't specified anywhere, and can make it incredibly compl…
For whatever reason, despite all the standardisation out there, DOM input always has been this massive cross-browser incompatible inconsistent proprietary clusterfuck. quirksmode.org may be known to some of you as this guy's blog, but it is best known for its DOM event compatibility tables, which somehow still matter in 2015.
If browser vendors cannot fix mouse and keyboard, why would they fix touch?
Re: Tired of Safari
#24Also, apple only allows using the UIWebView, so Chrome for iOS is just safari's engine with a better interface: https://developer.chrome.com/multidevice/ios/overview And in previous iOS releases, the UIWebView had a significantly worse performance than safari: http://daringfireball.net/2011/03/nitro_ios_43 Both cases are explained as security measures. But they are coincidentally degrading web applications' performan…
iOS added WKWebView.
Re: Tired of Safari
#25Also, apple only allows using the UIWebView, so Chrome for iOS is just safari's engine with a better interface: https://developer.chrome.com/multidevice/ios/overview And in previous iOS releases, the UIWebView had a significantly worse performance than safari: http://daringfireball.net/2011/03/nitro_ios_43 Both cases are explained as security measures. But they are coincidentally degrading web applications' performan…
Re: Tired of Safari
#26IIRC, pointer events require an huge amount of hit testing, and don't deal with bypassing the CPU to do smooth scrolling. Pointer events are a good solution for the future, but I understand why Google and Apple aren't pushing it, as they make phones where performance is more critical.
Re: Tired of Safari
#27Also, apple only allows using the UIWebView, so Chrome for iOS is just safari's engine with a better interface: https://developer.chrome.com/multidevice/ios/overview And in previous iOS releases, the UIWebView had a significantly worse performance than safari: http://daringfireball.net/2011/03/nitro_ios_43 Both cases are explained as security measures. But they are coincidentally degrading web applications' performan…
iOS added WKWebView.
WKWebview is good for a very simple in app link opener, if you want to do a full featured browser around it (Chrome iOS), the public API is nowhere near ready for that.
Re: Tired of Safari
#28It'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 t…
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.
Re: Tired of Safari
#29It'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 t…
I doubt it's intentional malice. I think it's just Apple's engineers being spread too thin. Before Blink, they had Google's manpower also helping them. Now that's gone. Flexbox will come, it'll just take Apple a while to implement it.
Flexbox will come, it'll just take Apple a while to implement it.
Flexbox is already fully implemented in Safari and has been since 6.1. The only difference is the use of a prefix.
Re: Tired of Safari
#30It'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 t…
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 i…
Apple only has finite resources, too. I doubt WKWebView is neglected, they may just be focussing on fixing something else.