Re: [csswg-drafts] [css-shadow-parts-1] Can class name selectors apply to a part? (#3431)

@JanMiksovsky thank you for your detailed post at https://github.com/w3c/csswg-drafts/issues/3431#issuecomment-446808478 , and apologies for taking a while to process it. I think I'm not fully understanding something though, which is why in your component libraries there are so many parts-with-states.

If you look at built-in HTML elements with UA shadow DOM (or other complex internals) today, they all use shadow DOM for encapsulation. The encapsulation is complete enough that the parts themselves don't really have any state; instead that gets bubbled up to the host element. Any case where there's a complicated-enough sub-element that has its own potential states ends up being done through light DOM, not shadow DOM.

So for example, you have a my-tabs-component, but from what I can gather in the OP, you have put all interesting sub-parts _inside the shadow DOM_. This means you have to re-expose them as `::part`s, and thus leads you to getting into trouble with sub-states and so on.

But this isn't how we would design a built-in element. There, the interesting sub-parts would be in the light DOM, e.g. something like

```html
<tabs>
  <tab>
    <tab-button>One</tab-button>
    Page One
  </tab>
  <tab>
    <tab-button>Two</tab-button>
    Page Two
  </tab>
  <tab>
    <tab-button>Three</tab-button>
    Page Three
  </tab>
</tabs>
```

Indeed, I see you even have an example of that later down, with "Custom content in default tab buttons"!

In other words, parts make sense for things that are internal parts of your main component, like `::backdrop`, `::cue`, `::placeholder`, `::marker`, `::-webkit-slider-thumb`, etc. In those cases, the state reflects up to the main element (e.g. `input:placeholder-shown`, or a fictional `dialog:backdrop-shown` or similar). But if you have something like a tab button, which is its own first-class object with its own states, then those things should probably be in the light DOM, not hidden inside the shadow DOM. And if they're in the light DOM, they don't need to indirect through parts in this way.

In general one rule of thumb I might come up with is that any time there can be an arbitrary number of the sub-control, it's probably first-class enough to need light DOM exposure. If the sub-control is 1:1 with the main custom element, then maybe it's just a part.

With this framing in mind, do you have any other examples from your 26+21+6 components where it's a more clear-cut case of the sub-part having its own state, that run into the issue described in the OP? Because the specific OP issue doesn't make sense to me anymore now that I look at this in more detail. Especially seeing how you explicitly encourage users in your docs to have light DOM `elixir-tab-button` elements which could just be addressed with normal CSS selectors and not need `::part` to select them.

-- 
GitHub Notification of comment by domenic
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3431#issuecomment-453130662 using your GitHub account

Received on Thursday, 10 January 2019 15:15:09 UTC