CSS: Weekly Summary (December 01-7, 2025)

I’d say this week in CSS felt a bit like popping the hood of a car and finding both a shiny new turbocharger and a few bits of duct tape. There’s careful engineering, playful tinkering, and a gripe or two about the things that still trip folks up. I would describe the posts I read as a mix of deep spec-minded thinking and hands-on, keyboard-in-the-browser play. To me, it feels like people are trying to balance two things: making web layouts smarter, and keeping the day-to-day of building simple and sane.

Anchor positioning and the Inset-Modified Containing Block (IMCB)

Bramus dug into something that, at first glance, sounds like spec-level boredom. But honestly, it’s one of those little bits that trips up real projects. The post walks through the Inset-Modified Containing Block — IMCB for short — and how anchor positioning works with it. It’s not just theory. There are visuals, fiddles, and a practical take on align-self and justify-self inside that IMCB space.

I would describe the IMCB as a new little room in CSS where anchors can move around. To me, it feels like trying to find the right shelf in a closet that’s been rearranged. You have inset values that change the size of the room, and then the usual alignment rules that decide where the furniture goes. But the surprise is that inside corners and inside edges don’t always have explicit position-area slots. So when you expect an element to sit snug in a corner, it might not. The post answers that — with concrete rules and demos that are easy to play with.

There’s also a slightly practical tool vibe in the post. The author shows small visual helpers that make the invisible math visible. Like using a flashlight to look under the bed. It helps if you’ve wrestled with anchor positioning before. If you’ve not, you’ll still get a sense that CSS keeps getting these nuanced alignment spaces, and that they matter for precise UI work.

It’s the kind of write-up that makes you want to try the examples in your own notebook. Or, yeah, in a codepen at 2 a.m. when you can’t sleep but you’re curious.

The Google Antigravity site, rebuilt with Modern CSS

Also from Bramus — and that’s an enjoyable coincidence — a rebuild of the old Google Antigravity thing using Modern CSS. If you remember that era of wild scroll-jacking demos (some folks love ’em, some folks hate ’em), this one is a study in how to recreate the uncanny scroll experience while using progressive enhancement.

The author leans on newer features: @starting-style, Container Queries, and Scroll-Triggered Animations. That combo reads like a toolkit people have been waiting for a while. I’d say the interesting part is not just that the site is rebuilt, but how it’s rebuilt: keeping the original vibe without breaking the basics when animation isn’t available. The post argues for progressive enhancement as not just a nicety, but a practical guardrail. To me, it feels like building a skateboard ramp with a safety rail — the tricks are fun, but the ramp still needs to stand up.

There’s also a short riff on scroll-jacking. The author is realistic: the original was uncanny and arresting, but it’s not for every site. The rebuild is more of a demonstration than a production-ready template. Still, it shows what modern CSS can do when you combine layout-aware tools with motion specs. It’s worth a read if you like that kind of playful demo-work, or if you want to steal an idea for a portfolio piece.

Should CSS be Constraints?

Pavel Panchekha wrote something that channeled the speculative part of the brain. The post asks whether CSS should be replaced with a constraint-based system. That’s not small talk. It’s the sort of question that makes people who write specs rub their temples.

The gist: constraints can express intentions more directly in some cases. Want an element centered relative to something else? A constraint system can declare that cleanly. But constraints aren’t magic. Pavel points out real problems: under-determined and over-determined layouts, and the unpredictable ways solvers can behave. There’s also the reality that constraints can make debugging a mess. They can hide the why behind the what. The post doesn’t advocate a full rip-and-replace. Instead it nudges toward more intuitive rule systems and better, standardized layout modes that capture common patterns.

I would describe the tone as both affectionate and wary. The author knows the promise of constraints, and also knows how brittle they can become. To me, it feels like imagining replacing the plumbing in a house while still living in it. You might get better water flow, or you might end up with leaking issues in three rooms you didn’t expect. The post reads like advice from someone who’s lived with the plumbing and fixed the leaks.

For readers who like design theory and language design, it’s a short think-piece that’s good for re-centering the debate. It asks: do we need a radically different model, or can we make existing models kinder to humans?

