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

@matthewp

> An attribute on the `<template>`, to me doesn't qualify as "page doesn't have to opt-in". They do have to opt-in, either by adding that attribute themselves or using a library or some other tooling to do it for them. Maybe you don't consider that to be the page opting in. And that's ok! I'm curious if others who value encapsulation feel the same way.
> 
> If adding an attribute doesn't count as "page opting in" then why do the other solutions? A library or tool can add a style tag with some CSS too. I think all of the proposed solutions fit the requirement if libraries are allowed.

I think it's important to consider *where* the attribute is and who is in charge of setting it. The `<template>` element would normally be rendered by the component itself, via some sort of server-side rendering mechanism. This is different than the global CSS having to consider the component.

The point here is for a component author to provide a component that, without any further changes from the user, can be dropped into a website and adopt the website's styling. So an opt-in from within the component is perfectly in line with the goals of this proposal, while an opt-in by the website author is not.

The `<template>` is really just a special case of `attachShadow`, where the component provides some server-side code to pre-render the contents of its shadow-DOM, but in these cases the attribute on the `<template>` is still under the control of the component author.

-----

Some more thoughts on this topic as an occasional component-author:

Pulling in *all* styles as a default seems essential to this feature. For a component that really "just works" there can be no requirements to separate styles out on the website into what should be used by a component and what shouldn't.

Likewise, having the option of writing my components to be configurable, meaning users could instruct my component on which of their styles should be used (for example via layers) would also be a very valuable feature to me.

One question that presents itself after considering that previous thought is that **changing** which styles get used in the shadow dom might be essential in avoiding life-cycle headaches. I think it is a *reasonable* expectation for a component to have figured out what styles to pull by the time it attaches its shadow-dom, but my ideal API for a component would allow for something like this:

```js
import "CoolComponent.js"

component = document.createElement("cool-component")
component.styleScope = "base" // I, the website author, put my global styles in this layer

someOuterElement.append(component)
```

What this means is that, if `CoolComponent` wants to attach its shadow-dom in the constructor, it won't yet know that the user wants to only pull in the "base" layer, so it would have to be able to change this later on.

As I mentioned, this isn't strictly necessary, as the component could attach its shadow dom in the `connectedCallback`, and the user would have to take care to set the attribute before the first time the component gets inserted into the document, but that's just clutter to the mental model of what happens, and yet another foot-note in the documentation making the component more unwieldy.

I still think a dedicated element inside the shadow tree would be the best interface from a user's perspective, as that would easily allow making this change even after the shadow-dom has been attached to the component, whereas a new `mode` value would make it very difficult to design an API that isn't confusing.

-----

@mirisuzanne I don't think layers would be a bad mechanism to select styles to be pulled into a shadow-dom. Conceptually, they seem like the right way of handling this. Whether or not this will incentivise users to start using layers as a more granular API to style components seems like a different question that should better be addressed by providing a *separate* way of doing these more granular styling tasks.

Ideally, layers would be a way of broadly narrowing down what styles to pull into a component, and some other mechanism (I like the idea of extending `@scope` for this) would allow website authors to be more granular about styling the inside of a component.

Put differently: This issue is about components **pulling** styles in, with layers only serving as a way of optionally narrowing down the affected styles; there is a separate need for a mechanism to **push** styles into a component that this feature could be misused for.

Am I understanding the criticism of the layers-based approach correctly, or am I missing the point?

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

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