- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Jan 2025 12:58:39 +0000
- To: public-css-archive@w3.org
> > 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. I think you'd struggle to make `pointer-events` about something more than pointers in a backwards compatible way. Also, if you do that, the feature becomes a real mess. For staters, the naming really sucks - the word 'pointer' is right there. > the division between CSS and JS feels somewhat arbitrary to me It is, absolutely. But as things currently stand, you can't impact `:hover` by preventing/stopping JS events. I think you'd be giving developers a lot of pain if you decide that this particular feature _does_ impact JS, when similar features do not. That's why my instinct was to create CSS containment of particular CSS features. > I also don't know how `:has(...)` would behave I think that's pretty straight forward. `el:has(:hover)` would match if any descendant matches `:hover`. The containment would only prevent `:hover` applying directly to elements outside the containment. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11185#issuecomment-2582654612 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 12:58:40 UTC