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.
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.
> 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).
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.
"Bugs" I get, but what do you mean by "non-standard behavior" mean here?
My perspective, having had some experience with some pretty sophisticated DB adapter layers in the past: SQLlite and other nominally-SQL DBs all have only a very superficial level of SQL-level compatibility. Aside from closely related DBs (e.g. forks) it's not like there's any actual ability to exchange character-for-character identical SQL or DDL between DBs. All kinds of things like quoting, namespacing, and so on have subtly different syntax. It's pretty easy for a human to switch between SQL-x and SQL-y systems, but not so much when you're talking query generation. Even Rails has a pile of different backends for Active Record, and AR's backend is pretty darn simplistic.
It should be compatible with most DBs, but SQLite has more dynamic types, and supports more things, in ways that are "odd" for almost all other DBs. As you correctly said, in general, no two DBs are easily interchangeable, and SQLite is no exception, perhaps it is even more of an outlier in fact.
That means that to implement SQLite, not using SQLite code, means you need to carefully reproduce that behavior, and all aspects of it - in practice, including bugs - to be a compatible web browser. For a web standard, that's just unacceptable.
* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature. SQLite is in public domain, so every company can use it (even Microsoft products already use it!)
* Also the argument of them that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).
Nowadays with the rise of NewSQL movement of people who burnt their fingers with NoSQL, one can only hope someone gives some love to Web SQL.
To sum up, NoSQL has it's place and SQL has one too.
> The argument that WebSQL was tailored to a specific SQLite version is nonsense.
No, the idea that WebSQLDB was not tailored to a specific SQLite version is nonsense. See Section 5 of the last version of the WebSQLDB spec [0]:
User agents must implement the SQL dialect supported by Sqlite 3.6.19.
> SQLite supports the official SQL92 standard
SQLite version 3.6.19 does not support all of, or only, the SQL92 standard. WebSQLDB did not mandate support for the SQL92 standard, or any other standard version of SQL, it specified the dialect supported by SQLite 3.6.19.
Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved. Richard Hipp, the creator of SQLite, stated that the dialect won't change (removing syntax) in SQLite v3 during the WebSQL W3C standardization in the mailing list.
About 95% of all mobile devices already support WebSQL (iOS & Android & WindowsPhone (via official Microsoft sponsored extension)). And all desktop Chrome, Safari, Opera support WebSQL too. The only missing browsers are IE 11 and Firefox/FirefoxOS.
> Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved.
Everyone does not know this. Some people believe this, other people believe it should die in a fire. But whatever one things about the current state of the abandoned WebSQLDB spec, that is what WebSQLDB is, and you can't talk about -- honestly, at least -- it and pretend that it specifies SQL-92 as the required SQL dialect when, in fact, it specifies "the SQL dialect supported by SQLite 3.6.19".
You are essentially arguing that WebSQLDB should not have been abandoned based on the content of an imaginary WebSQLDB spec that never existed. If WebSQLDB had specified a (explicit, well-defined, use-case appropriate, single-user subset of) SQL-92 that would be different than what it actually specified, and the discussion would be different.
> The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others.
Nobody ever said WebSQL was intended to require a specific version of SQLite. But nearly every browser would have used SQLite, and experience has shown that when you expose functionality to the web, sites start depending on specific implementation quirks - check out all the gibberish people used to feed to IE6's CSS parser to trick it into behaving.
Also, note that SQLite is not what most people think of when they talk about SQL databases, if only because of its very "manifest typing". Maybe SQL92 is flexible enough to permit such things, but code written for SQLite is very likely to break horribly on other SQL implementations.
* There is a common misconception about SQLite3 dynamic type system. It can be done using SQL statements: http://stackoverflow.com/a/2762020, http://www.sqlite.org/datatype3.html . The browser vendors could enable static typing by default by adding a few lines of code or just a flag afaik. Beside that there are other SQL db engines. SQL-92 was the third revision of the SQL database query language. It's the common dialect that every SQL engine supports: http://en.wikipedia.org/wiki/SQL-92
* Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue) database engine and use a slightly different SQL dialect, everyone else would use SQLite anyway (and even Microsoft products like several Xbox games and Tools use SQLite). It's the same like supporting different XHR/AJAX API versions (like the ActiveX API calls of < IE9) or many other glitches. One could use a shim.
Without WebSQL support one has to compile SQLite via emscripten to asm.js -> 3 MB big JS file.
Or you know, one could use IndexedDB, because you don't need a freaking relational model, unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.
> everyone else would use SQLite anyway
That does not make it a web standard and after 25 years of web evolution, I can't believe we are still having the same problems. The web has been extremely successful for some obvious reasons, yet we keep forgetting those reasons. One of the web's primary traits is that it's based on documented standards and has multiple implementations. SQLite fails that test.
> One could use a shim
Or you could not have this problem in the first place. And technically you could implement WebSQL on top of IndexedDB.
> unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.
You mean like every iOS app that uses Core Data? And web apps will kill native apps with an approach like this?
> SQL-92 was the third revision of the SQL database query language.
And is completely irrelevant to WebSQLDB, which specifies "the SQL dialect supported by SQLite 3.6.19" -- not SQL-92 -- as what implementations must support. The SQL dialect supported by SQLite 3.6.19 does not include all of SQL-92, and includes extensions to SQL-92, so supporting SQL-92 would be neither necessary nor sufficient, from a supported SQL standpoint, to conform to the WebSQLDB spec.
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).
I edited my text, I meant: Safari on iOS. The touch interface introduces bugs that haven't been fixed for years. Desktop Safari is as buggy as Chrome, both originally based on the same Webkit code.
GoogleDocs v2, Word WebApp and iCloud Pages use a JavaScript based page layout engine that renders one DIV per line and don't use the contenteditable. Even the blinking cursor is a DIV. Though, even they do not support text-columns - something that would work out of the box with contenteditable. (GoogleDocs v1 used contenteditable, as well as SharePoint content editor and its first Word WebApp incarnation)
Implementing such a complex page layout engine plus internal document format (XML based?) is a lot of work and afaik there is no such open source JS library exists.
Agreed. For instance, IE (11 at least) doesn't permit <td> cells contenteditable. There are some workarounds, but then other browsers seem to have problems.
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).
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.
The actual work is going on here, but it sounds like it's only at the experimental stage: https://github.com/mozilla/firefox-ios/ I'm kindof curious to build it and see if it works.
I read that the only issue with getting competing browsers onto iOS is the developer agreement says you can't provide a program with a proprietary javascript engine in it. Frankly, iOS is so big now, I would argue that that restriction strays into competitive advantage territory, and the OP is proof of that. If I were a lawyer at Apple, I would suddenly become magnanimous and get the developer agreement changed such that competing web browser programs _only_ may host their own JavaScript engines.
It is "Firefox", but it's still using the Safari rendering and JavaScript engine under the hood (like Chrome for iOS does), because there isn't an option to do otherwise.
The first problem is political - firstly Apple make it so that you have to use the Webkit rendering engine for any third party browser.
The second problem is more technical - iOS has memory protection that means you can't take a writeable page and make it executable. This means that you can't (for example) JIT compile Javascript (or any other language). Their built in exception to this is Safari. This is why Safari is faster than webviews.
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.
While your opinion is of course paramount, you should try the Kindle Fire's browser. (I have the original Kindle Fire; newer models are probably better off -- that said, my original iPads still work fine and their browsers are perfectly usable, if slow.)
That said, I use Mobile Safari a lot and it seems pretty good. My experience of Android browsers pretty much ended when my Nexus 7 died, but certainly it did not seem superior in any respect -- and it was markedly inferior in some -- to Mobile Safari.
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.
"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.
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.
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.
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.
> 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?
That's not how the Sherman Anti-Trust act defines monopolies, and that's the law they'd have to be prosecuted under. A republican congress probably isn't going to pass laws designed to sanction the most valuable country in the world.
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.
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.
Not realistically. The NaCl APIs to support dynamically-generated code have to revalidate every time, so they're too slow to support the heavily self-modifying nature of compiled JavaScript.
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.
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?
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.
> 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.
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
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.
This would be anti competitive as soon as the app store had a majority market share.
If it became too difficult for them "Charge Facebook $100mm" they would replace support with a lower quantity web app and blame Apple.
The reality is that Apple don't have as much interest in the web anymore, they have achieved their goal with web standards (removing enough of a dependency on Flash so they didn't have to support it). They have no need to make the web a successful app platform, so why waste effort on it.
For Google it's part of their core business, look at Angular, Closure tools, Dart, GWT etc...
Most of it comes from AdWords, i.e. Google Search. Angular, GWT, Closure, and Dart have nothing to do with it. They're also all essentially abandonware from Google's point of view, because management has rightly realized they have nothing to do with their core business.
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.
> If the next version of iOS didn't even have a browser, you would be astonished at how little that impacted most users.
If time spent in an application is your criterion, true.
But that way you hugely underestimate the importance of, for instance, that daily (or even weekly) Google search the average user performs in their browser. It takes little time compared to your average social feed, but definitely impacts their lives. Just one quick example: a local business' phone number lookup.
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.
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.
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).
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.
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.
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.)
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.
> 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.
> 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.
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.
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.
> 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.
Very briefly, pointer events has 3 main drawbacks relative to the alternative:
1) Mobile-first web:
Pointer events would likely never supplant touch events on the web (especially without support from Safari). Since touch events are here to stay, supporting another largely redundant input model has a high long-term complexity cost on the web platform.
2) Performance:
The hit testing model required by pointer events imposes a non-trivial performance penalty (hit test on every movement event) that neither Android, iOS or touch events has. We're not willing to add any feature that increases the web's performance disadvantage relative to native mobile platforms.
3) Richness:
Pointer events requires that scrolling and event handling are mutually exclusive. This precludes some UI effects which are common on on mobile platforms (eg. pull to refresh). Recently strong developer feedback has lead us to change Chrome in the opposite direction here - enabling event handling while scrolling (see issue 293467 ).
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.
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
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
> 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.
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.
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.
"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.
They make a compelling technical and business argument against it; a reason the author acknowledges and dismisses because doesn't align with his thesis.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This isn't Google using Apple as a feature implementation oracle, this is Google looking at pointer events using both their "web developer" and "browser developer" hats and reaching a disappointing conclusion.
As a web developer, Google would have to use Touch Events because that's all that Apple supports. Chrome already supports Touch Events. That covers the overwhelming majority of their touch-enabled users, with code they already have. Rewriting that to use a newer modern standard everywhere is one thing, but writing a second implementation with no path to sunsetting the first is much harder to justify.
Coming full circle, if Google's web developers aren't going to use Pointer Events for the forseeable future, it is hard to justify Google the browser developer putting them high on their priority list.
Thanks for the reply, honestly I haven't thought about Google as web developer. Another point that I unfortunately missed is that if Apple implemented Pointer Events in WebKit, then the changes could probably be ported very quickly to Blink (I guess both code bases are still largely similar).
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.
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.
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.
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.
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.
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.
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.