Skip to main content

Keeping up with CSS

Max Böck on all the new things in CSS:

While learning the syntax for any given CSS feature is usually not that hard, re-wiring our brains to think in new ways is significantly harder. We’ll not only have to learn the new way, we’ll also have to unlearn the old way, even though it has become muscle memory at this point.

Yes! This is the hardest part of web development for me, as there’s a lot of work that has to go into tearing down the years of experience I’ve had with, say, how CSS used to limit us in terms of layout. CSS Grid isn’t rocket science but unlearning the old and familiar ways sure is complicated. That takes time and serious amounts of effort.

And yet even though we’re living through the golden age of UI on the web, it doesn’t mean we have to use every new CSS thing in every single project. Sure, if something helps save you time then that’s great. Or if it unlocks some new super power then that’s fantastic. But you don’t have to use @layers and logical properties and :is or :has if you don’t need them.

It’s more than ok if you don’t know how the fanciest features work today and I don’t think you should force yourself to put them into a project if you don’t really need to. Yes, many of these new tricks expand what’s possible on the web today and make things easier but it’s perfectly fine to not be at the absolute bleeding edge of this stuff. And keeping up with CSS shouldn’t feel like a full time job, and it definitely shouldn’t stress you out.

This is the real magic of CSS though! All the old techniques from a decade ago work just fine. Are there better ways to do X, Y, or Z? Sure. But it’s also okay to not always be optimizing, to not always be grinding away at the infinite factory line of new CSS features in this mad-dash panic to feel like you’re a real front-end developer.

The thing is that a webpage from 1995 or a webpage from 2035 can—and often should!— work just the same. That’s ok!

Design Spells

Design Spells is a big collection of animations and fun, interactive details taken from all over the web. Lots of these are stressful and overwhelming to me but there’s some particularly absurd things in here I love like Webflow’s ridiculous 404 page or Vercel’s interactive conference badge.

If you’re looking for something to make a Codepen out of, then this is also a fantastic resource to pick something, copy it, and learn how they made it under the hood.

New magic for animations in CSS

Cool, punk rock stuff coming in hot off the press from Chase McCoy here:

There are two new features coming to CSS that will make it much easier to further avoid JavaScript when implementing animations:

  1. Animating to and from display: none; for the sake of enter/exit animations.
  2. Animating to and from the intrinsic size of an element (such as height: auto;).

Traditionally, animating something into our out of the screen (as opposed to just hiding it visually) required JavaScript to remove the element from the page after waiting for the animation or transition to complete. No longer!

This is a BIG deal. I feel like maybe 50% of my late-night panicked CSS-related searches are about these two topics alone. Perhaps the most eye-opening part of Chase’s blog post though is this bit:

