Issue 312

Scroll-linked animations, getting rid of layout grids, colors, and lazy-loading.

CSS Layout News
Issue 312
By Rachel Andrew – 21 Jul 2021 – View online →
I’m a little late in publishing this week, mostly due to the fact the UK has a heatwave, and we are very much not set up for heatwaves. By mid-afternoon my office has turned into a sauna, making productivity something of a challenge. It looks as if it will be grey and raining again by the weekend though.

I have managed to find some interesting things this week, and so here they are.

Rachel Andrew

📝 CSS-Tricks 260: The Maybe Future Magic of CSS Query Units

View this newsletter on the web.

[Robin]: Have you ever heard of CSS query units? They aren’t a thing in CSS just yet, but let me set the stage to explain exactly how they would be useful. I only stumbled across the idea because I bumped into an interesting problem when it comes to setting type on the web.

I was messing around with the fonts on a project and realized that there are a lot of ways to set the font-size of an element:

.element { font-size: 16px; } .element { font-size: 1em; } .element { font-size: 10vw; } .element { font-size: 10ch; } .element { font-size: 2pt; } .element { font-size: 60ex; }

These are collectively known as the lengths of CSS but they all fall short in an important way because sometimes when I’m setting the font-size of an element—especially when it comes to headings—I’d like to set the font-size based on the width of the parent element.

The examples I’ve seen for container queries, although not in browsers yet, could partially help solve this problem. Let’s say we have some HTML such as this…

<div class="container"> <h1>Title</h1> </div>

In the future, we’ll be able to write the following CSS…

.container { contain: layout inline-size; } @container (width > 40em) { h1 { font-size: 1.5em; } }

This CSS allows us to set the font-size of the <h1> when the container itself reaches a certain width breakpoint. However! Even though I would be thrilled if we got container queries tomorrow, this doesn’t quite solve my problem.

Let’s say I want this headline on the left to only change its font-size based on the width of the div that wraps it (that gray box):

Today we’d have to use something like Fittext.js to detect when the parent element changes size and then jump in and change the font-size of that text.

Sure, we could use a variable unit like this…

h1 { font-size: 20vw; }

…but that will make the heading keep scaling up and up if the width of the browser window increases. Alternatively, we could use the ever-so-good clamp() CSS function and set a min, ideal, and max font-size on the text:

h1 { font-size: clamp(1rem, -0.875rem + 8.333vw, 3.5rem); }

This is very smart and worth keeping in our back pocket but it still doesn’t do quite what I’d like to do. I just want the text to scale up in relation to the parent element.

And this is where CSS query units like qh and qw come in. Although only in a draft spec right now and not any browsers, at some point in the future, we might be able to write CSS like this:

/* All this is likely to change, but the spirit is here. */ div { contain: layout inline-size; } @container (width > 20em) { h1 { font-size: calc(30qw); } }

This will change the size of the <h1> to scale in proportion to the width of that <div> above. Perfect! This is exactly what I was thinking of. And I think the reason I’m so excited about this is that it is a relatively simple thing in print but, today on the web, it’s way, way harder than it needs to be.

I know I’ve only touched on font-size here but I can imagine all sorts of other purposes for scaling an element with qh, qw, or the other units that are available. And perhaps these units never land in browsers, but regardless—it’s truly exciting stuff, in this humble blogger’s opinion, and it solves a real problem that I have with CSS today.

Issue 311

An explanation of the difference between some very similar sounding alignment values. Also: Firefox 90, Intersection Observer, viewports, and theme-color.

CSS Layout News
Issue 311
By Rachel Andrew – 14 Jul 2021 – View online →
My intention with this new CSS Layout News site was to start to collect together a lot of the material I’ve written on layout, along with publishing some new pieces. I’ve made a start today with a piece about some alignment values you may not have come across yet.

Let me know if there is some layout mystery you’d like me to explain! I’ve been doing a lot of editing and API documentation recently, so I’m itching to get back to writing about CSS layout.

