When and if WebKit implements Shadow DOM, we won't use these vestiges of the old code. Note that this checkin (and the earlier actual removal of the old implementation) are not a commentary on our long-term plans to support it or not.
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.)
Specifically, the references to 60fps, mobile, and 8.8 million lines are all jokes. I hate to explain jokes. But I see a lot of people in the comments trying to read serious deep meaning into these that is just not there.
I don't know if I got it wrong, but for me, as soon as I read it, it was an obvious joke reference to Google's BS excuses for removing Adobe's CSS layout code from Blink.
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.
Inside jokes are good fun at the time. The problem is when you come back to them later and no longer remember the context. I can just imagine a manager coming in a few years' time and drawing a wrong conclusion from those lines and using it as the basis for doing something that dooms the entire company. (Somehow.)
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.
I don't check in to WebKit as much as I used to but I probably would not choose to make my own commit messages quite so inside jokey. That being said, we try to have fun on this project.
Many WebKit developers are very actively commenting on the Web Components family of specs. We don't generally comment specifically on future implementation plans though.
It looks like it was already removed, this is just some stuff they missed? Purge remaining ENABLE(SHADOW_DOM) cruft ... Showing 66 changed files with 40 additions and 399 deletions. [1]
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.[1]
It looks like this was just some last remaining code behind a leftover build flag.
Some web browsers use a DOM to make up UI elements (e.g. sliders, web video element etc). This allowed browser developers to make these elements using DOM elements. It's called a Shadow DOM because you can't actually get access to the DOM elements within each UI element via Javascript.
Q. Why is Apple doing this? A. They're moving this stuff to native code in an effort to speed up rendering on mobile.
> 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
Even in native code, having the shadow DOM may slow down code. A web page is a tree of nodes. With shadow DOM, you replace 'native button here' nodes by trees of nodes ('rounded rect with text inside it') that can be individually styled.
If you store those shadow DOM trees in the full page hierarchy, any JavaScript that walks the tree must inspect every node for its 'part of shadow DOM' bit (code that asks for all div's shouldn't see any div's in the shadow DOM) That slows down those walks. If you store them outside of the full hierarchy, your rendering code (which must walk the shadow DOM nodes) must know to inspect each node to see whether it has a shadow DOM tree. That slows down rendering.
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.
FWIW, no web browser uses native platform controls to render HTML form controls. Shadow DOM just gives developers a way to encapsulate what they're already doing on the web.
Ugh. Commit message jokes. At least mark it as such so people have a clue WTF was changed a year down the line (even if doing so violates some fundamental law of humor). Maybe I'm just being cautious in this context... the BBC really helped warp my sense of humor growing up.
It's an in-joke taking aim at Blink's stated 2014 goal of optimizing for mobile performance at the expense of supporting things like CSS Regions. Shadow DOM is also the subject of some controversy, as Blink and Mozilla seem intent on pressing ahead with implementing it without full buy-in from all vendors or even the WG.
Shadow DOM is a mechanism by which a browser can inject a subtree into the DOM, but it won't be visible to JS.
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.
Shadow DOM allows the contents of a component to be styled independently from the enclosing page. As far as I can tell, there currently isn't any other good way of doing robust, scoped CSS (short of iframes). I'll be very, very, sad if shadow DOM dies.
They're finishing up the removal of unmaintained and essentially dead code which started after the Blink fork.
> Isn't Shadow DOM necessary?
To what?
> 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.
I've read some comments dating from the blink fork saying "that's healthier to have many different rendering engines", but somehow after reading that news about shadow dom, i feel like it isn't that obvious ( unless you think that webkit is going the way of the dodo and that it's a good thing)
They're just cleaning up some leftovers, shadow dom code was excised from webkit back in May after the blink fork. It was unused, unmaintained (the maintainer left with Blink) and did indeed amount to about 8.8mLOC.
So nowadays to Apple innovation means to increase fps from 59 to 60?
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.
> So nowadays to Apple innovation means to increase fps from 59 to 60?
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.
Not to mention shadow dom isn't actually a layout technique, so centering a div (which is currently possible if non-obvious) is an odd tangent to mention.
It's a common misconception that Shadow DOM is required to create a "web component". What it brings to the table is style and dom encapsulation. Not using it means components won't have those benefit (by default), but there's nothing stopping people from creating custom elements that are not encapsulated.
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.
Adding powerful new APIs to the web platform benefits more than just Angular, no? The set of evolving standards-based technologies behind "web components" (templates, Shadow DOM, HTMLImports, custom elements) can be utilized by any framework. More tools in our toolbox.
>Adding powerful new APIs to the web platform benefits more than just Angular, no?
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.
That might be a bit of an exaggeration, although on the Angular side, we'd certainly like to have it pref'd on by default this summer (as unlikely as that may be).
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...
>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.
They needed to have an alternative to flash to make not implementing it viable...
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.
>Of course, not everyone wants to see the web-application model become too powerful...
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.
I think it was just a confusion between Shadoe DOM and React's virtual DOM, which is basically a pure-JavaScript doppelgänger of the real DOM for your React components.
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.)