Vanilla CSS is all you need

Rob Zolkos takes a practical route and walks through three 37signals products built with a "nobuild" philosophy. The case study — Campfire, Writebook, and Fizzy — is about keeping things small and semantic, using modern CSS features without a big build pipeline.

This post has the smell of a tidy workshop. The author praises simple CSS structure, flat files, and semantic naming. He contrasts that with utility-first systems like Tailwind, not by demonizing them but by pointing out that a content-driven system can be more maintainable and easier to reason about. The post also highlights newer CSS features making this approach possible, like OKLCH color space for consistent palettes and other niceties that make design predictable.

I’d say the strongest pull in this piece is its evangelism for doing more with less. There’s a confident tone about what’s sufficient: sometimes vanilla CSS is the right tool, and the modern language has enough horsepower to handle many real products. The argument is practical: fewer moving parts, fewer surprises. It’s like choosing to bake bread at home instead of buying pre-sliced loaves — more effort, but more control over the result.

There’s also a gentle poke at the cult of tooling. Not everything needs to be compiled, and the outcomes aren’t always better with more tools. The examples are modest and readable. The post nudges you to try being slightly more conservative about adding build steps, at least until you know you need them.

Fizz Buzz in CSS

This one is just delightful. Susam Pal tackles the well-known Fizz Buzz challenge, but with the strict rule that the output must come only from CSS — no HTML, no JS. The result is a four-line CSS solution, and a minified version for anyone who likes watching cleverness get compressed.

I would describe this as a small party trick. It’s the sort of thing that makes people grin. To me, it feels like solving a crossword with only a pencil you sharpened yourself. There’s no practical reason your site needs Fizz Buzz from CSS. But the exercise highlights the language’s expressive quirks and the delightful ways constraints spark creativity.

The post is short and playful. It invites people to try and beat the four-line solution. There’s a community nudge there: show me a shorter one. It’s the web equivalent of a friendly flex.

Homepages and redesigns

Two posts this week touched on personal site redesigns. James' Coffee Blog wrote about building a new home page, and Lalit Maganti shared a broader homepage redesign, the re-introduction of light mode, and typography improvements.

James’ post reads like someone proud of tinkering. There’s a joy in experimenting, and a repeated reminder that the author learned by playing in the dev tools. He cites reading ’The Non-Designer’s Design Book’ and lets that friction of being both a developer and a designer show. I’d say it’s reassuring. It’s the work of someone who treats their site as a lab. The narrative is messy in a good way: mockups, tweaks, small failures, then a design that finally feels like it breathes.

Lalit’s piece is more product-like. The site moves to a two-pane dashboard to handle varied content. That’s a sensible UI choice when you have different types of writing and want them to be discoverable. The author also simplified CSS, removed complexity, and brought back a light mode. Typography got a refresh too, with new fonts and small improvements to readability.

The two posts together make a nice pair. Both emphasize smallness and clarity. Both accept that a homepage is not a final object but a work-in-progress. You can almost smell the coffee in James’ post and the clean stationery in Lalit’s.

There’s a small theme here: personal sites are where people try new ideas before they spread. They’re the testing ground for typographic choices, layout experiments, toggles like light/dark, and the kind of streamlined CSS that Rob praises.

Recurring threads and where the conversations overlap

If I were to pick the threads that tie these posts together, they’re mostly three:

• Modern CSS features are getting used in real ways. Bramus shows layout and motion features, the Antigravity rebuild shows how to combine them, and Rob shows they can support a nobuild philosophy. People are no longer waiting for the spec; they’re using it.

• Simplicity vs. power. This is the tug-of-war you see in Rob’s nobuild argument, in Pavel’s constraint caution, and in Lalit and James choosing to simplify their homepages. A lot of the week’s writing is about finding the sweet spot between expressive power and understandable, debuggable rules.

• Experiments as learning. The Fizz Buzz piece is pure play. The Antigravity rebuild is demo play. James’ home page is experimental design. These are reminders that the most useful innovations often start as small, weird experiments.