Rachel Andrew

📝 CSS-Tricks 259: How to use variable fonts

View this newsletter on the web.

I have a terrible confession to make. Send me to jail and lock away the key because, despite how much I rant about variable fonts, I’ve never really used them. I’ve read tutorials and demos and I love seeing what’s possible with this new font format, but I’ve never used any of them in a website of my own.

So this weekend I wanted to fix that. I started looking around for variable fonts to play with and, well, did you know that test fonts are a thing? A lot of type foundries will offer fonts that are free to download and play around with in your local environments before you buy them. They’re super handy and that’s just what I did the other day.

First, I headed over to David Jonathan Ross’s website where I discovered the ever-so-good Job Clarendon that he designed alongside Bethany Heck:

Welp! Also, Job Clarendon has a great variable font version available and you can download it for free (so long as you’re being a cool chap and only using it on your computer).

So, first things first: how do we load Job Clarendon as a variable font and make it accessible from our CSS? The first thing to note is that we have to support both the new syntax and the old syntax for variable fonts:

@font-face { font-family: "JobClarendon"; src: url("job-clarendon.woff2") format("woff2 supports variations"), url("job-clarendon.woff2") format("woff2-variations"); font-weight: 100 1000; }

We’re pointing to the same variable font file here (which note is a regular ol’ .woff2 file) but we have to tell the browser that it supports “variations.” woff2 supports variations is the future syntax for telling the browser it’s a variable font and woff2-variations is the deprecated way.

You see that weird part underneath where we’ve said font-weight: 100 1000? That’s not a mistake, we’re telling the browser that this font supports a range of font-weights from the light weight 100, all the way up to the heaviest weight of 1000.

We can then use our variable font just like we can any other, but whilst I was working on adding these demo font, I realized that I could use CSS custom properties to set the fallback font if for whatever reason this one can’t load:

:root { --font-fallback: BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-sans; } h1, h2 { font-family: "JobClarendon", var(--font-fallback); }

Now that’s pretty handy. I could even set different fallbacks for my display and body text font. From here we can then set an element to use one of those ranges between 100 and 1000:

h1 { font-weight: 600; } h2 { font-weight: 250; }

Right now it looks like there are five “common axes” that fonts let us change variably. So that’s stuff like font-weight and font-stretch which lets you make letters more or less condensed. This all depends on what the specific font supports though, so make sure you know what features the font has before you buy it (this is why test fonts rule).

Another place to check out is Variable Fonts, which I know I’ve mentioned in every human conversation I’ve had the past year, but still, it’s a great place to find cool new variable fonts.

With variable fonts, we can do wild things with animations. So now that I can change any font-weight between 100 and 1000, I can also animate between those properties, too. Why is that a good idea? Well, most of the time it’s probably not a good idea. But you could set really big and beautiful headlines like this:

@keyframes scale { 0% { font-weight: 100; } 100% { font-weight: 1000; } } .element { font-size: 15vw; animation: 4s ease-out scale alternate infinite; }

That said, I don’t think animations are what that excite me most about variable fonts. Instead, the most exciting thing about variable fonts is the ability to making really small changes to text because, the more you look at type on the web, the more you realize it’s either way too thin or way too bold.

But now with variable fonts we can get it just right.

Issue 310

This week in CSS Layout News grab your copy and paste counter styles, see what’s coming to Safari, learn about the world of RTL text.

CSS Layout News
Issue 310
By Rachel Andrew – 06 Jul 2021 – View online →
Despite the fact that last week seemed to have at least 426 days, it is once again Tuesday. This week I’ve got a fairly eclectic collection of layout adjacent things, covering accessibility, internationalization, improvements in browsers, plus a proposal for a new CSS feature.

Rachel Andrew

📝 CSS-Tricks 258: Good Meetings, System Colors, and Upcoming CSS Pseudo Elements

