Re: [csswg-drafts] [css-ui] select:hover and select:active styles (#11185)

> > E.g. you might want `:focus-within` to keep behaving the same for `querySelector()` for the purposes of DOM queries, but prevent the propagation when using it for styling.
> 
> That's what I was intending with my proposal. It only impacts CSS, not JS. I guess the naming I went with didn't make that clear. I'm sure there's better names out there.

I think the issue isn't just about the name, as soon as you mention CSS selectors directly, people (reasonably) expect the result to be consistent across CSS/JS/DOM (e.g. `.matches()` / `.querySelector()` / hit-testing / etc.), or at least the question will cross their mind. I doubt any name will be clear enough without it being too verbose.

I also don't know how `:has(...)` would behave or how easy / sensical / predictable it would be to just change `:has()` for some APIs but not others.

I'd rather the control to be at "customer facing feature" level than be split at CSS-selector level, such as `user-select: contain` (this already exists fwiw) / `pointer-events: contain` / etc. I think it makes the result a lot more understandable.
 
> > Hence my preference for re-using primitives like `pointer-events`
> 
> The problem is `:active` and `:focus-within` are not limited to pointers, they can happen through keyboard interaction. `pointer-events` is about hit testing, whereas we're talking about propagation of particular pseudo states that aren't limited to pointers.

That's a problem to solve for `pointer-events: none` and friends too right? In the majority of cases, you would not want UI that has `pointer-events: none` to be tabbable/focusable through. If there's a problem with existing primitives, I'd rather have them addressed in some way rather than completely dodged.

This somewhat reminds me of the brand new `interactivity: inert`, there may be some mental model where a new value addresses this use case without needing to introduce yet another CSS property for a similar use-case. cc @flackr @emilio 

> I'm not tied to my proposal either, but my aim was to provide a property that lets you create a CSS propagation boundary for particular pseudo classes. I don't think it should impact JS events.
> 
> Would your proposal impact JS events? I worry that would recreate the issue we see with iframes when it comes to things like drag & drop.

I am personally the type of person who thinks in terms of customer features, so the division between CSS and JS feels somewhat arbitrary to me (to me these are just different tools, not an end result).

It's possible to design specific values like `pointer-events: contain-style`, but I'm really not convinced this is good API design.

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


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

Received on Friday, 10 January 2025 10:18:22 UTC