The checkin message is a series of inside jokes, which I see have confused many people. You can just interpret this as "remove some remnants of dead code, also I am a bit of a jokester". (Where "I" is the author of the patch, not me.)
They used the same speed, mobile and "too many lines of code" comment, IIRC.
Also, knowing that Google really pushes and wants the Shadow DOM (see recent hoopla with W3C about them shipping their own version ahead of standard), WebKit removing it could also be seen as a FU to Google.
Change "million" to "zillion" and put the words and phrases "synergy", "looking forwards" and "value-add" and no developer would ever have guessed that it was anything other than a joke.
… of course, the manager still might not have ;-)
Apple Removes Shadow DOM from Safari (webkit.org)
I believe most of the shadow DOM stuff was removed almost a year ago after the Blink fork, because the maintainers of the code were leaving with Blink. eg
> Is anyone intending to maintain the feature on trunk? If not, we should simply get rid of code behind this build flag for now; keeping unmaintained code that doesn't even compile isn't healthy for the project of our size.
It looks like this was just some last remaining code behind a leftover build flag.
Q. Why is Apple doing this? A. They're moving this stuff to native code in an effort to speed up rendering on mobile.
This doesn't really make sense, so I assume you're extrapolating from the commit comment. There is no "this" to move, first of all, and the shadow DOM was already "native code" for whatever that means, anyway. See om2's comment for what the whole "60fps on mobile" comment meant: https://news.ycombinator.com/item?id=7243328
On top of that, more code = more cache misses, more code = less room for user data, and your nodes likely will grow a bit in size (at least on average) if you add that 'part of shadow DOM' bit.
I don't have the faintest idea how large the effect of all this is, but there will be an effect.
I just wish it warped others a bit more as well.
This was often used for things like custom elements (inputs and such). I presume it wasn't very popular to use the shadow dom in webkit.
Far as I recall, there's also talk about using the shadow dom for injecting foreign fragments into the DOM in a secure manner (web components). Although there's probably ways to achieve this without the full shadow dom.
They're finishing up the removal of unmaintained and essentially dead code which started after the Blink fork.
> Isn't Shadow DOM necessary?
> What is this 60fps on mobile intent and how it relates to Shadow DOM?
Shadow DOM requires hooks throughout the engine. If you remove the hooks (because nobody uses them because shadow dom is not supported) the engine is lighter and executes faster. Hence 60fps goal.
Is that for embedded video playback? Whatelse could it apply to? Any idea?
Shadow DOM might be really, really useful for millions of developers building ordinary business web apps. It is 2014 and would be good to add new things like Shadow DOM, new layout models so in _2020_ there will be standard and a sane way to center a ... div.
It is a joke at Blink removing CSS Regions' 10k LOC for mobile performance.
> Shadow DOM might be really, really useful for millions of developers building ordinary business web apps.
Current implementation of Shadow DOM has little to do with future implementation of Web Component's Shadow DOM (See https://news.ycombinator.com/item?id=7243328). It was already removed 9 months ago after the Blink fork due to its experimental nature and lack of maintainer (http://trac.webkit.org/changeset/150070). This commit only removing the remaining parts of it.
No, and count the ways you got it wrong:
1) This is not Apple in general, it's a specific team at Apple.
2) The never said this is "innovation" to them. Just a goal they have.
3) Who said it's from 59 to 60? Might be from 30 to 60fps.
4) Smooth animation/scrolling experience matters and IS innovation.
Even worse, the whole line is a joke -- at a similar Google line.
Shadow DOM is a key part of web components: http://www.w3.org/TR/components-intro/#shadow-dom-section
An analogy can be made to requestAnimation. raF isn't required to create animations, but it's highly useful in that context. raF can also be used for other use cases outside of animations (scroll effects, etc). Shadow DOM is the same IMO. It's a useful standalone technology, but when used in the context of web components, it really shines.
Maybe, but that doesn't mean Google cares about enpowering the web platform in general.
If they did they wouldn't have removed other standard code (css regions), and they wouldn't have pushed for their, non-standard, Shadow DOM implementation.
Anyways, I really think people are sort of attributing malice to Glazkov's remarks where none really ever existed, WRT shipping the shadow DOM in its current state.
Needed to turn the web into a solid application platform with good support for composition and code reuse? I'm going to say yes (or if not Web Components then something that facilitates better scoping of code and CSS).
Of course, not everyone wants to see the web-application model become too powerful...
Is that directed at Apple? Because they have had the most powerful mobile web engine for years -- and they continue evolve their desktop one. Heck, the gave us stuff like Canvas and CSS animations.
Nope, they never supported flash in mobile in the first place. And they continue to do so today, years after Flash has been dead and burried.
If they hadn't added canvas/video etc to HTML and there was no way to do half the things flash did, it would have been trumped by Android and their mobile flash player.
That's funny, since when the iPhone first came out, Apple claimed there wasn't gonna be a native SDK, and developers would just write all their apps in HTML.