[Robin]: CSS-Tricks started way back in 2007. That’s 15 years! Since then Chris has redesigned the website a bunch of times and with each new version of the site comes a visual refresh, a new trick or two, and the adoption of the latest features of the web platform.

So I thought it would be interesting to go through the archives and look at the design of CSS-Tricks over the years.

One great example can be found in this post by Mads Stoumann (which is also wondrously in-depth) called Don’t Fight the Cascade, Control It which uses this example:

@layer generic, components; @layer components { body { background-color: lightseagreen; } } @layer generic { body { background-color: tomato; } }

We set up two groups above, or “layers” of CSS. They both have conflicting styles within them and only one can “win”. But in that first line there we’ve told the browser which is more specific than the other. We’ve told the browser that the block of styles in “components” will override “generic.”

In this example, the body element will have a color of lightseagreen because even though tomato comes second here in the file, we’ve defined the order of the layers at the very top. Even if that first layer (“generic”) had a matching selector that was 100✕ stronger, lightseagreen would win. Think of layers of a cake. A big, stressful, and complicated cake that you absolutely do not want to serve at a wedding or a birthday party.

With Cascade Layers we can now control the specificity of large portions of our CSS and we can now safely control what overrides what. For example, let’s imagine we have a CSS reset, then we want our component styles on top, then you want your third-party libraries to override all of that other stuff. All you’d have to do is write this:

@layer reset, components, thirdParty; /* those layers can then go in any order here */

This makes a ton of sense to me! (Although I could also imagine a situation where you do it in the exact opposite order where third-party code is lower in the stack and easier to override.) Another great example though is from Una’s video I mentioned earlier…

@layer typography, base, utilities; /* those layers can then go in any order here */

With those utility classes—like .bg-red or padding-left-10px—you’ll almost always want them to override your typography and base styles. So now we can safely guarantee that great chunks of CSS are layered on top of each other properly! Neat.

But… why? Why is this useful and why should I care?

Well! First: rude. Second: in the past we’ve had to abuse !important and throw it on things to try and sort of z-index: 999999999 our way out of complex CSS problems. We always wanted to override any other elements that might be too specific in our codebase but we never had the tools to do so. But now we do! (Or, rather: we almost will once this stuff lands in browsers).

I do have a slight old-man-yells-at-cloud thing to ruin your day here. I sort of worry that @layers could be really, truly confusing. Let’s say I have no idea that these @layers are set up and I’m not all that familiar with CSS, then perhaps I could get pretty dang confused as to why my styles aren’t being applied in the browser as I expect they would. But then perhaps (playing my own devil’s advocate here) we don’t want folks to just throw their styles wherever and we just want our DevTools to make it super clear to those folks that the reason their styles don’t work is that there is this bigger system they don’t quite understand yet.

Anyway, I’m excited about this and I think it’s going to be extremely useful to a lot of folks who own large CSS codebases with lots of chefs in the kitchen. For most CSS folks I can see them not having to touch this, though. Maybe.

See how this weather component has entirely changed because it’s in a sidebar? That’s the power of container queries right there.

Although there’s no word when they’ll ship in browsers yet, it seems like they’re gathering steam in the community and they’re an official draft spec now. I have a feeling that container queries are going to move fast and ship in browsers pretty darn quickly (although this is just a hunch).

But the big news of the week here is that Surma made a polyfill—a chunk of code that lets other code work on older browsers—and it rather magically allows us to use container queries today!

To get started, we first need to load the script:

// Test if container queries are supported already by the browser const supportsContainerQueries = "container" in document.documentElement.style; // If not, load the polyfill if (!supportsContainerQueries) { import("https://cdn.skypack.dev/container-query-polyfill"); }

(Although I would probably just download the polyfill and throw it in here instead of making another request to a CDN that can break, this is just a quick example.)

Next up, we can write our HTML…

<div class="weather-wrap"> <dl class="weather"> <!-- the rest of our component markup goes here --> </dl> </div>

We need that extra div of .weather-wrap to apply our container query logic to. Now, we can apply our styles that “activates” the container:

.weather-wrap { container-type: inline-size; container-name: weather-wrapper; }

Two new CSS properties here. Fear not!

When we say container-type: inline-size that translates to “I want this container query to be used on the inline axis (so for English-speaking languages that means left/right or perhaps you can think of this as width). inline-size is an odd thing that I’m still trying to get my head around (more on that in a future newsletter).

container-name on the other hand is telling the browser that we want to refer to this query as weather-wrapper elsewhere in our CSS, like this:

.weather { display: flex; } @container weather-wrapper size(max-width: 700px) { .weather { flex-direction: column; } }

The way I think about it is prep work first: tell the browser you want a wrapper that acts as a container query, then somewhere else in your CSS you can give it instructions. It’s a bit weird but not too weird and unfamiliar. If you squint at the code above it does look odd but you can read it and parse it, even if you’ve never seen anything like it before. And that’s neat!

If you’re interested in reading more about this polyfill then I’d recommend checking out Bramus’s post on the matter since it clarified a few things for me.

This polyfill is so exciting because it makes something that has been theoretical for such a long time suddenly tangible, real. You can go and use them today! And sure, it’s not perfect, but holy hot dang mackerel we have container queries in browsers!

(Almost.)

Chris writes:

Thanks for stopping by and reading this site. If you didn’t, I’d be out of a job around here, and I quite like this job so I owe it all to you. Like a family holiday card, allow me to share how the year went from our perspective, both with numbers and feelings, and then do a review of our goals.

I reckon the common pattern this year in the newsletter was that, yes, all these tricks and front-end stunts are extremely cool but keeping up with this stuff shouldn’t be a burden. We try pretty hard to make sure this newsletter doesn’t feel like an endless list of things. We don’t want to overwhelm you, and we certainly don’t want this newsletter to be homework. On that front, there will be more of the same next year because ultimately we want learning about front-end development to be a ton of fun and we hope to encourage everyone to experiment with old techniques and new kick-flip things (without the stress of FOMO).

Anyway, we very much hope that next year brings you good fortune and what not but we also hope you stick around to see even weirder, wilder changes in the front-end development space.

We’re pretty darn excited.

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Lots of guidelines are like that. But! They’re not just here to boss us around—even if WCAG compliance is written into law in some cases. The ultimate goal here is to help us make better websites and the WCAG 2.1 (which is the current standard and recommendation) does just that. It provides us with ways to test our work, like with color.

Stacie Arellano wrote about all this a while back and how these color recommendations let us test to see if our websites are easy to read (think black text on white background good, yellow text on yellow background bad). The WCAG 2.1 has rules about how color ratios are calculated, like over on accessible-colors.com where they tell you if your text is readable and what you need to do to fix it.

These ratios in other tools like this one are directly from the WCAG 2.1 guidelines and tons of designers and developers use them to make the case to change the colors of things.

Onto the drama: the new WCAG 3.0 Working Draft has a new color contrast method called Advanced Perceptual Contrast Algorithm (woof!) which looks like it has a much improved method to figure out if our text is readable or not. That’s great! But Eric Eggert argues that WCAG 3 is not ready yet, and it won’t be for quite some time:

In general, web technologies are very good citizens to early adopters like me: They usually come with suitable fallbacks that allow you to use, for example, animations and transitions in 2009 with the fallback of no animation for browsers without support.

With guidelines like WCAG 2.1 and 2.2 (to be released later), the same approach is true. If you use WCAG 2.2 Success Criteria now, the Guidelines are built to be backwards compatible. So you will never break a 2.0 or 2.1 audit by using it. But WCAG 3 breaks backwards compatibility. This is a conscious move to better adapt the standard to serve different disabilities which WCAG 2 did not sufficiently cover, due to its structure.

Interesting! I hadn’t heard about any of this before and it looks like all of this works very differently to CSS or HTML or JavaScript where we’re encouraged to use the latest and greatest tools with progressive enhancement in mind.

Kilian Valkhof clarifies this argument really well here:

Whatever is currently written down as WCAG3, including APCA, is subject to change. This is great! It means developers still have a chance to submit feedback. If you like something, don’t like something, or have suggestions: now is the time.

It also means that whatever is written down as WCAG3 at the moment, is not something you should base your accessibility choices on. Worse, using these guidelines while they’re not ready might lead to you thinking you’re doing the right thing while not conforming to WCAG2, and you’ll have to change it.

So: don’t use APCA, and stick to the current WCAG 2.1 Guidelines when it comes to color. Got it. But I think there’s an important lesson from all this somewhat complicated terminology and drama. I think this proves we shouldn’t jump on the coolest, latest trend when it comes to accessibility because, on the web, accessibility is one of the slowest things to change. And there’s a good reason for that!

If we use the latest stuff too soon then it does the exact opposite of what accessibility best practices attempt to do in the first place and it leaves people behind. So let’s stick to the boring stuff.