
Apple Removes Shadow DOM from Safari - vjeux
http://trac.webkit.org/changeset/164131
======
om2
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.)

~~~
om2
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.

~~~
mathias
The 8.8 million lines joke refers to
<[http://techcrunch.com/2013/05/16/google-has-already-
removed-...](http://techcrunch.com/2013/05/16/google-has-already-
removed-8-8m-lines-of-webkit-code-from-blink/>).

~~~
0x0
It references a generic 404 page?

Very funny.

~~~
bjcy
Looks like the closing bracket got included into the url. Here's a fixed
version: [http://techcrunch.com/2013/05/16/google-has-already-
removed-...](http://techcrunch.com/2013/05/16/google-has-already-
removed-8-8m-lines-of-webkit-code-from-blink/)

------
taspeotis

        Apple Removes Shadow DOM from Safari (webkit.org)
    

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]

[1]
[https://github.com/WebKit/webkit/commit/0e1e0ebf18aaac177366...](https://github.com/WebKit/webkit/commit/0e1e0ebf18aaac177366c797cfb1ae11011e55a1)

~~~
jordwalke
Oh, you mean these are just the _remaining_ 8.8 million lines of shadow DOM
code?

~~~
magicalist
No? I don't understand how your question makes sense in relation to the GP
comment. You can see the entirety of the diff here:
[https://bugs.webkit.org/attachment.cgi?id=224240&action=diff](https://bugs.webkit.org/attachment.cgi?id=224240&action=diff)

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.

[1] [https://lists.webkit.org/pipermail/webkit-
dev/2013-May/02489...](https://lists.webkit.org/pipermail/webkit-
dev/2013-May/024894.html)

~~~
masklinn
You're correct, by and large shadow dom "support" (unmaintained and behind a
flag) was removed back in may:
[http://trac.webkit.org/changeset/150070](http://trac.webkit.org/changeset/150070)
[http://trac.webkit.org/changeset/150430](http://trac.webkit.org/changeset/150430)
[http://trac.webkit.org/changeset/150464](http://trac.webkit.org/changeset/150464)

------
schappim
For those asking what does it mean:

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.

~~~
magicalist
> _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](https://news.ycombinator.com/item?id=7243328)

~~~
Someone
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.

~~~
tedmielczarek
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.

------
Bluestrike2
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.

I just wish it warped others a bit more as well.

------
Geee
Can someone explain this? Isn't Shadow DOM necessary? What is this 60fps on
mobile intent and how it relates to Shadow DOM?

~~~
mwenge
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.

~~~
nephyrin
Mozilla (along with most everyone else) took issue with Google's intent to
ship Shadow DOM. See e.g. this exchange:

[http://lists.w3.org/Archives/Public/www-
style/2014Feb/0152.h...](http://lists.w3.org/Archives/Public/www-
style/2014Feb/0152.html)

------
pjmlp
For those asking what Shadow DOM is all about,

[http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...](http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom)

------
bsaul
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)

------
chucknelson
Does anyone have any real info on this? I don't think we have enough context
or details to really know what this means, do we?

~~~
masklinn
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.

~~~
kevinSuttle
Source?

------
dgregd
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.

~~~
vjeux
Flexbox is actually very good and works on all the mobile browsers today and
most desktop browsers if you ignore old IE.

~~~
emn13
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.

------
lennel
what impact will this have on the web component standard implementation in
webkit?

~~~
masklinn
The shadow dom support was removed back in May after the blink fork:
[https://www.webkit.org/blog/2455/last-week-in-webkit-
million...](https://www.webkit.org/blog/2455/last-week-in-webkit-millions-of-
lines/) these are just leftovers.

~~~
MrBuddyCasino
Still the question remains, WebComponents need shadow DOM right?

~~~
dasmoth
Yes.

Shadow DOM is a key part of web components: [http://www.w3.org/TR/components-
intro/#shadow-dom-section](http://www.w3.org/TR/components-intro/#shadow-dom-
section)

~~~
lennel
That is what I thought, so dead the tech is dead in the water.

~~~
coldtea
Well, it isn't even a standard yet. Google wants to push it just to have it
for Angular.

~~~
ebidel
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.

~~~
coldtea
> _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.

------
apunic
What is the shadow DOM in Safari and will it interfere with React JS?

~~~
masklinn
There is no relation between shadow dom and react.

~~~
kibibu
Perhaps they were thinking of [http://www.polymer-
project.org/](http://www.polymer-project.org/)?

~~~
chc
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.

------
jamesaguilar
How is this 8.8M lines? It looks like only about 80kB of diffs.

~~~
DougBTX
Looks like it is a reference to this event:
[http://www.engadget.com/2013/05/16/google-blink-team-
pulls-8...](http://www.engadget.com/2013/05/16/google-blink-team-
pulls-8-8-million-lines-of-webkit-code/)

