
Introducing Shadow DOM API - twsted
https://www.webkit.org/blog/4096/introducing-shadow-dom-api/
======
EdSharkey
DOM is such a crufty old API/data structure to work with and with CSS,
computationally it's a pig. Anything we can do to isolate bits and bobs on the
page from one another and make DOM easier for the browser to render and emit
events for, the better.

I just think the Shadow DOM and Web Components are too complex to work with as
designed. The componenty composability of React definitely seems real to me,
whereas I don't have such optimism about Web Components.

All I would want/need is a lightweight version of iframe whereby it functions
like a javascript security and css styles sandbox, call it a subwindow. A
subwindow could load html/css/js independently from the parent page like a Web
Worker does, or it could borrow from assets the parent page has loaded and its
HTML could be inlined as innerHTML statically/dynamically from the parent page
(at creation time.)

A subwindow would have an independent global/window object from the parent
window. And, you could postMessage/onMessage communicate with the parent
window if you needed. It could be constructed with its own dedicated DOM
thread, or it could schedule on the parent's thread if you didn't want another
thread spawned. Paints would have to be synchronized between the DOM threads,
which could be a bummer.

I just want an inline iframe, which I know is like saying I want an "inline
inline frame". ;)

~~~
hayksaakian
Isn't that how normal frames used to work?

Before they were deprecated for iframes?

~~~
EdSharkey
I don't want to partition the page the way frames/frameset did, I want to
sandbox code and content the way iframe does, just in a more lightweight
fashion. If I could couple that sandboxing with a component factory library
like React, that could really be something else.

------
BinaryIdiot
At first I was gung ho about web components. I was so excited I used Mozilla's
X-Tag for one project and Polymer in another project. I am now no longer in
favor of using them and it makes me sad, actually.

Web components are simply too heavy. They add latency to download (yeah you
can combine them but I've never found tooling (including Vulcanize) that
worked very well). Also the shadow dom's separation makes styling more
difficult across multiple components requiring awkward shadow dom hacks in the
CSS and / or duplicating / adding more CSS to components themselves. Same with
using JavaScript and third party libraries not expecting to use the ShadowDom
though this isn't so bad.

When I'm working on something that needs to be optimized for low bandwidth /
high latency I go as lightweight as possible and I concat as much stuff
together as I can. I want web components to work so badly but they're way too
slow for me to use anytime soon.

~~~
mozumder
The other terrible side effect of web components is that it gives the
standards group an excuse to never update HTML anymore. "Why do we need HTML6
when you can make anything you want with big, heavy Javascript-based web
component that takes expert programmers to make?" Indeed.

Just say no to web components. Say yes to upgrading HTML specs directly.

~~~
nostrademons
That's the exact opposite of the reason why browser vendors are implementing
web components. It's so that they can get direct, real-world feedback from
actual users of a feature before baking it into standards and making it
impossible to remove from the web. The intent has always been that the most
frequently used webcomponents will end up getting baked into the browser, and
then into the HTML spec.

We used to write web specs speculatively, without having feedback from real-
world use, and it was a disaster. Take a look at the list of W3C standards:

[https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Stan...](https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Standards)

How many of them do you _actually_ use? Remember when everything was XML,
XPATH, XSLT, the semantic web, and we were going to replace HTML with XHTML?

~~~
mozumder
_The intent has always been that the most frequently used webcomponents will
end up getting baked into the browser, and then into the HTML spec._

That's nice in theory, but what's happening in reality is that no component is
going to be standardized, and HTML remains stagnant for another 15 years.

~~~
nostrademons
It's a little hard to make that argument when _web components themselves aren
't standardized yet_, and are fully supported natively in only one of the
major browsers.

There's pretty ample evidence that common webdeveloper behavior _does_ make it
into the spec, eg. JQuery => querySelectorAll, Javascript animations => CSS
transitions & animations, long-polling => websockets, common layouts =>
<header>/<footer>/<main>/<nav> elements, dropdowns => <details>/<summary>
elements, the addition of date/datetime/color/number/range/tel input types,
etc. If you're still coding HTML like you did in 2000, you are now very
obsolete.

------
Zikes
I'm pretty excited about what this will do for web components development.
Polyfills have come very close, but deeply nested components can become a
tangled mess in no time.

If anyone is interested in getting started with web components, I recommend
taking a look at Google's Polymer[1] library. It's a fairly opinionated
approach, but has a relatively small learning curve.

[1] [https://www.polymer-project.org/1.0/](https://www.polymer-
project.org/1.0/)

