so, this got way more traction than I expected!
i'd like to reiterate that this is something you should use only in very specific use-cases. there's prob a very good reason why browsers behave this way
also, many of you pointed out that this can be achieved in different ways too, so i'll include a section in the docs about them, along with feedbacks i got and some simple benchmarks:)
browsers mostly skip updating hover state while you scroll
so I made super-hover, a tiny utility library that checks what's under your cursor every frame!
`pnpm add super-hover`
browsers mostly skip updating hover state while you scroll
so I made super-hover, a tiny utility library that checks what's under your cursor every frame!
`pnpm add super-hover`
@andreaskruszaki you mean on terms of performance?
in this particular demo there is none, but on a more complex website/list I’d expect some differences
you can def get to this in a few prompts, but at this point it would make more sense to just point the agent to your codebase and describe on which elements you want to achieve an effect like this.
so i don’t think it makes too much sense to publish a general prompt
but also if you are only worried about installing an npm pkg, you can also point your agent to the codebase on github and say, hey copy this without installing or something
code is super short and doesnt have any runtime deps:)
@sloikodavid i’d say whoever is using this would be responsible to just not use it on reduced-motion enabled. but fair feedback, will include an example about it in the docs, thank you!
1. yeah react-scan can be a good proxy, but it doesn't give a full picture
eg. on a more complex site with more elements, where the browser has to do much more work, I'd expect bigger differences between this and native :hover. I'll try to do some proper benchmarking later to get a more accurate picture tho
2. yeah you're right!
as @asciidiego also pointed out, this can be achieved much more simply (and prob more performant) if you know your elements' positions/heights/layout etc:
https://t.co/j7tPcScTuG
I think this library maybe has a place as a drop-in solution where you don't know, or don't want to manage all of that yourself - eg arbitrary tall elements, unknown layouts, framework rendered lists, etc.
or idk, maybe I'm just trying to justify the work I did for this in hindsight hahah
it is def worse than just using the default `:hover`
so I'd say it depends on your use-case: If it's for some fun creative effects, landing pages / portfolios, for sure, but i'd def avoid it for webapps or anywhere where perf is super super important
will do some benchmarks later to get a more accurate picture tho
https://t.co/rb7OqVOZwX
@codedgar_dev yes, certainly haha
will try to do some benchmarking later to get a more accurate picture how much worse it is tho
https://t.co/cnbxzA6y2U
so why would you use this?
well, you probably shouldn't.
deprioritizing hover updates is most likely done for performance, so browsers can focus on scrolling, painting and any layout work needed as new elements enter the viewport.
which is probably what you want by default!
BUT :)
updating hover every frame opens up some fun interactions, like this super sick section by Locomotive, which first gave me the idea a while ago:
https://t.co/5qx1XQVGuH