Skip to main content

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.

What would HTML do?

Smart take here from Jeremy about composable design systems:

Colours, spacing, type; these are all building blocks that a designer can compose with. But it gets murkier after that. Pre-made form fields? Sure. Pre-made forms? No thank you!

It’s like there’s a line where a design system crosses over from being a useful toolkit into being a bureaucratic hurdle to overcome. When you hear a designer complaining that a design system is stifling their creativity, I bet it’s because that line has been crossed.

Jeremy argues that design systems should have many small pieces that can be easily reconfigured—and this happens to tie in nicely from another post of his about HTML web components:

...what if my web component needs to do two things?

I make two web components.

The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.

Yes! This is precisely why I started ranting a while back about how, whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”

HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes from: everything has one job, does it really well (ideally), which makes the possible options almost infinite.

Design systems should hope for the same.

An alternative proposal for CSS masonry

Rachel Andrew:

The Chrome team believes that masonry should be a separate layout method, defined using display: masonry (or another keyword should a better name be decided upon). Later in this post, you can see some examples of what that could look like in code.

There are two related reasons why we feel that masonry is better defined outside of grid layout—the potential of layout performance issues, and the fact that both masonry and grid have features that make sense in one layout method but not the other.

The most compelling argument for me is the potentially very confusing overlaps and underlaps between grid and masonry where sometimes a grid property just won’t apply to a masonry-style layout. However, this example that Rachel shares in her post certainly feels icky to me:

.masonry {
	display: masonry;
	masonry-template-tracks: repeat(auto-fill, auto);

.placed {
	masonry-track: 2 / 5;

At a quick glance, and without understanding too closely what’s going on under the hood, I’d question why the heck this looks so much like a grid-but-not-a-grid syntax. Maybe I just gotta sit with it some more though!

Printing Music with CSS Grid

Cool cool cool:

Too often have I witnessed the improvising musician sweaty-handedly attempting to pinch-zoom an A4 pdf on a tiny mobile screen at the climax of a gig. We need fluid and responsive music rendering for the web!

Music notation should be as accessible and as fluid as text is, on the web; that it is not, yet, is something of an afront to my sensibilities. Let us fix this pressing problem.

Maybe we need display: music , too? Okay that was a mean joke and I did not mean it, everyone just calm down. Jeez.