.item {
	@starting-style {
		opacity: 0;

	opacity: 1;
	transition: opacity 0.5s;

This @starting-style chap is for when you want an element to be hidden by default but then fade in. And Una Kravets and Joey Arhar wrote about this a while back for the Chrome blog where they have a fantastic demo of a todo list in which each new item added is invisible by default with @starting-style and then expands into view.

I can see myself using these new CSS animations in every project from now until the end of time!

11ty goes independent

This is super cool:

...11ty is making some bigger moves: we’re going all-in to create a fully independent and sustainable, grass-roots funded open source project in 2024.

Practically speaking this means that for the very first time in 11ty’s history, I will be working independently on 11ty full time. This means increased iteration speed, more responsive official support, more features and bug fixes, and faster releases.

Exciting stuff! It’s no secret that I’m an 11ty super fan since this very website is powered by it under the hood. Either way, if you or business can help out here, go support this thing and help make the web a better place.


There’s been some chatter over the last few days about “Baseline” and I’d heard the name in passing before but I must be honest: I was pretty embarrassed to ask around because a lot of blog posts mention this thing as if it’s been kicking around forever.

(I think it was announced at Google I/O last year and it managed to slip me by! How embarrassing!)

Let’s set the stage then: a “Baseline” feature can be anything—a new CSS property or a handy new thing in JavaScript—and the idea is that, at a glance, us developers can see if that feature is coming down the pipeline or if it’s already supported by browsers today. This should help us get a feeling for whether we can use the feature without a care or if we should think about a backup plan if it’s not supported by some browsers.

This is great because the standards process has felt entirely random to me over the years. I usually don’t know what’s going to ship or what cool new features are going to be available soon. “Baseline 2024” for example is all the features that are new to the web platform this year and you can see a handy list of all them over on The Web Platform Dashboard which is pretty fantastic. In terms of CSS, that means...

  • Declarative Shadow DOM
  • CSS offset-position and offsetpath values
  • The Popover API
  • align-content on block layout

There’s also the Baseline widget (boy, keep saying that over and over and it feels like saying “iPad” obnoxiously without the “the”) and it’s implemented all over MDN and CanIUse, like in this example for the new <search> element. This chap started to be rolled out back in December and the label comes in three flavors: Widely supported, Newly available, and Limited availability.

This is all useful stuff but I love what Jeremy had to say last week:

...I really like how it’s nice and glanceable right now. But it would be nice if there way some indication that a newly-available feature is a progressive enhancement.

For now it’s up to us to make that distinction. So don’t fall into the trap of thinking that just because a feature isn’t listed as widely-available you can’t use it yet.

One example might be text-wrap: balance because, in the spirit of giving hints and suggestions to browsers, it’s totally okay if older browsers ignore that rule since it’s a nice-to-have progressive enhancement. I do think that the “Widely supported” label is supposed to give an indication of that. But then some features that are “Newly available” are totally fine to use because they don’t break any functionality if they’re not supported and they gracefully degrade. So things are a little confusing on that front today.

Either way, I think this is a great improvement and I’m going to use the heck out of it. And I think I prefer bucketing these new features by year more so than I do by version number, like “CSS5”.

Generating text colors

I had never heard of this exciting contrast-color function before:

.element {
	background: var(--bg-color);
	color: contrast-color(var(--bg-color));

That’s from Lea Verou’s great piece about generating text colors. The way it works is that you pass a background color into the function and it’ll spit out a color that’s accessible to read as text on top of it. This solves about 90% of the problems I have with working with colors today as it’s super frustrating to constantly redefine variables or create new ones, just when the design calls for the background to change.

It might be a bit of a wait until it lands in browsers though, as Lea writes:

Glorious, isn’t it? Of course, soonish in spec years is still, well, years. As a data point, you can see in my past spec work that with a bit of luck (and browser interest), it can take as little as 2 years to get a feature shipped across all major browsers after it’s been specced. When the standards work is also well-funded, there have even been cases where a feature went from conception to baseline in 2 years, with Cascade Layers being the poster child for this: proposal by Miriam in Oct 2019, shipped in every major browser by Mar 2022. But 2 years is still a long time (and there are no guarantees it won’t be longer). What is our recourse until then?

Lea then talks about how it’s possible to set the color of text based on its background today with the relative color syntax. Super smart stuff.

Three Layers of UI Interaction

Drew Powers wrote about how to polish UI and described this process as the 3 layers of UI interaction:

  1. Render area: where does this element appear?
  2. Hit area: what is the shape/size/placement of the invisible interactive area?
  3. Focus area: when Tab-ing, what is the focus ring shape/placement?

What happens when you don’t care for these things? Well, I reckon everything about a UI then feels uncertain and we tend to navigate around with a real lack of confidence. But there’s been many times where I’ve forgotten about that third one!

Time-based CSS animations

This post by Chuan about time-based CSS animations has a ton of bonkers CSS tricks that are worth checking out:

After years of wait, CSS now has enough Math functions supported, particularly mod(), round(), and trigonometric functions. It's time to revisit the time-based way of animation, hope it'll be more useful this time.

Chuan uses these functions to set up a custom variable via the CSS Houdini API and then track the time in milliseconds. So beware, this is pretty wild stuff:

@property --t {
	syntax: "<integer>";
	initial-value: 0;
	inherits: true;

@keyframes tick {
	from {
		--t: 0;
	to {
		--t: 86400000;

:root {
	animation: tick 86400000ms linear infinite;

Chaun also works on css-doodle which is a web component for drawing cool and elaborate patterns. All of this stuff is very much worth checking out!

Unleash the power of scroll-driven animations

Here’s a great video course about the power of scroll driven animations by Bramus and he takes what we already know about CSS animations but gets into the nitty gritty new-ness of binding these fancy animations to the reader’s scrolling behavior.

Speaking of which, here’s Bramus writing about them in his ever-so-excellent demo page from a while back:

Scroll-driven animations are a common UX pattern on the web. These are animations that are linked to the scroll position of a scroll container. This means that as you scroll up or down, the linked animation scrubs forward or backward in direct response. Think of interesting effects such as parallax background images or reading indicators which move as you scroll.

What clicked for me in Bramus’s video series is that with CSS alone we can now detect if an element is visible in its “scrollport” and then animate it in or out or upside down. So it’s not just about adding big, fancy (and often annoying!) animations to the page. Instead, I think subtle examples like this stacking card effect is where scroll-driven animations are going to really shine. But that’s just my hunch!

Either way, I’m extremely excited about all this stuff because I think it’ll lead to more performant scrolling animations but it also unlocks untold power for us web designers to make subtle visual changes to the reading experience.

Web Components Demystified

Scott Jehl just kickstarted his course on web components and it just sounds great:

Fortunately, we now have a standard component model built right into our browsers, and using its various technologies can help us cut delivery weight and reduce complexity. Many of the largest companies in the world have already begun transitioning their sites and design systems to use web components, and major JavaScript libraries like React have greatly improved their compatibility to work with them as well. And while web components are indeed ready for production today, in the coming months several specifications are shaping up to make them even better. This course aims to cover all of that.

Can’t wait.

Applying P3 colors

Andy Bell set out to convert all the hex colors (like #FFFFFF for white) into p3 colors and wrote up his process:

I’ll be honest. I am not smart enough to explain the new colour systems that CSS has in its ever-expanding toolset. What I can do though, is show you what a major impact they can have with not much effort.

Andy also links to which lets ya pass in any hex value and it’ll do its best to transform it into a p3 color.

Hints and Suggestions

Miriam Suzanne gave a fantastic talk the other day during 11ty’s International Symposium on Making Web Sites Real Good and I couldn’t possibly recommend it more. The highlight for me was when Miriam talks about the “CSS is awesome” meme:

This is the reason that the default overflow is visible: if we get cocky and make a box too small for our text, browsers will try to bail us out. Not because it’s the best looking solution but because the web will try to protect content whenever it can. Browsers are helping us out here.

So to me, this meme, this “CSS is awesome” box-breaking meme, it actually perfectly captures what is awesome about CSS and how much can go wrong when we try to control things that we shouldn’t necessarily control. When we add too many constraints at once.

I love that meme for the wrong reasons.

Miriam argues that this is a core part of CSS’s design but it’s also a political choice: to protect the content and protect the user we shouldn’t treat the CSS we write as a series of strict rules. Instead, we must think of them as hints and suggestions to the browser. Or, as Miriam says: guidance with a light touch.