- From: Thomas Walichiewicz via GitHub <noreply@w3.org>
- Date: Sat, 14 Mar 2026 21:52:21 +0000
- To: public-css-archive@w3.org
Hey @bramus, thanks for the response.
I think your suggestion serves a different purpose than what `:near` would be intended for:
1. **Function vs Visual:** Expanding the hit area changes where the user can click, but `:near` would change what the user sees before they get there. If, for example, we were to expand the hit area by 100px to reveal a toolbar on approach, we are also making that empty 100px space clickable. If the user accidentally clicks 50px away from the actual button, it would trigger the button's action.
- **Hit-area expansion** is perfect for accessibility (e.g. making a 16x16 button compliant with WCAG target sizes)
- `:near` is for discoverability (e.g. gently fading in a "Drag to reorder" handle when the mouse gets within 50px, without making the empty space itself draggable.
2. **Media Queries:** You mentioned that a property allows for conditional application; fortunately, pseudo-classes are fully compatible with media queries too. We can easily scope `:near()` to devices with fine pointers where approach states make the most sense:
```
@media (pointer: fine) {
.handle:near(40px) {
opacity: 1;
transform: translateX(0);
}
}
```
I completely agree that CSS needs a native way to adjust hit areas (`hit-margin`) but I see that as a complementary tool for accessibility rather than a replacement for proximity-based styling.
--
GitHub Notification of comment by twalichiewicz
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13271#issuecomment-4061486170 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 14 March 2026 21:52:22 UTC