Apple Removes Shadow DOM from Safari(trac.webkit.org)
trac.webkit.org
Apple Removes Shadow DOM from Safari
http://trac.webkit.org/changeset/164131
14 comments
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.
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.
The 8.8 million lines joke refers to <http://techcrunch.com/2013/05/16/google-has-already-removed-....
It references a generic 404 page?
Very funny.
Very funny.
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-...
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.
… of course, the manager still might not have ;-)
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 ;-)
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.
Apple Removes Shadow DOM from Safari (webkit.org)
[1] https://github.com/WebKit/webkit/commit/0e1e0ebf18aaac177366...
Oh, you mean these are just the remaining 8.8 million lines of shadow DOM code?
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
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...
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...
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/150430 http://trac.webkit.org/changeset/150464
That's the joke, I assume - ALL of WebKit is less than 8.8 million lines.
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.
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
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.
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.
I just wish it warped others a bit more as well.
I just wish it warped others a bit more as well.
Can someone explain this? Isn't Shadow DOM necessary? What is this 60fps on mobile intent and how it relates to Shadow DOM?
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.
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.h...
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.
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.
> 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.
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.
> Hence 60fps goal.
Is that for embedded video playback? Whatelse could it apply to? Any idea?
Is that for embedded video playback? Whatelse could it apply to? Any idea?
Wild guess: Rendering live web pages (html+js+css, with animations and scrolling) at 60 frames per second.
As stated in nearby comments, it's an in-joke. There's no "goal".
The FPS count is generally with regards to scrolling and built in animation / transition rendering.
For those asking what Shadow DOM is all about,
http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...
http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...
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)
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?
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.
Source?
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.
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.
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.
>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.
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.
Flexbox is actually very good and works on all the mobile browsers today and most desktop browsers if you ignore old IE.
what impact will this have on the web component standard implementation in webkit?
The shadow dom support was removed back in May after the blink fork: https://www.webkit.org/blog/2455/last-week-in-webkit-million... these are just leftovers.
Still the question remains, WebComponents need shadow DOM right?
Yes.
Shadow DOM is a key part of web components: http://www.w3.org/TR/components-intro/#shadow-dom-section
Shadow DOM is a key part of web components: http://www.w3.org/TR/components-intro/#shadow-dom-section
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.
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.
That is what I thought, so dead the tech is dead in the water.
Well, it isn't even a standard yet. Google wants to push it just to have it for Angular.
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.
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.
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.
Yes, but the question is whether Web Components is needed.
Needed for a document-based web? maybe not.
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...
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.
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.
That was to kill flash. Now they have video and animations sorted they don't want to eat into their native platform.
>That was to kill flash
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.
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.
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.
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.
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.
Try Reactjs. Does all that at 60 fps without the Shadow DOM on all modern browsers.
What is the shadow DOM in Safari and will it interfere with React JS?
There is no relation between shadow dom and react.
Perhaps they were thinking of http://www.polymer-project.org/?
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.
How is this 8.8M lines? It looks like only about 80kB of diffs.
Looks like it is a reference to this event: http://www.engadget.com/2013/05/16/google-blink-team-pulls-8...
It's a joke. The entirety of WebKit is less than 8.8 million lines of code.
There were 439 lines changed in this commit. Clearly it was an exaggeration, though it was an oddly specific one.
[deleted]
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.)