*Contact emails* [email protected] *Specification* https://www.w3.org/TR/selectors-4/#useraction-pseudos
*Summary* This feature represents the behavior described in this section of the CSS spec: https://www.w3.org/TR/selectors-4/#useraction-pseudos which says that :hover, :active, and :focus-within match on the parents of elements, but only up to the first top layer element in the parent chain. The change for Chromium is that last "up to the top layer" part of this behavior. Concretely, this means that for this structure: ``` <main> <div popover> <button></button> </div> </main> <script>document.querySelector('[popover]').showPopover();</script> ``` if the user hovers the `<button>`, then the `:hover` pseudo class will match the `<button>`, and the popover, but will not match the `<main>` element. The rationale behind this change is that typically top layer elements are rendered "elsewhere", in a location that is disconnected from the parent element visually. So it typically does not make sense to change the styles of the parent element when the top layer element is hovered or activated, for example. The customizable-<select> implementation shipped in Chromium has this logic hard-coded for the specific case of the select `::picker()` popover. That special case logic will be removed when this feature ships. *Blink component* Blink>CSS <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> *Web Feature ID* user-action-pseudos <https://webstatus.dev/features/user-action-pseudos> *Search tags* top layer <https://chromestatus.com/features#tags:top%20layer>, popover <https://chromestatus.com/features#tags:popover> *Risks* *Interoperability and Compatibility* While this is a behavioral change, in that the user action pseudos will no longer match across top layer boundaries, it is very unlikely to cause compat issues, because the old behavior was so broken. It is unlikely that a site is relying on that behavior intentionally. While it's possible they unintentionally did so, but in that case, this feature will effectively be a bug fix for those sites. *Gecko*: No signal *WebKit*: No signal *Web developers*: No signals *Other signals*: *WebView application risks* Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? *No information provided* *Debuggability* *No information provided* *Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* No *Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* No *Tracking bug* https://crbug.com/407769114 *Estimated milestones* Shipping on desktop 149 DevTrial on desktop 148 Shipping on Android 149 DevTrial on Android 148 Shipping on WebView 149 *Link to entry on the Chrome Platform Status* https://chromestatus.com/feature/6296574159355904 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDh1YzT0wa9stdi5D5Q9%3DvT-5cqD%3Dcz9Wsiq%3D%3DjmYG_Now%40mail.gmail.com.
