- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Sat, 02 Feb 2019 21:47:39 +0000
- To: public-css-archive@w3.org
> The native pseudoclasses would be redefined as shorthands for the `:state()` selector. One potential problem with this is that custom elements already match certain state-like pseudoclasses. The author-defined states would need to cascade on to the default ones. For a generic custom element (`<my-widget>`), the default states would be something like ```css @state { hover: :root:hover; active: :root:active; focus-within: :root:focus-within; } ``` If an author provided a new definition of the `active` state (something beyond "is the user holding down their mouse somewhere in this box tree?"), it would replace the `my-widget:active` pseudoclass, but the `my-widget:hover` pseudoclass would work as normal. For custom elements that upgrade native elements with the `is` attribute, the set of native states would be longer. But the benefits of being able to override them would be greater. The native pseudoclass could apply as the graceful degradation state if the custom element definition never loads. For example, consider an enhanced version of `<input type="tel"/>` that breaks it into a fieldset with multiple parts (area code drop-down, telephone, extension). You could define `valid` and `invalid` states, and so on, using selectors that check that all parts of the fieldset are valid in order for the input as a whole to be valid. But the basic browser behavior for `:valid` would apply if the element never got upgraded. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3431#issuecomment-460001869 using your GitHub account
Received on Saturday, 2 February 2019 21:47:41 UTC