Re: [whatwg/dom] Declarative Shadow DOM (#510)

I really regret I come that late to this discussion.

At Starcounter, we are using some form of declarative Shadow DOM on production for more than a year and a half, now.
So far, to make it work, it requires a [specific custom element](https://github.com/Starcounter/starcounter-include) as a host - that also does client-side include.
I'm currently working on writing an independent [`<template is="declarative-shadow-dom">`](https://github.com/tomalec/declarative-shadow-dom) CE, which could be closer to a real prolyfill.

Starcounter is an application platform, so there are even more devs actually using that feature. So far I received only positive feedback, mostly for:
 - extremely easy way to separate layout from content,
 - well.. declarative, JS-free way to use Shadow DOM,
 - an unobtrusive way to style 3rd party content - [article](https://starcounter.io/unobtrusive-styling-composing-3rd-party-html-content/ )
(By _style_ and _layout_ I mean a full composition of HTML+CSS features, not just CSS)

That also plays nice with a server- or client-side includes, as you can share the same set of functional elements, but attach different HTML+CSS composition to each instance.

-----


@treshugart, @bedeoverend 
 Speaking of SEO problems for Declarative Shadow DOM, I don't think it's a big problem.
 Until robots will completely adapt to the new spec, DSD could still be useful just for encapsulated, scoped styling.
 So far, putting an actual content to the (imperative) Shadow DOM leads to the problems anyways - a11y and label-form coupling for example. That's why I'd not consider it as a blocking issue for _Declarative_ Shadow DOM.
 I believe, the fact that some external party cannot access the thing we wanted to encapsulate in first place into Shadow DOM, is closer to a "feature" rather than a "showstopper"

----

Speaking of `<template shadow>` vs. `<shadowroot>`, I don't have a really strong opinion. 
I'd just like to mention that `shadowroot` nicely correlates to the way dev tools currently shows already attached shadow roots, it's also the syntax used in some articles, tutorials, and examples over the Web, so I believe it would be intuitive and self-explanatory for the developers.

Even though, technically and implementation-wise they could be pretty similar, having a separate name would let them evolve in different directions if needed. Having a single tag with different attributes that changes its behavior completely reminds me `<input type="*">`.

----

> I would prefer to remove a `<shadowroot>` element from the light tree after parsing and attaching it as a shadow tree, to save memory.

I'd like to upvote this and [behavior speced](https://github.com/whatwg/dom/issues/510#issuecomment-331323635) by @hayatoito giving the developer perspective.

If it would remain there, one (at least me) would try to modify it to actually change the `.shadowRoot`, and having a yet another way to **imperatively** change `shadowRoot`, through a ... **declarative** shadow dom would be extremely confusing and messy. 

Also, polluting `.children` would be problematic for custom elements that act as decorators, or relies on the number of actual children.


---- 

I cannot express how happy I am seeing the progress of this issue. This is the thing I wanted to use since I started to use Web Components ~2013.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/510#issuecomment-338820389