View this newsletter on the web.

[Robin]: I’ve been in my fair share of meetings over the years; those that were unfocused and a bit rambling, those that were unclear about why they even needed to be meetings in the first place, or heck meetings that ended up being just plain weird. I would often leave those meetings and wonder why they felt so peculiar. Did I eff up by not writing an agenda? Was I a little unclear at the end about what everyone’s expectations were?

Meetings are important for us front-end developers and there are so many ways a meeting can go sideways that it’s worth sitting down and asking ourselves how we can improve them. So! Thankfully Sarah Drasner wrote about how to have good meetings and gosh darn is it a very good post:

It may at times feel like meetings are a drag on a software engineering process, but it doesn’t always have to feel this way. There’s something special about collaborating with a group of people who are respectful and working towards a common purpose. Good meetings can provide clarity and save people hours and days of work when they’re headed in the wrong direction. Having clear ownership, documentation, and only the right people in the room can keep many teams in lockstep, even when problems are complex.

The whole post is great because it digs into what a bad and good meeting is, but Sarah also explains how adding process to your meetings might actually make them worse in the long run:

Sometimes people use an agenda to write thoughts down before the meeting, and I would strongly suggest you steer clear of this—there’s nothing wrong with a person keeping notes for themselves for the meeting but if you come to a meeting where an agenda is locked top to bottom with material, it can sometimes shut down the collaborative aspect of the meeting—which means it shouldn’t be a meeting at all, it should just be a shared doc, to be consumed async. Part of the purpose of the meeting is the discussion itself.

Gah! That’s such an important note: meetings shouldn’t be the place where you give information to someone, but space where you can discuss the ideas and brainstorm solutions.

The best part of all this is that these notes are just a tiny bit from Sarah’s latest book called Engineering Management for the Rest of Us. And although I’m not an engineering manager (and let us all hope I never will be), I think there’s going to be so much to learn here about communication skills that I’ve found lacking in my own career.

So I couldn’t be more excited about this beautiful thing. Make sure to sign up on the website and get notified when it’s out.

Issue 309

TPAC diversity and inclusion, CSS Paint API, image-set(), and the communities of the web past.

CSS Layout News
Issue 309
By Rachel Andrew – 29 Jun 2021 – View online →
Tuesday seem to come around very quickly at the moment, and with them another issue of CSS Layout News. This week you can watch the presentation that I gave online for Frontend RheinMain. I’d love to schedule in some more talks. I’ll be happy to travel once it’s allowed, and less likely to end up with me spending 10 days in a quarantine hotel, but until then I’m really happy to do online presentations.

Rachel Andrew

📝 CSS-Tricks 257: The One About Images

View this newsletter on the web.

[Robin]: When it comes to web development I feel like images have been in a state of constant flux over the past few years. What’s the best way to add an image to a website? Well, that question is much more complex than it looks at first and, depending on the month, it seems like there’s new advice from every direction. This is partly a good thing because there’s been an awful lot of improvements made in this space.

For example, did you know about the image-set() CSS function? Me neither! According to this great post by Ollie Williams, it’s been supported in Chromium since 2012(!) and it just landed in Firefox 88. It allows us to load different images in CSS depending on screen resolution:

.element { background-image: image-set("platypus.png" 1x, "platypus-2x.png" 2x); }

This might look familiar to you if you’ve ever used the HTML srcset attribute that looks something like this:

<img alt="A baby smiling with a yellow headband." src="baby-lowres.jpg" srcset="baby-highres.jpg 2x" >

The browser will look at that 2x part and if it’s a higher pixel density display it will load that one instead of the low-res image. But let’s say you wanted to use a next-gen image format that isn’t supported in a lot of browsers right now, such as AVIF. You could then write something like this first:

.element { background-image: url('kitten.png'); }

This is the fallback image you want to use for browsers that don’t support image-set but then you can add to that code like this…

