6 ms·

Apple Removes Shadow DOM from Safari

90 points by vjeux 13y ago

jezell 13y ago
https://lists.webkit.org/pipermail/webkit-dev/2013-May/024894.html https://lists.webkit.org/pipermail/webkit-dev/2013-May/02489...
taspeotis 13y ago
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/0e1e0ebf18aaac177366c797cfb1ae11011e55a1 https://github.com/WebKit/webkit/commit/0e1e0ebf18aaac177366...
- jordwalke 13y ago
  Oh, you mean these are just the remaining 8.8 million lines of shadow DOM code?
  - magicalist 13y ago
    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/024894.html https://lists.webkit.org/pipermail/webkit-dev/2013-May/02489...
    - masklinn 13y ago
      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
  - azakai 13y ago
    That's the joke, I assume - ALL of WebKit is less than 8.8 million lines.
lennel 13y ago
what impact will this have on the web component standard implementation in webkit?
- masklinn 13y ago
  The shadow dom support was removed back in May after the blink fork: https://www.webkit.org/blog/2455/last-week-in-webkit-millions-of-lines/ https://www.webkit.org/blog/2455/last-week-in-webkit-million... these are just leftovers.
  - MrBuddyCasino 13y ago
    Still the question remains, WebComponents need shadow DOM right?
    - dasmoth 13y ago
      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 13y ago
        That is what I thought, so dead the tech is dead in the water.
        coldtea 13y ago
        Well, it isn't even a standard yet. Google wants to push it just to have it for Angular.
        caitp 13y ago
        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.
chucknelson 13y ago
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 13y ago
  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 13y ago
    Source?
Geee 13y ago
Can someone explain this? Isn't Shadow DOM necessary? What is this 60fps on mobile intent and how it relates to Shadow DOM?
- masklinn 13y ago
  > Can someone explain this? 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.
  - why_me 13y ago
    > Hence 60fps goal. Is that for embedded video playback? Whatelse could it apply to? Any idea?
    - 0x0 13y ago
      Wild guess: Rendering live web pages (html+js+css, with animations and scrolling) at 60 frames per second.
      - danabramov 13y ago
        As stated in nearby comments, it's an in-joke. There's no "goal".
    - joegaudet 13y ago
      The FPS count is generally with regards to scrolling and built in animation / transition rendering.
- pyalot2 13y ago
  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.
apunic 13y ago
What is the shadow DOM in Safari and will it interfere with React JS?
- masklinn 13y ago
  There is no relation between shadow dom and react.
  - kibibu 13y ago
    Perhaps they were thinking of http://www.polymer-project.org/ http://www.polymer-project.org/?
    - chc 13y ago
      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.
pjmlp 13y ago
For those asking what Shadow DOM is all about, http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...
jamesaguilar 13y ago
How is this 8.8M lines? It looks like only about 80kB of diffs.
- euank 13y ago
  There were 439 lines changed in this commit. Clearly it was an exaggeration, though it was an oddly specific one.
- DougBTX 13y ago
  Looks like it is a reference to this event: http://www.engadget.com/2013/05/16/google-blink-team-pulls-8-8-million-lines-of-webkit-code/ http://www.engadget.com/2013/05/16/google-blink-team-pulls-8...
- azakai 13y ago
  It's a joke. The entirety of WebKit is less than 8.8 million lines of code.
bsaul 13y ago
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)
om2 13y ago
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 13y ago
  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.
  - coldtea 13y ago
    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.
  - mathias 13y ago
    The 8.8 million lines joke refers to <http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/> http://techcrunch.com/2013/05/16/google-has-already-removed-....
    - 0x0 13y ago
      It references a generic 404 page? Very funny.
      - bjcy 13y ago
        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-8-8m-lines-of-webkit-code-from-blink/ http://techcrunch.com/2013/05/16/google-has-already-removed-...
schappim 13y ago
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 13y ago
  > 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 13y ago
    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 13y ago
      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.
dgregd 13y ago
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.
- sirn 13y ago
  > 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 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 http://trac.webkit.org/changeset/150070). This commit only removing the remaining parts of it.
- coldtea 13y ago
  >So nowadays to Apple innovation means to increase fps from 59 to 60? 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.
