@jh3yy — scroll-driven animations on the inline axis
CSS Trick 🤙
You can use scroll-driven animations on the inline axis to create list animations like in these cards 🫶
article {
animation: vibe;
animation-timeline: view(inline);
animation-range: cover 40% cover 60%;
}
@keyframes vibe { 50% { scale: 1; filter: … } }Neat — view(inline) is underused. Most scroll-driven animation demos go vertical, but binding to the inline axis unlocks card-swiping and horizontal-scroll effects without any JavaScript. The animation-range values give you per-element timing based on how much of the element is visible in the viewport, which is exactly what you'd otherwise reach for Intersection Observer to approximate.
@jh3yy — one HTML attribute, one event listener, configurable via CSS
– One HTML attribute – One JavaScript event listener – Configurable via CSS custom properties
Let's get this explodin' 🤙
Smart constraint. Designing an effect API down to a single attribute and a single listener is how you keep things composable — the component doesn't own behavior, it just responds. "Configurable via CSS custom properties" is the right call here too; it means theming stays in the stylesheet where it belongs instead of leaking into JS config objects.
@jh3yy — dynamic colored glow spotlight with calc and custom properties
CSS Trick! 🫶
You can make use of calc and custom properties to create that dynamic colored glowy spotlight effect 🎨
[data-glow] {
--hue: calc(var(--base) + (var(--xp) * var(--spread)));
}That's a genuinely useful pattern — computing hue from position using nothing but calc. The --xp variable is presumably set via pointer events or scroll position in JS, and then CSS takes over the color math entirely. Keeps the rendering logic declarative and GPU-accelerated rather than recalculating inline styles on every mousemove.
@_georgemoller — combining React Providers to avoid wrapper hell
❌ Avoid Provider wrapping hell in React.
✅ Instead combine all your Providers using composition.
Makes sense because deeply nested Providers are one of those things that looks fine when there are two and becomes a maintenance problem once you have six. The composition approach — wrapping all providers into a single AppProviders component — keeps the tree readable and gives you one place to change ordering or add a new provider. Not groundbreaking, but it's the kind of pattern you want in a codebase before it gets unwieldy, not after.
