3 ms·

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

Are they really? ... It's a Microsoft-backed spec that only Microsoft supports. Exactly, you've hit the nail on the head. It seems a bit strange to single out Apple when there are plenty of other vendors also not implementing it. That said, I know very little about the history of mobile browser development; have Apple historically dragged their feet on mobile Safari?

streptomycin 12y ago
have Apple historically dragged their feet on mobile Safari? Yes. Here's another example: http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-Broken-Bad http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B... Every other browser supports IndexedDB for years, then Apple finally releases support for it and it's completely broken in multiple unfathomably bizarre ways. Still hasn't been fixed.
- anon1385 12y ago
  That's hardly exclusive to Safari. IndexedDB seems to be a buggy mess in all browsers: http://pouchdb.com/2014/10/26/10-things-i-learned-from-reading-and-writing-the-pouchdb-source.html http://pouchdb.com/2014/10/26/10-things-i-learned-from-readi...
  - streptomycin 12y ago
    No, it's very exclusive to Safari. Add up all the other bugs in all the other browsers and it's about 0.1% as bad as Safari. It's almost unfathomable how huge and severe the bugs are in Safari. That's why the PouchDB solution was to simply not use IndexedDB on Safari: http://pouchdb.com/2014/09/22/3.0.6.html http://pouchdb.com/2014/09/22/3.0.6.html Here's my experience from building a fairly complex app that VERY heavily uses IndexedDB. If you follow the IndexedDB spec, you'll wind up with something that is 99% working in Firefox and Chrome. If you happen to run into that 1%, you'll find that Firefox and Chrome devs are very responsive and want to make it work. IE is a little buggy and is missing a couple features, but it's not impossible to work around them. Unfortunately the IE dev team is less responsive and it's not clear if/when they will fix things. But to support Safari, you'd have to do things that are utterly horrifying. It's basically not worth even trying.
CSMastermind 12y 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.
- 542458 12y ago
  > 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. That's only one of their reasons. https://code.google.com/p/chromium/issues/detail?id=162757#c64 https://code.google.com/p/chromium/issues/detail?id=162757#c... https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2RH6mQCFQHk8R01s5qvjm2Po/edit#slide=id.g355c5631f_129 https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2... In particular, see the notes in slide 6. They have several reasons that include performance, flexibility, and compatibility.

streptomycin 12y ago

have Apple historically dragged their feet on mobile Safari? Yes. Here's another example: http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-Broken-Bad http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B... Every other browser supports IndexedDB for years, then Apple finally releases support for it and it's completely broken in multiple unfathomably bizarre ways. Still hasn't been fixed.

anon1385 12y ago
That's hardly exclusive to Safari. IndexedDB seems to be a buggy mess in all browsers: http://pouchdb.com/2014/10/26/10-things-i-learned-from-reading-and-writing-the-pouchdb-source.html http://pouchdb.com/2014/10/26/10-things-i-learned-from-readi...
- streptomycin 12y ago
  No, it's very exclusive to Safari. Add up all the other bugs in all the other browsers and it's about 0.1% as bad as Safari. It's almost unfathomable how huge and severe the bugs are in Safari. That's why the PouchDB solution was to simply not use IndexedDB on Safari: http://pouchdb.com/2014/09/22/3.0.6.html http://pouchdb.com/2014/09/22/3.0.6.html Here's my experience from building a fairly complex app that VERY heavily uses IndexedDB. If you follow the IndexedDB spec, you'll wind up with something that is 99% working in Firefox and Chrome. If you happen to run into that 1%, you'll find that Firefox and Chrome devs are very responsive and want to make it work. IE is a little buggy and is missing a couple features, but it's not impossible to work around them. Unfortunately the IE dev team is less responsive and it's not clear if/when they will fix things. But to support Safari, you'd have to do things that are utterly horrifying. It's basically not worth even trying.

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

542458 12y ago
> 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. That's only one of their reasons. https://code.google.com/p/chromium/issues/detail?id=162757#c64 https://code.google.com/p/chromium/issues/detail?id=162757#c... https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2RH6mQCFQHk8R01s5qvjm2Po/edit#slide=id.g355c5631f_129 https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2... In particular, see the notes in slide 6. They have several reasons that include performance, flexibility, and compatibility.