- vjeux 13y ago
  Flexbox is actually very good and works on all the mobile browsers today and most desktop browsers if you ignore old IE.
  - emn13 13y ago
    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.
deleted 13y ago
[deleted]
Bluestrike2 13y ago
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.

90 points by vjeux 13y ago

https://lists.webkit.org/pipermail/webkit-dev/2013-May/024894.html https://lists.webkit.org/pipermail/webkit-dev/2013-May/02489...

taspeotis 13y ago

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/0e1e0ebf18aaac177366c797cfb1ae11011e55a1 https://github.com/WebKit/webkit/commit/0e1e0ebf18aaac177366...

jordwalke 13y ago
Oh, you mean these are just the remaining 8.8 million lines of shadow DOM code?
- magicalist 13y ago
  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/024894.html https://lists.webkit.org/pipermail/webkit-dev/2013-May/02489...
  - masklinn 13y ago
    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
- azakai 13y ago
  That's the joke, I assume - ALL of WebKit is less than 8.8 million lines.

lennel 13y ago

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

masklinn 13y ago
The shadow dom support was removed back in May after the blink fork: https://www.webkit.org/blog/2455/last-week-in-webkit-millions-of-lines/ https://www.webkit.org/blog/2455/last-week-in-webkit-million... these are just leftovers.
- MrBuddyCasino 13y ago
  Still the question remains, WebComponents need shadow DOM right?
  - dasmoth 13y ago
    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 13y ago
      That is what I thought, so dead the tech is dead in the water.
      - coldtea 13y ago
        Well, it isn't even a standard yet. Google wants to push it just to have it for Angular.
        caitp 13y ago
        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.

chucknelson 13y ago

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 13y ago
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 13y ago
  Source?

Geee 13y ago

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

masklinn 13y ago
> Can someone explain this? 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.
- why_me 13y ago
  > Hence 60fps goal. Is that for embedded video playback? Whatelse could it apply to? Any idea?
  - 0x0 13y ago
    Wild guess: Rendering live web pages (html+js+css, with animations and scrolling) at 60 frames per second.
    - danabramov 13y ago
      As stated in nearby comments, it's an in-joke. There's no "goal".
  - joegaudet 13y ago
    The FPS count is generally with regards to scrolling and built in animation / transition rendering.
pyalot2 13y ago
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.

apunic 13y ago

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

masklinn 13y ago
There is no relation between shadow dom and react.
- kibibu 13y ago
  Perhaps they were thinking of http://www.polymer-project.org/ http://www.polymer-project.org/?
  - chc 13y ago
    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.

pjmlp 13y ago

For those asking what Shadow DOM is all about, http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...

jamesaguilar 13y ago

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

euank 13y ago
There were 439 lines changed in this commit. Clearly it was an exaggeration, though it was an oddly specific one.
DougBTX 13y ago
Looks like it is a reference to this event: http://www.engadget.com/2013/05/16/google-blink-team-pulls-8-8-million-lines-of-webkit-code/ http://www.engadget.com/2013/05/16/google-blink-team-pulls-8...
azakai 13y ago
It's a joke. The entirety of WebKit is less than 8.8 million lines of code.

bsaul 13y ago

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)

om2 13y ago

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 13y ago
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.
- coldtea 13y ago
  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.
- mathias 13y ago
  The 8.8 million lines joke refers to <http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/> http://techcrunch.com/2013/05/16/google-has-already-removed-....
  - 0x0 13y ago
    It references a generic 404 page? Very funny.
    - bjcy 13y ago
      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-8-8m-lines-of-webkit-code-from-blink/ http://techcrunch.com/2013/05/16/google-has-already-removed-...

schappim 13y ago

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 13y ago
> 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 13y ago
  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 13y ago
    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.

dgregd 13y ago

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.

sirn 13y ago
> 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 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 http://trac.webkit.org/changeset/150070). This commit only removing the remaining parts of it.
coldtea 13y ago
>So nowadays to Apple innovation means to increase fps from 59 to 60? 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.
vjeux 13y ago
Flexbox is actually very good and works on all the mobile browsers today and most desktop browsers if you ignore old IE.
- emn13 13y ago
  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.

deleted 13y ago

[deleted]

Bluestrike2 13y ago

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.