W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2018

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

From: fergald via GitHub <sysbot+gh@w3.org>
Date: Thu, 13 Dec 2018 03:53:40 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-446833990-1544673219-sysbot+gh@w3.org>
Thanks for all that info. The `part-attributes` stuff makes more sense as you've clarified it. I have some concerns about it exposing more implementation details than is desirable, e.g. if I write a component and it contains some sub-component and I export some of that sub-components parts, then I have no control over the exported attribute names and values, they may be inconsistent with the names and values I use in the parent component and if I swap out that sub-component for an entirely different implementation, they may have an entirely different set of names of values. So there would be no way to ensure a stable API given different implementations (whereas part renaming does give us that even when exposing parts that are not controlled by the parent component's author).

All that said, perfect is the enemy of good. The value of being able to do this at all seems high and it also seems unlikely that we would ever go as far as adding something to allow transforming attribute names and values to allow a stable API to be presented in cases like these.

> The problem is that a `MenuButton` knows what values of `horizontalAlign` are valid. A component using a `MenuButton` instance in its shadow does not — but it's that outer component that will need to stick a `part` like `horizontal-align-left` on the `MenuButton` instance. That means the outer component needs to track the current value of the menu button's `horizontalAlign` property ("left", etc.), munge it to some part variation (`horizontal-align-left`, etc.), and manage that on the part. That's non-trivial JS that needs to be written for any parts with styling that might depend on component or part state. It could be made to work, but will be cumbersome.

I'm not sure I follow this example. The containing component would not put a `part=` on the `MenuButton`, it would put `exportparts=`. E.g.

```
<style>.bar::part(button-foo) { ... }</style>
<custom-elem class="bar">
  # shadow
  <menu-button exportparts="foo: button-foo">
  # shadow
    <div part="foo">...</div>
  </menu-button>
</custom-elem>
```

If we added wildcard exports then this would change to be
```
...
  <menu-button exportparts="foo: button-foo attr-*">
...
```
only the inner component would have to worry about tracking state and munging things to look like `part="foo attr-horizontal-align=left"`.

It's still hacky. I think `part-attributes=` makes a lot of sense but I'm also interested in how far we can get without it, since we still haven't got the basic `part=` and `exportparts=` enabled in any browser yet, so adding this seems a long way off.

-- 
GitHub Notification of comment by fergald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3431#issuecomment-446833990 using your GitHub account
Received on Thursday, 13 December 2018 03:53:42 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:41 UTC