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

@domenic Thanks for giving this some thought; we really appreciate it.

Let me offer some more use cases where someone will want to expose multiple sub-elements as parts, and where those parts will often have state that people will want to reflect in styles.


## Components with generated elements

The carousels @kevinpschaaf mentions above are a common example of a category of components that want to generate subelements. Our stock [Carousel](https://component.kitchen/elix/Carousel) does this, and we have others that generate page numbers, thumbnails, or labels drawn from image captions.

Other examples:

* Calendar components. Our [MonthCalendar](https://component.kitchen/elix/Carousel) generates an element for each day of the month. Each of those days can have state: in our stock calendar, weekend days are represented specially, as is the current date. We also have an interactive calendar that adds a selection state for dates. Other calendar components include things like Google Photo’s timeline scroll bar.
* Charts and other data visualizations. Charts have tons of generated elements: tick marks, labels, legends, points, bars, etc.
* Maps.
* Live data components: most recent Tweet, stock tickers, etc.

In these types of components, it’s simply not possible to ask the component user to generate the elements themselves and place them in the light DOM. The generation of that content is much of the component’s value.

A component could try to generate its own light DOM content, but that gets messy, no?
* It would interfere with the real content the user is interested in having the component render.
* It would also raise the likelihood of the kinds of unintentional CSS collisions Shadow DOM was designed to prevent.
* It hinders composition. If I embed a chart component inside one of my own components, there’s no easy way for me to expose the chart’s generated light DOM content (which is now inside my component’s shadow) outside my own component. In contrast, we’re hoping `::theme` will eventually address that cleanly.


## Components with stock content

Another category of components with parts with multiple instances are components that provide stock content such as tools.

As a simple case of such stock content, the carousel above has left and right arrow buttons. An author will want to style the general appearance of those buttons, along with :hover and :disabled states. Although there are just two of these buttons, conceptually it’d be nice to define such styling once, rather than having to style `::left-arrow-button` and `::right-arrow-button` parts separately. We have other examples, such as a [SlideshowWithPlayControls](https://component.kitchen/elix/SlideshowWithPlayControls), that have more commands.

As the number of commands increases, the burden of having to style each button as its own independent part increases. A rich text editor or image editor component which offer the user a toolbar with a number of buttons for editing commands. Those buttons are stock content — elements built into the editor. The creator of the editor component wants to let someone style those buttons as a collection, instead of having to style each command separately. The buttons have state: disabled, checked, etc. It should not be necessary to expose those commands in the light DOM to make them available for styling.

A component that wants to provide elements for the author — generated elements like those dots, or stock elements like those editing commands — is going to want to let the page author style those elements. In both cases, it’s cumbersome to try to do that through light DOM elements.


As soon as we ask the component user to put something in the light DOM that could in any way be inferred or generated from their real data/content, some clever person will create a script to automate the creation of those light DOM elements. They’ll share that script with their team as a more helpful wrapper for the actual component. Different team members will create different wrapper scripts for different components; the wrappers will behave slightly differently. If that happens, it would mitigate many of the advantages of having introduced a component model.

I don’t think we’re trying to give the user complete fine-grained control over the subelements. The user can’t modify those subelements directly, they can’t listen to events on them, etc. The interest is specifically on styling. I share your concerns about increasing complexity, but think focusing on the styling problem prevents full-blown replication of a duplicate light DOM.


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

Received on Friday, 11 January 2019 16:51:29 UTC