Adam Argyle

Adam Argyle

@nerdy.dev.web.brid.gy

CSS DevRel @Google on Chrome, @CSSWG, co-host @CSS Podcast, co-host Bad @ CSS, host @GUI Challenges. Web design & development tips & tricks: CSS, JS, HTML, Design, & UX.

200 followers0 following336 posts

Adam Argyle
@nerdy.dev.web.brid.gy
nerdy.devScroll Axis LockI first noticed web scroll areas had scroll locking behavior when making 2D scroll snap demos; I couldn't scroll diagonally without getting hijacked and locked into an `x` or `y` axis. Even on a touch device, where a diagonal gesture is so easy and natural. See the Pen by Adam Argyle (@argyleink) on CodePen. Thanks to Bramus's rad interactive blog post I saw **Chrome 153** with the remedy: .scroller { overflow: auto; overscroll-behavior: contain; scroll-axis-lock: none; 👈 } spec | check for support **Freedom from the axis lock** 🤘🏻 ## Use cases # I was thinking: 1. swipe to dismiss interactions 2. flings 3. maps or infinite canvas navigating 4. datagrids or tables 5. image zoom scrolling around 6. 360 pano images or 3D model panning 7. data vis exploration Just seems worth while to use the natural inertia, tensions, perf and feels that scroll snap has for the snap feedback of "didnt swipe far enough" and the browser owned easing. Can also mitigate `scrollTo` strangeness that might do `x` then `y`. ## I did log a bug # I saw some performance regressions in the first 2 demo's I pulled up to test with 1. swipe prototype 2. snap matrix Filed a bug. I wouldn't necessarily file this as perfectly fixed, I still felt it was a bit clumsy or not enabling diagonal scrolling as smoothly as I'd like. **Overall exciting and meaningful IMO tho.** Your thoughts?
Adam Argyle
@nerdy.dev.web.brid.gy
nerdy.devCSS Infinity Use CasesCSS `infinity` (and `-infinity`!) solve some pretty specific problems elegantly, but can also just be plain fun to use. Showing support for `infinity`, `-infinity`, `NaN`, `pi`, and `e` Lets spur creative CSS juices with `infinity` and follow a couple use cases. ## Basics and gotchas # `infinity` and `-infinity` need to always be wrapped in `calc()`. If you want it to represent a dimension, it also needs to be multiplied by a unit like: div { border-radius: calc(infinity * 1px); z-index: calc(infinity); } Not quite limited to `calc()` too, you can use it with other `calc()`-like scenarios like `clamp()`, `min()`, `max()`, etc, which we'll dig into a bit 🤘🏻 ## 1. Circles and Pills # Before `infinity`, I would have used scientific notation like `1e9px` (which is `1000000000px`) to create a "big enough" radius for circles and pills at any size. But with `infinity`..!? .radius-full { border-radius: calc(infinity * 1px); } ## 2. Perma-state # Setting duration `calc(infinity * 1s)` makes an animation/transition so long that it appears to be frozen ⛄️ Hover over those boxes and the duration will be pinned to happen over infinity seconds, sticking the state for the duration of the page's life. I like how the duration of your hover is permanently made visible too. Visible millisecond duration via background color. ## 3. z-index # Need to beat `z-index: 999999999` or something? .tippy-top-of-stacking-context { z-index: calc(infinity) } This will max out at the largest int a browser allows: `2147483647`. Speaking of that number, you can see it by using counters like this: .css-max-int { counter-reset: cssInt calc(infinity); &::after { content: counter(cssInt); } } See! ## 4. To infinity and beyond # Use `calc(infinity * 1px)` to remove the floor or ceiling of a clamp. div { inline-size: clamp( calc(-infinity * 1px), /* no floor */ 100%, calc(infinity * 1px) /* no ceiling */ ); } ## 5. Freeze view transitions # Make view transitions never complete. ::view-transition-group(*), ::view-transition-old(*), ::view-transition-new(*) { animation-duration: calc(infinity * 1s); } The `::view-transition` tree stays in the devtools DOM, giving you an opportunity to inspect or tweak. You can also freeze and inspect animations using the Animations panel in devtools. ## 6. Responsive radius # Another scenario where I would have reached for making a large number with scientific notation, is a responsive border radius. .viewport-responsive-radius { border-radius: clamp(0px, (100vi - 100%) * infinity, 20px); } .container-responsive-radius { border-radius: clamp(0px, (100cqi - 100%) * infinity, 20px); } If the elements inline-size is less than 100vi, the radius will be 0. If it's greater than 100vi, the radius will be 20px. There are a set of these available in Open Props. ## 7. Bools # Clamp an arbitrary number down to exactly 0 or 1, then use it: .flippy { --solo: clamp(0, (2 - sibling-count()) * infinity, 1); --crowded: clamp(0, (sibling-count() - 5) * infinity, 1); flex-grow: calc(1 - var(--solo)); font-size: calc(1rem - var(--crowded) * 0.125rem); } One variable now can drive color, offset, opacity, gaps, whatever. ## 8. Backdrop # You can use the spread feature of `box-shadow` to create a **non-interactive** backdrop: .backdrop { box-shadow: 0 0 0 calc(infinity * 1px) #0005; } Paint past the "entire viewport". ## 9. Scroll Trigger # Trigger a scroll driven transition in, and never transition out. .nav-title { timeline-trigger-activation-range-end: calc(infinity * 1px); } .product-title { animation: slide-and-fade 150ms ease both; animation-trigger: play-forwards play-backwards; } Though you'll see in the demo I use `scroll 100%` which is a specced way that feels closer to the intent I was going for, in that I wanted the range end to be the end of the scroll area. Try it: See the Pen by Adam Argyle (@argyleink) on CodePen. Also, just for funsies to share, here's the scroll driven version of the same navbar effect. Doesn't use infinity, but fun to try and compare scroll-triggered vs scroll-driven animation. See the Pen by Adam Argyle (@argyleink) on CodePen. ## Thats all # Hope you found that interesting! Comment with your own creative uses of `infinity`?
Adam Argyle
@nerdy.dev.web.brid.gy
nerdy.devWWW Ep248 Live At React Miami With Guests Jason Lengstorf And Kent C Dodds And Tanner Linsley And Francesco CuillaEp #248 **Live at React Miami with guests Jason Lengstorf, Kent C. Dodds, Tanner Linsley and Francesco Ciulla** Robbie and I chat with **4 guests in 1 episode**! Topics span things like Lambo's, MCP vs OpenClaw, agents building agents, polymorphic UI libraries, SDD + state machines, how Prolog is the most hated programming language, and whatnot. ⤷ whiskey.fm · youtube · spotify · apple Presented by GitKraken and Clerk
Adam Argyle
@nerdy.dev.web.brid.gy
nerdy.devProp For ThatAnnouncing Prop For That, a JS library that backfills what CSS doesn't provide us yet (and maybe never will). I'm done waiting for CSS to catch up to all the valuable information JS knows and done watching folks write the same little JS to just write a custom property to a component. " demo · docs · npm " Here's a basic example taking the value from a range slider to draw a nice gradient that fills up the slider: import 'prop-for-that/auto' // or import 'https://esm.sh/prop-for-that/auto' ` <input type="range" data-props-for="range" min="0" max="100" value="40" /> ` input[type="range"] { background: linear-gradient( to right in oklab, var(--theme) calc(var(--live-value-pct) * 100%), var(--track) 0 ); } ` codepen · docs example · codepen collection ## Why? # It's **super common** to need a few lines of JS for a simple thing like: * the value of the color input * the mouse pointer position * the size of the scrollbar * the colors present in an image or video * the battery level * an element's visibility * etc With Prop For That, you just declaratively specify on any element the props you want, and live props show up. "There's an imperitive API too, but the data attribute path is the slickest" Everything is a plugin that loads only if you need it too, ultimately putting you right where you wanted to be: **creating something sick in CSS using dynamic information** without wiring up some dorky JS. ## What kind of props? # My talk at CSS Day was an enumeration of all the ways CSS can adapt to users, contexts, pages, etc… which made me hyper aware of all the ways CSS couldn't adapt without JS. Here's a flat list of all the **live props** currently supported by the library: 1. Pointer x/y in the window 2. Pointer x/y inside/local to an element 3. Viewport pixel height/width values 4. Visual viewport information 5. Element size information 6. Element visibility 7. Scrollbar and thin scrollbar sizes 8. Input element values 9. Input element dirty, touched, pristine, etc 10. Select element value, index, count, etc 11. Colors from an image or gradient (average, accent, light, dark, etc) 12. Colors occuring in a video 13. Video progress 14. Image loaded or broken + natural h/w 15. Clock time 16. FPS 17. Online/offline status 18. Page focused/visible 19. Scroll velocity 20. Accelerometer and device tilt/orientation 21. Geolocation 22. DPR, CPU cores, memory 23. Page navigation type (reload, back, etc) And a few Chromium only props: 1. Network status like type, speed, save data, etc 2. Battery status 3. CPU pressure ## Style Queries # Style Queries being in all major browsers marks an important milestone for CSS, and made this library much more viable. Using Prop For That with Style Queries looks like this: import 'https://esm.sh/prop-for-that/auto' ` <form data-props-for="form-state"> <input name="name" required> <input name="email" type="email" required> <button type="submit">Save</button> </form> ` @container style(--live-all-valid: 1) { … } ` ## Bye noise # **Import, add attribute(s), have CSS fun.** Go make cool shit and share it with me 🤘🏻💀
Adam Argyle
@nerdy.dev.web.brid.gy
nerdy.devCSS Recently In All BrowsersHere's some rad CSS that just hit baseline between October 2025 - April 2026. At this point with the following features, the "I can't use it" vibe can shed away. ## Anchor Positioning # Anchor positioning lets you natively tether components to target elements without adjusting DOM semantics or crowding the main thread. This widget doesn't show green across the board as of writing this, there are sub features that aren't all supported, but the general featureset is ready. Checkout Tab's talk about `anchor` called Anchor Positioning at CSS Day 2025. Checkout my post on AIM if you missed it, neat anchor technique for FLIP-like transitions with anchor. ## @scope # CSS **selector** scoping, not _style_ scoping; a common misconception. However! With @scope we can simplify naming conventions or robobarf classnames just to avoid global cascade collisions. The "donut" feature is very special, it can limit styles from cascading into nested components by setting an end to the selector (a donut hole 🍩). Chris gave a talk about `@scope` called Scope In CSS at CSS Day 2025. ## Name Only Container Queries # @container no longer requires a size condition. You can now conditionally style elements just by name: .sidebar { container-name: sidebar; } .card { display: grid; @container sidebar { grid-auto-flow: column; } } ` * Chrome 149 * Safari 26.4 * Firefox 148 Chris wrote a good post about it over on FrontEnd Masters. ## shape() # Responsive, native CSS geometry. Draw complex clipping paths using standard CSS syntax and dynamic units (like `rem` or `calc()`) instead of being locked into rigid SVG pixel coordinates. Temani wrote a rad post about it over on FrontEnd Masters and a "complex" post CSS-Tricks. ## shape-outside with xywh() and rect() # Wrap inline text around precise geometric boundaries with xywh() and rect(). Typographical control over floating text flows without relying on images or clip-paths. * Chrome 150 (soon) * Safari 18 * Firefox 149 Still no pretext, but also still coo. ## view-transition-class and Types # SPA-like routing animations. With view-transition-class you can target massive collections of DOM nodes with a single animation rule, while JS View Transition Types let you programmatically direct "forward" or "backward" contextual motion. ## rcap, rch, rex, ric # Even more typographic precision. I wrote about these here.
Adam Argyle
@nerdy.dev.web.brid.gy
nerdy.devWhy AI Sucks At Front EndAI is a sycophantic dev wannabe that skimmed a shitload of tutorials. You get the results of a probabilistic guess based on patterns it saw during training. What did it train on? Ancient solutions, unoriginal UI patterns, and watered down junk. I'm about to rant about how this is both useful and lame. ## The Good # **AI loves the boring stuff. It thrives on mediocrity.** If you want some gloriously unoriginal UI, it has your back 😜 * **Scaffolding:** Generic regurgitation of patterns it's seen, done. * **Tokens:** Migrating tokens or mapping them out? It eats this tedious garbage for breakfast. * **Outlining features:** Generic lists ✅ * **Lying to your face:** Confident hot garbage on a silver platter. It'll hand you a snippet, dust off its digital hands, and tell you it finished the work. _It did not finish the work._ Aka: If it's a well-worn pattern, AI is there to help you copy-paste faster. Which, for a lot of programming, is totally the case. I'm genuinely finding a lot of helpful stuff in this department. ## The Bad # **Pixel perfection & bespoke solutions… what are those?** The exact second you step off the paved road of unoriginality, it faceplants. * **Bespoke solutions & custom interactions:** Try asking it for some scroll-driven animations or custom micro-interactions. It will invent a CSS syntax that hasn't existed since IE6. * **Layout & Spacing:** Predicting intrinsic/extrinsic page properties? It's already bad at math, how could it get this rediculously dynamic calculation correct. Spacing? Ha, seems reasonably to expect symmetry, but it's terrible at the math. * **Combined states:** Pinpointing where to edit a complex component state makes it cry. * **Accessibility:** It throws `aria-hidden="true"` at a wall and hopes it sticks. * **Performance:** It will give you the heaviest, jankiest solution unless you explicitly ask it to be for a specific (apparently "indie") performance solution. * **Tests:** Writing good tests? Good, no. A lot, yes. And the absolute best part? The more complex the component gets, the slower and dumber the front-end help becomes. Incredible how it can one shot a totally decent front-end design or component, than choke on a follow up request. Speaks to what it's good at. ## Why? # ### 1. It trained on ancient garbage # **It lacks modern training data.** It has an excessive reliance on standard templates because that's what the internet is full of. Modern CSS? It's barely aware of it. ### 2. It literally cannot see # **It's an LLM, not a rendering engine!** It's notoriously bad at math, and throwing screenshots at it means very little. It's stabbing in the dark. This leads to the classic UI interaction: **AI:** _"I'm done! Here is your perfectly crafted UI."_ **Me:** _"There's a gaping hole where the icon should be, fix the missing icon."_ **AI:** _"You're absolutely right. Let me fix that for you."_ ### 3. It doesn't know WHY we do things # **It doesn't understand the "why" behind our architectural decisions.** SDD, BDD, or state machines might help guide it, but the models weren't exactly trained on those paired with _stellar_ solutions. We're asking a giant text-predictor to make new connections on the fly. We can get it there, but there's so much to consider we have to spell it out before it starts making the connections we want. ### 4. Zero environmental control # **It doesn't control where the code lives.** It can write annoyingly amazing Rust, TypeScript or Python, but those have the distinct advantage of a predictable (pinnable!!! like v14.4) environment the code executes in. That's not how HTML or CSS work, there is no pinning the browser type, browser window size, browser version, the users input type (keyboard, mouse, touch, voice), their user preferences, etc. That's complex end environment shit. The list goes on too, for scenarios, contexts and variables the rendering engine juggles before resolving the final output. The LLM doesn't control these, so it ignores them until you make them relevant. Even prompting in logical properties, you have to ask for this kind of CSS. These should be CSS tablestakes output from LLMs, but it's not. And even when you ask for it, or provide documentation that spells it out, it's not guaranteed to work. The place where HTML and CSS have to render is chaotic. It's a browser, with a million different versions, a million different ways to render, a million different ways to interact with it, and a million different ways to break it. **It's a moving target, and LLMs are terrible at moving targets.** ## Damnit humans # **We're a LLM combinatorial explosion.** We're wildly unpredictable targets. We change our minds, we switch viewports, we change theme preferences, we changes devices, we change browsers, we change browser versions, we switch inputs, we change our everything. We're not a static target. We're not a pattern that can be learned. There is a "human mainstream" of behaviors, preferences, and expectations where LLMs can be genuinely helpful; but our "full potential" matrix will be exploding LLM output patterns for a long time to come. IMO at least. unless we Borg.