The CSS Working Group has a proposal on the table for a CSS :near pseudo-class, and it is one of those features that makes you wonder why we are still faking this in JavaScript. Anyone who has tried to trigger a UI change before the user actually touches an element knows the drill: you calculate Euclidean distances inside a pointermove listener and hope it never becomes the bottleneck.
Thomas Walichiewicz proposed the selector so an element can match while a pointer sits within a given range. The syntax would read something like button:near(3rem). Styles fire once the user is close enough to look interested but has not committed to a hover or a click.
What the current proximity logic costs
Right now, a request for a magnetic button or a menu that opens as the cursor approaches means JavaScript. You read the mouse position and run the math every frame, and if you are careless about it you get layout thrashing. The boilerplate looks like this.
// The expensive way to detect proximity
document.addEventListener('pointermove', (e) => {
const rect = element.getBoundingClientRect();
const x = e.clientX - (rect.left + rect.width / 2);
const y = e.clientY - (rect.top + rect.height / 2);
const distance = Math.sqrt(x * x + y * y);
if (distance < 100) {
element.classList.add('is-near');
}
});That approach is fragile. It ignores the browser’s paint cycle unless you wrap it in requestAnimationFrame, and accessibility ends up an afterthought. If cutting JS overhead is the goal, there is also how to stop JS scroll bloat with CSS sibling-index().
Where the CSS :near pseudo-class would help
The clearest win for the CSS :near pseudo-class is cutting visual clutter. Picture a dense dashboard where every button carries an icon. Fifty icons on screen at once is noise. With :near() those icons could fade in only once the user’s intent is readable, which reads better than :hover, since hover only fires at the last millisecond.
Then there is the invisible hit area. We have all padded a button with a slab of transparent space to make it easier to click, and we have all watched that padding wreck the layout around it. The proposed selector lets the button keep its real dimensions while its interactive gravity reaches past them.
Hiding elements until they are needed
Hiding an element until someone is nearby is easy on the eye, but it usually breaks find-in-page (Cmd+F). Pairing hidden="until-found" with content-visibility gets around that, and adding contain-intrinsic-size reserves the space before the element renders.
/* Proposed native approach */
button {
content-visibility: hidden;
contain-intrinsic-size: auto 40px; /* Reserve height */
}
button:near(3rem) {
content-visibility: visible;
opacity: 1;
}The browser then knows the element is there and holds its space, without spending paint time on it until the pointer gets close. On related ground, I have a guide on implementing CSS contrast color approximation.
The fingerprinting problem
Having sat through a few security audits, I keep coming back to privacy. A selector like :near() could be turned into a heatmap of the viewport without anyone agreeing to it. Nest enough :near() ranges and a script can follow the cursor through CSS transitions alone. That is presumably why the W3C proposal spends so much time on how to block that kind of abuse.
If this kind of thing is eating your dev hours, I can take it over. I have been wrestling with WordPress since the 4.x days.
Waiting on browser support
Moving proximity logic out of JavaScript and into the browser engine is a performance win, and it sits alongside Interest Invokers, the browser APIs built to handle hover and focus intent with less code. Until vendors ship it, the padding-container hack is still the workaround. Keep that logic in one place so it is easy to delete later.
