"A problem that can show up when you create a nice transform and transition is because most of that time-based effect on :hover is glitchy and jolty for users if their pointer escapes out of the bounds of your element. See it for yourself. This is the CSS that creates that effect for us. We have a --transform-size custom property and by multiplying that by -1 - using calc() - it becomes a negative value, shifting our card element upwards."
"The selector .card:hover targets the specific .card element when it is being actively hovered, so as the pointer leaves .card, it starts to snap back to its default state, causing a glitchy loop. A quick way around a fix Let's first take a look at our CSS for the card element. We've set some tokens with custom properties that because they're at the :root, they will be available to all of our CSS. Then we use those to set some consistent padding, spacing and radius."
Transform-based hover effects can become glitchy when the pointer escapes an element's bounds, producing jolty transitions. Using a negative --transform-size via calc() shifts card elements upward and a linear transition timing function smooths the motion. Applying :hover directly on .card causes the element to snap back as the pointer leaves, creating a looping glitch. An attempted fix added padding to the parent <li>, but that introduced horizontal alignment issues and required negative margins that felt like a hack. Colour custom properties and spacing tokens are defined at :root for consistent sizing. The .card contains child elements like <img>, so hovering those children still triggers .card:hover.
Read at Piccalilli
Unable to calculate read time
Collection
[
|
...
]