- From: Sean May via GitHub <noreply@w3.org>
- Date: Sat, 19 Jul 2025 04:19:39 +0000
- To: public-css-archive@w3.org
@knowler Thank you for the example. ```html <style> /* CE consumer forces the state of a custom element (potentially breaking it beyond just styling) */ @state open { matches: my-element; } </style> ``` I understand more of where you are coming from, now, but on rereading, I do not think the comment in the referenced block would be true. I think that it might be possible for the consumer of the element to show it in an open state, via CSS, if a `my-element::open` selector in a style tag is wholly sufficient to display your content, from userland. However, I don't see where the proposal states that the CSS selectors, used in the CSS files (or style tags), would be reflected back into the HTML or JS. The closest I can find to that reading is this: > States added via @state combine with ElementInternals.states (and the proposed Element.states) > The resulting states are a union. This means, if a component removes a state via JS but the same state is in effect through an @state rule, it still applies. However, my interpretation of that is: "For the purpose of styling elements, within the styling rules, if the CSS-declared selectors still apply, despite the JS selectors being removed ..." rather than a reading of "For the purpose of DOM node state, and JS reflection of DOM node state, if the CSS ......." Again, I could be wrong. I think we are both making assumptions in two different directions, relating to missing context, in this area of the proposal. Note that I am not suggesting that this is your argument, at all, but for cases of "that selector, with a `display: block` on the host element, will break my component", it does mention that it would be tree-scoped, but could be extended later. And to that, I might say that having `doesMyComputedStyleContainDisplayBlock(root)` as a programmatic JS state, might be detrimental, in general. And also, if `my-element::open { display: block; }` is enough to mess with the component, just by virtue of the computed style (and not JS reflection, except through checking the computed style), then the end user could equally mess with the component with an `!important` or with any specificity greater than `(0,0,1)`. -- GitHub Notification of comment by seanmay Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12502#issuecomment-3091515815 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 19 July 2025 04:19:39 UTC