5 ms·

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 n

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 12y 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.
- matthewmacleod 12y 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?
pcx 12y 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?
- mbel 12y 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.
  - pcx 12y ago
    The OP is also critical of Google. But doesn't make Apple any less wrong.
  - fpgeek 12y ago
    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.
    - mbel 12y ago
      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).
- idonthaveaname 12y ago
  Can you prove the quote was not spin to make Google appear to have the moral high-ground here?
- 542458 12y ago
  The author is cherrypicking here. See what Google actually said: 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... 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 12y ago
  As a BS excuse?
Touche 12y 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 12y 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.
  - Touche 12y ago
    Is there just 1 WebRTC implementation? Do Google and Mozilla not have their own separate codebases?
- matthewmacleod 12y 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.

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

matthewmacleod 12y 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?

pcx 12y 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?

mbel 12y 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.
- pcx 12y ago
  The OP is also critical of Google. But doesn't make Apple any less wrong.
- fpgeek 12y ago
  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.
  - mbel 12y ago
    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).
idonthaveaname 12y ago
Can you prove the quote was not spin to make Google appear to have the moral high-ground here?
542458 12y ago
The author is cherrypicking here. See what Google actually said: 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... 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 12y ago
As a BS excuse?

Touche 12y 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 12y 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.
- Touche 12y ago
  Is there just 1 WebRTC implementation? Do Google and Mozilla not have their own separate codebases?
matthewmacleod 12y 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.