~~~
david-given
I rejigged my personal website using Polymer and was thoroughly impressed.
It's pretty heavyweight, mostly because I'm too cheap to precompile and minify
my Javascript, but the modular approach means that I can now, finally, apply
_actual software engineering principles_ to building websites.

The documentation could be better, and you pretty much have to like Material
Design, and there could be a richer set of standard widgets available, and it
desperately needs a CDN, but other than that I found it really pleasant to
use.

What I _haven 't_ tried is building any kind of reactive interface. It's got
some support for binding elements to data, but I didn't explore that much.
Anyone care to comment?

~~~
wwweston
> actual software engineering principles to building websites

What are the actual software engineering principles Polymer enables developers
to apply?

~~~
pfooti
Separation of concerns and better variable scoping as well. In a webcomonent
inside a shadow dom, you can do something like input id="mainInput" or some
other generic-named DOM id, without worrying that some other third-party
library or component will create another node with the same id.

Similarly for CSS selectors and class names - I mean, BEM and SMACCS and stuff
are cool and all, but it's also nice to know that my CSS styles won't leak
outside the component, so I can just do div class="main" or something and not
worry about how other developers name their classes on other branches of the
DOM.

------
TeeWEE
I really like webcomponents, but they still statefully update the UIX, just
like most native ui frameworks.

React solves this by giving a declarative functional approach to
webdevelopment.

Would it be possible to combine both react with webcomponents? If so, are
there any demo"s out there? I couldnt find anything.

~~~
mbrock
That depends on what you are doing inside of your web components. You can load
any JavaScript you want in there, you know. If you want to use React, that's
fine. Web Components is just a set of extensions to the DOM standards to allow
encapsulated custom elements.

------
gravity13
The things I'm curious about with Shadow Dom:

\- How does it affect performance, if say, a large application is composed of
many shadow dom elements, each containing a large amount of redundant CSS?

\- Will there be a way to let certain css styles "leak" through while
encapsulating others? Or is any type of native inheritance gone?

~~~
Zikes
Because a template would define the styles once, but be stamped multiple
times, there should be minimal redundant copies of the styles themselves. How
this performs will remain to be seen, as it would be up to the browsers to
implement the spec optimally.

