Re: [csswg-drafts] "Single content, multiple renderings" feature for `<selectlist>` (#9284)

So I think that, in general, "one content, multiple renderings" is acceptable mechanically. Whatever layout-tree abstraction a browser uses can, at least in theory, handle a many-to-one relationship with the dom tree. The main issue is that some relevant state for rendering might be stashed on the element rather than the layout node, but that's presumably fixable. (And as flackr points out, fragmentation already, to some extent, exposes these issues.)

The big question is about targeting your styling, tho. The current "just clone it" behavior makes this easy - any styles you write to target the option sub-elements will target the copy as well, so long as you're not *too* specific with context in the selector. So, how do we target the stuff when it's *not* cloned?

I think there are two options:

1. Make a pseudo-element, and allow it to have full structure after it, like `::selected-option > img {...}`. This is straightforward and I think fairly clear. It's unprecedented so far, but we purposely allowed for this [in the selector grammar](https://drafts.csswg.org/selectors/#typedef-complex-selector). The main problem is that these elements would *not* be targeted by the styles targeting the actual option. You'd have to explicitly target things. Nesting can help here, tho: `option, ::selected-option > option { img { ... }}`.

2. Just make the elements pretend to live under the `selectedoption` element for Selector purposes, without actually cloning them. Which "face" of the element gets selected determines the styles it gets for the corresponding render-tree copy. This is also unprecedented, but we do have *some* things slightly like this, notably the host element in a shadow DOM, which is not *in* the shadow tree but is *targetable* from the shadow tree, and pretends to be the parent of the elements in the shadow tree (you can write `:host > .foo` to target `.foo` elements at the top-level of the shadow tree).

    This gives us essentially the same usability as the current `cloneNode()` experiment, but keeps the liveness of the nodes in both locations. (It's similar to the pseudo-class approach that Mason lists in the OP.)

Do we want to support being able to style differently based on *which* node was selected? That is, if the first option is selected it's styled as X, but if the second option is selected it's styled as Y. I presume this is necessary, since the options can have different markup. In that case, we would need to have a way to go from option -> selectedoption. 

In my (1) above that's easy if we make the `option` the originating element of the pseudo-element; you can write `option.foo::selectedoption > img`. 

In (2) we'd need to do something else; maybe we'd allow the direct "pretend to be descendants of `selectedoption` element" behavior so it can be targeted generically, but *also* allow the pseudo-element to let you do per-option styling. Or we can put a pseudo-class on `selectedoption`, like `selectedoption:option(.foo) > img`; we'd check if the corresponding `option` element matches the provided selector.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 14 September 2023 14:27:55 UTC