4 ms·

>we need more features and it takes way to long for the W3C to deliver We also need features that work across all major browsers.

johnward 13y ago
It's kind of a catch22. We do need features to work across all browsers but the standards body moves to slowly. So vendors push out features they think are good. Others implement them. This is how we end up with multiple vendor prefixes. Then eventually the standards group gets around to accepting it and the vendors update to use the standard. Waiting for w3c might be the "right" way to develop standards but it also slows progress. I'm not sure which is worse. Even using the vendor prefix process things work in more browsers now than they did in the past.
munificent 13y ago
I don't know about the CSS stuff that spawned this thread, but the rest of the shadow DOM stuff is polyfilled to work in other browsers: https://github.com/Polymer/ShadowDOM https://github.com/Polymer/ShadowDOM
- potch 13y ago
  This is speculation: The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. Think about what it takes to make DOM invisible in the browser in a polyfill- overriding every DOM method to filter out shadowed nodes. I've heard reports of 10x slowdowns on DOM operations with this polyfill in place. The kicker? Web Components (specifically Custom Elements) lose almost all their encapsulation without Shadow DOM. Those of us who are betting heavy on Web Components as The Future™ are pretty anxious about this.
  - munificent 13y ago
    > The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. I'm not sure what you mean by "moving forward quickly". They've been hammering on this in the public eye for over three years. How many more years of salary should they pay before they get it out the door? At some point, you just have to ship.

johnward 13y ago

It's kind of a catch22. We do need features to work across all browsers but the standards body moves to slowly. So vendors push out features they think are good. Others implement them. This is how we end up with multiple vendor prefixes. Then eventually the standards group gets around to accepting it and the vendors update to use the standard. Waiting for w3c might be the "right" way to develop standards but it also slows progress. I'm not sure which is worse. Even using the vendor prefix process things work in more browsers now than they did in the past.

munificent 13y ago

I don't know about the CSS stuff that spawned this thread, but the rest of the shadow DOM stuff is polyfilled to work in other browsers: https://github.com/Polymer/ShadowDOM https://github.com/Polymer/ShadowDOM

potch 13y ago
This is speculation: The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. Think about what it takes to make DOM invisible in the browser in a polyfill- overriding every DOM method to filter out shadowed nodes. I've heard reports of 10x slowdowns on DOM operations with this polyfill in place. The kicker? Web Components (specifically Custom Elements) lose almost all their encapsulation without Shadow DOM. Those of us who are betting heavy on Web Components as The Future™ are pretty anxious about this.
- munificent 13y ago
  > The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. I'm not sure what you mean by "moving forward quickly". They've been hammering on this in the public eye for over three years. How many more years of salary should they pay before they get it out the door? At some point, you just have to ship.