You can "pierce" the shadow DOM with the ">>>" combinator (previously /deep/),
allowing you to style elements from outside of the shadow DOM. This is
discouraged in the case of web components, however, as a component is supposed
to operate as a black box entity. Instead, a component can expose APIs for
styling, such as with CSS variables: [https://www.polymer-
project.org/1.0/docs/devguide/styling.ht...](https://www.polymer-
project.org/1.0/docs/devguide/styling.html#xscope-styling-details)

Edit: This article[1] has details on performance and styling options.

[1] [https://hacks.mozilla.org/2015/06/the-state-of-web-
component...](https://hacks.mozilla.org/2015/06/the-state-of-web-components/)

~~~
arota
The last I had read[1], the intention is to deprecate shadow piercing
combinators altogether.

[1] -
[https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meetin...](https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting)

~~~
Zikes
I guess that would make it discouraged in all cases, then.

------
cletusw
I'm sure Chrome/Opera and Firefox will tweak their implementations to match
the updated spec soon, then all that's left will be Edge, and they've
expressed intent to implement!!
[https://dev.modern.ie/platform/status/shadowdom](https://dev.modern.ie/platform/status/shadowdom)

~~~
Cshelton
Well, we need the custom elements spec to be figured out too

~~~
rictic
This is true. But custom elements are quite easy to polyfill, especially
compared to shadow dom.

------
thegayngler
I'm extremely excited about this. I have been playing with stock Web
Components for the last year and a half or so. Polymer I have been hot and
cold for. I prefer to learn the standard to start. Overall I am very happy
with this development.

~~~
tdumitrescu
Agreed. While Polymer is a neat project, I honestly think it's kind of hurt
the adoption of web components. I'm sure I'm not the only one who's tried to
learn about web components according to the standards, only to run into a ton
of Polymer stuff on the web and get turned off by the heavy, opinionated,
framework-like nature of it. The underlying web components APIs are much less
off-putting to me, once you can dredge them up through the SEO swamp.

~~~
marknutter
Polymer is really not that opinionated. All they do is provide sugar that you
would eventually write yourself after you get comfortable with web components
and start to notice where the boilerplate lives.

------
pjmlp
One step closer to XAML...

~~~
taf2
or XUL ;)

~~~
elcritch
Finally! ;)

------
pornel
I, for one, am not excited about this.

It's a "oh, that's neat" feature visible only to developers, but it is not
enabling anything groundbreaking for the end users, so it isn't making webapps
more competitive with native. We still need iframes for 3rd party embeddable
components, and for 1st party components we have good enough solutions, and
the tendency seems to be abstracting the DOM away.

Web Components keep taking a lot of spec and implementation effort that could
be spent on something with a bigger impact (ServiceWorkers in iOS?
Transactional DOM that doesn't jank/layout-trash? Activities/Intents/Scopes
for native-like sharing?)

~~~
hugozap
A solid platform gets better gradually, it may not excite you but it's an
important step in the right direction.

Indirectly it does impact the users, because polyfills for browsers that do
not support shadow dom have performance issues, not counting the time
developers spend maintaining them.

------
idibidiart
Without Microsoft adopting this too it remains in a "sort of kind of useful
but not really" status.

Where is Microsoft in this adoption cycle?

And are there any incompatibility across the existing implementations, namely,
Chrome, FF and now Webkit?

~~~
ebidel
MS:
[https://dev.modern.ie/platform/status/shadowdom/](https://dev.modern.ie/platform/status/shadowdom/)
"we intend to begin development soon"

FF:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1205323](https://bugzilla.mozilla.org/show_bug.cgi?id=1205323)

------
michaelwww
"Stop writing frameworks" by Joe Gregorio [OSCON 2015] is a nice intro to html
imports, shadowdom and other aspects of web components, although his knock on
frameworks goes too far for me, especially since some frameworks can use web
components as well.
[https://www.youtube.com/watch?v=GMWAHzXQnNM](https://www.youtube.com/watch?v=GMWAHzXQnNM)

------
sslnx
I have always been skeptical about Shadow DOM. It tries to solve different
problems under one solution.

Say you want a static page without scripts but with CSS encapsulation. You
cannot achieve that. Instead you have to use Shadow DOM and get it in package
with other unneeded things.

CSS encapsulation could be solved with special attribute, new HTML tag or even
with new CSS rule, and it would have been more flexible than Shadow DOM is.

~~~
nostrademons
You're looking for "<style scoped>", which is in Firefox, used to be in
Chrome, but was eventually removed in favor of Shadow DOM.

[http://html5doctor.com/the-scoped-attribute/](http://html5doctor.com/the-
scoped-attribute/)

[http://caniuse.com/#feat=style-scoped](http://caniuse.com/#feat=style-scoped)

[https://groups.google.com/a/chromium.org/forum/#!searchin/bl...](https://groups.google.com/a/chromium.org/forum/#!searchin/blink-
dev/scoped/blink-dev/R1x18ZLS5qQ/Bjuh_cENhlQJ)

I think the main reason webcomponents won out over scoped styles is because
usually once you need to scope your styles, you find you also need to scope
your querySelector calls, and your DOM traversals, and your IDs....and pretty
soon you have shadow DOM. It's unlikely that you need style namespacing if
you're just a single dev working on a static page, and it's unlikely that you
_won 't_ need JS & DOM scoping if your product grows beyond that.

------
avodonosov
Great to see such a progress. I hope within a decade or two HTML will finally
allow us to create convenient reusable building blocks.

------
hugozap
I've working with Polymer and it's been a great experience. This is great news
as it will make polyfills less needed.

------
datashovel
Compose all the things! It's definitely reassuring to see that this is the
attitude of the people who are building the standards for the future of the
web.

------
Someone
Can anybody tell how this relates to
[http://trac.webkit.org/changeset/164131](http://trac.webkit.org/changeset/164131)
(discussed in
[https://news.ycombinator.com/item?id=7243122](https://news.ycombinator.com/item?id=7243122))?

New API, new implementation, or both?

~~~
cletusw
New API and new implementation. [https://lists.webkit.org/pipermail/webkit-
dev/2015-September...](https://lists.webkit.org/pipermail/webkit-
dev/2015-September/027661.html)

------
octref
Really like this as a React dev. Recently there is a trend to use inline CSS
to do CSS modularization in React, but I feel it's not really a clean
approach. With Shadow DOM you can mount the whole React App onto a Shadow root
and have perfect CSS encapsulation. Hopefully we can see Shadow DOM supported
by major vendors' stable channel soon.

~~~
jlongster
Shadow DOM is not the solution for CSS isolation for components. You'd have to
mount every single component into its own shadow DOM which seems unnecessarily
complex (and most likely has significant perf implications).

The answer to CSS scoping is much simpler: CSS Modules
[https://github.com/css-modules/css-modules](https://github.com/css-
modules/css-modules)

~~~
octref
No I wouldn't mount each component into a Shadow DOM. For example if I have a
React App with 2 major parts developed by 2 teams, I would just mount them
onto 2 Shadow DOMs so each team don't need to worry about CSS classes
collisions or whatever else that's on the webpage.

------
hxn
The template element looks very useful. Basic support in old browsers should
be possible by simply setting it to display:none.

~~~
Zikes
There are some key features of template that hiding it would not accomplish,
namely that the contents like scripts are guaranteed not to execute until
they've been cloned/stamped.

Fortunately there are already polyfills for that:
[http://webcomponents.org/](http://webcomponents.org/)

------
Ideabile
What gonna happen to all those engines/framework with Shadow DOM Views
technologies? In short is the end of React?

~~~
bsimpson
React's virtual DOM is an implementation detail - its real power is in how
easy it makes it to write composable components. If Web Components are ever a
faster render target than the DOM, you can trust that ReactDOM will be
upgraded to comply (in the same way that Ember aped React's virtual DOM as
Glimmer).

That said, I have a feeling Web Components add complexity (and weight) to the
render path. I doubt they will be faster than DOM diffing in the near term
(although with any new web tech, there's always the possibility that they'll
make available performance optimizations that can't be supported in the
traditional DOM).

~~~
eob
I agree there will probably be a performance lag for a while, but long-term I
think the WC model wins out because it brings encapsulation and reuse into the
formal suite of W3C specs.

That's not a big deal for any one web app, but a huge deal across web
development in general.

------
elcritch
They're fantastic for a lot of purposes. I've been experimenting with web-
components for a couple of months now. It's not really "prime-time" ready,
IMHO, but it's cool to see how quickly it's progressing now that Mozilla is
more on board [1] and Microsoft's Edge is implementing core features [2a] and
supporting WC's generally [2b]. (PS Vote on the MS's Edge website for
implementing WC features! Seems they actually look at the votes some to
determine features).

One of the biggest hangups for my team has been Firefox/Mozilla opting not to
enable HTML imports (it's implemented) which causes quite a bit of annoyance
when developing and using piece-meal web-components. They list there reasons
[3] but their perspective seems to be driven from a "Javascript" first
mentality with HTML being second class. My code is all driven by web-compoents
though. The difficulty comes from getting the WC polyfills to load before
Firefox tries to load your dom-modules (in Polymer terms). I want to separate
out my HTML into modules and not require loading polyfills _before_ I can
include static HTML pages that might not even have Javascript in them.

There will probably be a lot of resistance, or rather, misuse of web-
components for a while unless web-developers start switching to a "data first"
mentality which is gaining traction from React and ClojureScript. It also
feels pretty very heavy-weight if you're using Polymer currently.

BTW, anyone know how the shadow DOM affects performance of the entire browser
window? Mainly, I'd be curious to know if updates to a shadow-DOM is isolated
from causing Light DOM updates (e.g. updates to the shadow DOM could be
isolated to generally not affect the parent window, or could be batched). This
would yield much of the benefits of React's Virtual DOM. Just not sure where
to look in the Webkit docs to find where this would be documented.

[1]: [https://hacks.mozilla.org/2015/06/the-state-of-web-
component...](https://hacks.mozilla.org/2015/06/the-state-of-web-components/)
[2a]:
[https://dev.modern.ie/platform/status/templateelement/](https://dev.modern.ie/platform/status/templateelement/)
[2b]: [https://blogs.windows.com/msedgedev/2015/07/15/microsoft-
edg...](https://blogs.windows.com/msedgedev/2015/07/15/microsoft-edge-and-web-
components/) [3]: [https://hacks.mozilla.org/2014/12/mozilla-and-web-
components...](https://hacks.mozilla.org/2014/12/mozilla-and-web-components/)

------
meesles
Isn't this React???

 _Shadow DOM, in particular, provides a lightweight encapsulation for DOM
trees by allowing a creation of a parallel tree on an element called a “shadow
tree” that replaces the rendering of the element without modifying the
underlying DOM tree._

~~~
chc
It's similar in some ways, but not exactly the same. This allows an element on
a page to contain a whole tree of elements while still appearing as a single
element from the outside (i.e. for the purposes of DOM methods, CSS, etc.).

------
wampler
So when can we use it?

------
williamle8300
This is a nod to ReactJS

~~~
JeremyBanks
The ShadowDOM spec has been in development since at least a couple of years
before React was announced.

