📝 CSS-Tricks 287: The History of CSS Tricks’ Design

View this newsletter on the web.

[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.

Issue 336

Subgrid, focus-visible, everything flexbox, and CSS fingerprinting.

 
CSS Layout News
Issue 336
By Rachel Andrew – 24 Jan 2022 – View online →
Some genuine layout news to cover this week with an intent to prototype for the subgrid value of grid-template-rows and grid-template-columns. While there has been an implementation of the value in Firefox for some time, we’ve all been waiting for it to land in Chromium-based browsers.

If you haven’t looked at subgrid yet, here’s my talk from CSSConf EU in 2019, back when we could all meet in big rooms and chat about CSS.

Rachel Andrew

📝 CSS-Tricks 286: CSS Cascade Layers are (almost) here

[Robin]: The next big thing that’s coming to a browser near you is CSS Cascade Layers. Una Kravets made a great video all about them and how they’re coming to Firefox and Chrome pretty dang soon. I’d definitely watch that video for a more in-depth look, but my quick summary is this: they let you have greater control over specificity in your CSS files.

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.

Issue 335

Color Gradient Vector Fonts, Cascade Layers, gradients, and a responsive design course.

 
CSS Layout News
Issue 335
By Rachel Andrew – 15 Jan 2022 – View online →
Hello! I took a week off as it seemed like folks took time off over the holidays and I didn’t find enough stuff to bother your inboxes with. So here is issue 335 with some news, and other interesting layout things.

I hope that your 2022 is starting well,

Rachel Andrew

📝 CSS-Tricks 285: The Year of the Container Query

[Robin]: My hunch is that 2022 will be The Year of the Container Query. Everyone’s excited about them, and for good reason: this new and fancy addition to CSS makes a component respond to whatever container they’re placed in. For the first time ever we’ll be able to create truly isolated components that can shrink and expand depending wherever you put them, like this:

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.)

📝 CSS-Tricks 284: New Year, New Color, Newsletter

[Robin]: Happy new year, folks! Chris wrote his annual thank you and end of year wrap-up which breaks down everything that’s happened on CSS-Tricks this year. I love starting the year reading these things, digging into the analytics, and learning about how the site is doing (considering that data often is hidden or never available on other similar websites).

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.

Issue 334

Happy New Year! CSS Paint API and prefers-color-scheme, empathetic animation, and column scroll animations.

 
CSS Layout News
Issue 334
By Rachel Andrew – 31 Dec 2021 – View online →
Welcome to your holiday season CSS Layout News. I’m having my first Christmas week vacation in many years. I did pop my head over the work parapet each morning to make sure Designcember was rolling out. You might enjoy these interviews with Miriam Suzanne and Lynn Fisher that were published over the break.

I have read a few things from the comfort of my sofa, and you’ll find those below.

Happy New Year!

Rachel Andrew

📝 CSS-Tricks 283: Happy Holidays!

[Robin]: Happy holidays, folks! This will be the last newsletter from us this year and so we just want to say thanks for reading. We covered so many topics in this newsletter over the last twelve months that I’m not even sure to begin. There was drama! New features in CSS! Weird hacks that I didn’t think were possible! Just keeping up with everything was tough, yet alone learning how to apply it in my day-to-day work. But writing this newsletter has definitely helped me figure things out and get a lay of the land when it comes to front-end development, so I hope it helped you, too.

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.

📝 CSS-Tricks 282: We shouldn’t treat accessibility like the cool new thing of the week

[Robin]: There’s a bit of drama in the accessibility world at the moment that’s worth taking a look at. It all hinges around a working draft of the WCAG 3. Here’s the gist: the Web Content Accessibility Guidelines (WCAG) are rules that tell us web developers how to make our websites accessible and it covers a ton of things, like how to use color in our interfaces:

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.

Issue 333

State of CSS Survey results, Compat 2021, Layout DevTools, and aspect-ratio.

 
CSS Layout News
Issue 333
By Rachel Andrew – 19 Dec 2021 – View online →
It feels like everyone is winding down towards the holidays, even so, there are a few useful things to share this week including the results from the State of CSS Survey. Thanks to those who mentioned me when responding to the survey, I’m happy if some of the things I do are useful to someone!

Rachel Andrew