There’s also a subtle agreement about progressive enhancement and predictability. Bramus calls it out explicitly. Rob demonstrates it in practice by keeping things simple and reliant on the platform. Pavel worries that constraint systems could reduce predictability. The net effect is a shared desire for CSS to be more reliable and easier to reason about.

Points of disagreement or tension

Not many posts formed a direct argument with one another, but the tension is visible in the margins.

• Tooling vs. nobuild. Rob’s straightforward case for vanilla CSS is friendly resistance to the ever-expanding toolchains that many projects adopt. It’s not that Tailwind or build systems are wrong; it’s that they’re not always necessary. Some folks will nod, others will raise an eyebrow.

• Spec complexity vs. user simplicity. Pavel’s thought experiment about constraints pushes toward rethinking how CSS expresses intent. Others, like Bramus and Rob, show that expanding the language with useful, well-specified features can also improve expressiveness without replacing the whole model. It’s a debate about evolution versus revolution.

• Motion and progressive enhancement. Bramus’ Antigravity rebuild shows motion done with a careful fallback in mind. But some purists still dislike scroll-jacked experiences. So the tension is more cultural than technical: what’s tasteful and usable versus what’s impressive and bold.

Little practical takeaways (the kind you might steal)

• If you wrestle with anchor positioning, check out the IMCB write-up from Bramus. The visuals make the rules less mysterious. It’s a good shortcut when an element refuses to sit where you expect.

• If you want to experiment with motion and layout without breaking accessibility, look at the Antigravity rebuild for a pattern: use modern specs, but protect baseline functionality. The post shows how to layer effects on top of robust markup.

• If you’re tempted by a constraint system, read Pavel’s post first. It’s not a showstopper, but it’s a useful reality check. Constraints sound neat until they don’t. Understanding the edge cases matters.

• Try a small "nobuild" approach on a new project. Rob’s case studies are convincing: start simple, use native features, and only add tooling when you have a clear need. It’s a tidy way to keep complexity from creeping in.

• If you enjoy quirky hacks, the Fizz Buzz CSS piece is tiny and fun. It’s an easy way to practice the bizarre corners of the language and maybe find a clever trick to reuse.

• Treat your homepage like a lab. James and Lalit both show that homepages are good places for iteration. Light mode, typography, tiny CSS reductions — these are low-risk experiments that teach a lot.

A few analogies that stuck with me

• The IMCB felt like finding the right shelf in a newly organized closet. You know the shelf exists, you just need the right diagram to put the book where it belongs.

• The Antigravity rebuild felt like restoring an old car with modern parts. It looks familiar, but it runs smoother and has seatbelts now.

• Pavel’s constraint idea felt like thinking about replacing a house’s plumbing: maybe better flow, but a lot can go wrong mid-job.

• Rob’s nobuild philosophy is like baking bread at home. You control what goes in, and sometimes that makes the result better.

• The Fizz Buzz trick is a party trick. Cute, educational, and harmlessly showy.

If you feel like reading deeper

Most of these pieces are friendly entry points. The posts are not all long spec essays. They’re practical, and they leave little breadcrumbs if you want to chase the details. If you like neat diagrams and layout rules, start with Bramus on IMCB. If you like playful demos and motion, the Antigravity rebuild is cheerful company. If you like language design and what it would mean to re-imagine CSS, Pavel gives you a clear, skeptical tour. If you want to see how small teams keep CSS simple and maintainable, Rob offers concrete examples. For a small, clever diversion, check out Susam and the Fizz Buzz piece. And if you want the human angle — how folks tinker with their homepages and typography — the posts from James and Lalit are warm and honest.

I’d say the week felt like a reminder: CSS isn’t just a language of boxes. It’s a toolbox that people keep reshaping. Some want fewer tools. Some want smarter tools. And some just want to play. That mix is healthy. It keeps the language useful and keeps the craft interesting.

If one tiny bit of advice landed here: try a small experiment in your next project. Trim a build step. Try a container query. Play with an anchor position until you understand the IMCB. Make a tiny motion demo with graceful fallbacks. The web grows when people try small things and share the messy results. And I’m always glad to see that happening — messy, practical, and a little bit joyful.