Re: [WICG/webcomponents] "open-stylable" Shadow Roots (#909)

@mirisuzanne:

> Still, I agree that layers do seem essential to the solution here. We're concerned with both which styles apply, and also how they cascade. So we absolutely want ways to put sheets or scopes (or whatever) into layers. That would be similar to the way we can import entire CSS files into layers. And it would be useful for component authors to expose layers, for more nuanced cascading between page and shadow-dom.
> 
> We should be able to combine these features, but we should not conflate these features.

(Github Issues sadly don't have a reply-to-comment button, I am talking about your [whole comment](https://github.com/WICG/webcomponents/issues/909#issuecomment-2011014948), in this thread ([original comment](https://github.com/WICG/webcomponents/issues/909#issuecomment-1971878378), [shadow layer proposal](https://github.com/WICG/webcomponents/issues/909#issuecomment-1993388146), [layers access @scope](https://github.com/WICG/webcomponents/issues/909#issuecomment-1995046971), [syntax](https://github.com/WICG/webcomponents/issues/909#issuecomment-1998305361))

I share your optimism that combining without conflating is possible.

The shadow layer proposal is in two parts:  declarative shadow DOM, and syntax(s?) to access page styles (the ones that are already on the page outside the shadow tree, not ones that can be pulled in through a link or import tag which already work in shadow trees).

Declarative shadow DOM solves an even more fundamental "mistake" than you reference. The declarative subtree problem in markup languages predates even HTML itself.  Perhaps the old object tag debacle delayed an HTML solution by a decade, but the problem was so long and so well known when modern shadow DOM was introduced in 2011 that providing a Javascript-only shadow tree to me was just a huge mistake.

But that is behind. Anyone using or authoring a web component (or designing a shadow tree) now can use declarative shadow DOM.  So to me of course any proposal now would use it to "pull" in page styles. And any syntax would therefore of necessity be declarative and work from inside, not outside, the shadow tree.

To write a POC, I had to pick only declarative syntaxes that are polyfillable and spec-defensible. I even explored how to synchronize multiple different syntaxes. 

I am a little surprised one of those syntaxes is so intuitive that it is even used to point out [what you can't do](https://github.com/WICG/webcomponents/issues/909#issuecomment-2012215949) with @layer today anywhere else on a page.

So please, any syntax is fine by me, but I do think a polyfillable syntax would be much preferable overall.

All syntaxes, even on [a style tag](https://github.com/WICG/webcomponents/issues/909#issuecomment-1952054895), like all solutions will have tradeoffs, to me it is a question of picking the best tradeoffs overall.

Yes, to me a solution would be similar to the way we can import entire CSS files into layers and into shadow trees now -- I was doing that into declarative shadow trees, but got annoyed reimporting resets.css files and relinking components.css files.

And since to me @scope inside a shadow tree is a good thing, @scope inside a shadow tree could also fix shortcomings in ::slotted (the bottom side of encapsulation).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/909#issuecomment-2015662403
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/909/2015662403@github.com>