.element { background-image: url('kitten.png'); background-image: image-set( "kitten.avif" type("image/avif"), "kitten.jpg" type("image/jpeg") ); }

image-set lets you add a series of images that you want to load depending on the device. The first image here is the next-gen image format but if a browser doesn’t recognize it, then cool — it’ll ignore it and use the jpeg. Just like srcset allows you to do as well.

This is pretty dang amazing, especially as there are new image formats looming on the horizon like AVIF (which is a format already supported in Chrome and Android browsers).

Speaking of serving sharp images, Jake Archibald just wrote all about that. He writes about how to cater for low-res and high-res screens in a lazy way and also the most intense way imaginable by using the <picture> element. Here’s what Jake calls the lazy way:

Here’s the technique I use for most images on this blog: I take the maximum size the image can be displayed in CSS pixels, and I multiply that by two, and I encode it at a lower quality, as it’ll always be displayed at a 2x density or greater. Yep. That’s it.

That’s been my approach with most projects, too. But also dang is it great to know that the AVIF example Jake shows is about 37% the size of a regular ol’ JPEG.

Issue 308

Information as more of the new rendering engine for Chromium lands. Explaining interesting CSS Grid examples, CSS masking, and serving sharp images.

CSS Layout News
Issue 308
By Rachel Andrew – 23 Jun 2021 – View online →

lots of browser-related stuff today from the Chrome team. The two posts I’ve included about TablesNG and RenderingNG are a really accessible look into the improvements being shipped.

I’m not a browser engineer, but one of the great benefits of being part of the CSSWG has been to listen to browser engineers explaining why something is difficult to implement. Many of the annoying inconsistencies, or the lack of support of some obviously useful feature, come down to them just being incredibly hard to fix or implement. Big projects such as RenderingNG may appear to slow progress for a while, as things get held up waiting for the big change to ship. Now it is all landing I think we are going to see a whole bunch of really annoying things fixed. Also, these changes allow future work on features we all want to see (such as Container Queries) to happen.

Do give these pieces a read, if nothing else I have found that an appreciation of this stuff makes the web platform somewhat less frustrating.

Rachel Andrew

📝 CSS-Tricks 256: When to use @container queries

View this newsletter on the web.

[Robin]: Max Böck asks when should we use @container or @media queries?

While I think container queries will eventually replace most “low level” responsive logic, there are still a lot of good usecases for trusty media queries.

A combination of both techniques will probably be the best way forward. @media can handle the big picture stuff, user preferences and global styles; @container will take care of all the micro-adjustments in the components themselves.

Once @container queries get support in browsers and it becomes a part of our daily work, I can see how this question might be confusing for folks getting started in web development. Heck, I can see it being confusing for me! And yet, although Max makes a lot of great points in that piece, I think the quickest explanation between the two could be this:

@media queries are for page layout and @container queries are for components.

That’s a little simplistic but when it comes to component design (like a navigation or a button) you likely want that component to be aware of its environment and the width or height of its parent. Let’s say you want to throw that dropdown component into the sidebar, or grab that button group and put it into a bigger space than it was initially designed for. Those are the moments when @container queries will absolutely shine.

Layouts are a bit different because we don’t often want to nest layouts. If you have a 12-column grid, it’s unlikely you’ll want to nest that grid within another grid component—instead, you’d want the elements to inherit the grid. And that’s precisely what subgrid is for:

See how nested elements above (like the gray rectangle) is aligned to the grid gap of the outer container? That’s good ol’ subgrid and that means we can mostly avoid nesting grid elements within grid elements.

Anyway, I reckon in almost all instances when we’re designing a component we’ll want to use @container. But, saying that, I really hope @media queries aren’t treated later like the <table> element is today, where a ton of people are somehow under the impression that they are bad practice just because they were the best option to lay things out at the time.

Even though @container is on the horizon and it will be fancy new tool under our belt, @media still has its place and is still useful and relevant in layout and design.