Webmasters Gallery

Free e-book from Jens Oliver Meiert that’ll bore you to death in the best way: Rote Learning HTML & CSS

---

Quick Hit #11 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Killed by Google is called a “graveyard” but I also see it as a resume in experimentation.

---

Quick Hit #10 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Modern CSS keeps giving us a lot of new, easier ways to solve old problems, but often the new features we’re getting don’t only solve old problems, they open up new possibilities as well.

Container queries are one of those things that open up new possibilities, but because they look a lot like the old way of doing things with media queries, our first instinct is to use them in the same way, or at least a very similar way.

When we do that, though, we aren’t taking advantage of how “smart” container queries are when compared to media queries!

Because of how important media queries were for ushering in the era of responsive web design I don’t want to say anything mean about them… but media queries are dumb. Not dumb in terms of the concept, but dumb in that they don’t know very much. In fact, most people assume that they know more than they do.

Let’s use this simple example to illustrate what I mean:

html {
  font-size: 32px;
}

body {
  background: lightsalmon;
}

@media (min-width: 35rem) {
  body {
    background: lightseagreen;
  }
}

What would the viewport size be for the background color to change? If you said 1120px wide — which is the product of multiplying 35 by 32 for those who didn’t bother doing the math — you aren’t alone in that guess, but you’d also be wrong.

Remember when I said that media queries don’t know very much? There are only two things they do know:

• the size of the viewport, and
• the browser’s font size.

And when I say the browser’s font size, I don’t mean the root font size in your document, which is why 1120px in the above example was wrong.

The font size they look at is the initial font size coming from the browser before any values, including the user agent styles, are applied. By default, that’s 16px, though users can change that in their browser settings.

And yes, this is on purpose. The media query specification says:

Relative length units in media queries are based on the initial value, which means that units are never based on results of declarations.

This might seem like a strange decision, but if it didn’t work that way, what would happen if we did this:

html {
  font-size: 16px;
}

@media (min-width: 30rem) {
  html {
    font-size: 32px;
  }
}

If the media query looked at the root font-size (like most assume it does), you’d run into a loop when the viewport would get to 480px wide, where the font-size would go up in size, then back down over and over again.

Container queries are a lot smarter

While media queries have this limitation, and for good reason, container queries don’t have to worry about this type of problem and that opens up a lot of interesting possibilities!

For example, let’s say we have a grid that should be stacked at smaller sizes, but three columns at larger sizes. With media queries, we sort of have to magic number our way to the exact point where this should happen. Using a container query, we can determine the minimum size we want a column to be, and it’ll always work because we’re looking at the container size.

That means we don’t need a magic number for the breakpoint. If I want three columns with a minimum size of 300px, I know I can have three columns when the container is 900px wide. If I did that with a media query, it wouldn’t work, because when my viewport is 900px wide, my container is, more often than not, smaller than that.

But even better, we can use any unit we want as well, because container queries, unlike media queries, can look at the font size of the container itself.

To me, ch is perfect for this sort of thing. Using ch I can say “when I have enough room for each column to be a minimum of 30 characters wide, I want three columns.”

We can do the math ourselves here like this:

.grid-parent { container-type: inline-size; }

.grid {
  display: grid;
  gap: 1rem;

  @container (width > 90ch) {
    grid-template-columns: repeat(3, 1fr);
  }
}

And this does work pretty well, as you can see in this example.

As another bonus, thanks to Miriam Suzanne, I recently learned that you can include calc() inside media and container queries, so instead of doing the math yourself, you can include it like this: @container (width > calc(30ch * 3)) as you can see in this example:

A more practical use case

One of the annoying things about using container queries is having to have a defined container. A container cannot query itself, so we need an extra wrapper above the element we want to select with a container query. You can see in the examples above that I needed a container on the outside of my grid for this to work.

Even more annoying is when you want grid or flex children to change their layout depending on how much space they have, only to realize that this doesn’t really work if the parent is the container. Instead of having that grid or flex container be the defined container, we end up having to wrap each grid or flex item in a container like this:

<div class="grid">
  <div class="card-container">
    <div class="card">
  </div>
  <div class="card-container">
    <div class="card">
  </div>
  <div class="card-container">
    <div class="card">
  </div>
</div>

.card-container { container-type: inline-size; }

It’s not that bad in the grand scheme of things, but it is kind of annoying.

Except there are ways around this!

For example, if you’re using repeat(auto-fit, ...) you can use the main grid as the container!

.grid-auto-fit {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fit, minmax(min(30ch, 100%)), 1fr);
  container-type: inline-size;
}

Knowing that the minimum size of a column is 30ch, we can leverage that info to restyle individual grid items depending on how many columns we have:

/* 2 columns + gap */
@container (width > calc(30ch * 2 + 1rem)) { ... }

/* 3 columns + gaps */
@container (width > calc(30ch * 3 + 2rem)) { ... }

I’ve used this in this example to change the styles of the first child in my grid based on whether we have one, two, or three columns.

And while changing the background color of something is great for demos, we can, of course, do much more with this:

The downside to this approach

The only downside I’ve found using this approach is that we can’t use custom properties for the breakpoints, which would really improve the DX of this.

That should eventually change considering custom media queries are in the spec editor’s draft of the Media Queries Level 5 specifications, but its been in there for a while with no movement from any browsers, so it might be a long time before we can use them.

And while my opinion is that having custom properties for these would both make them more readable and easier to update, it opens up enough possibilities that it’s still worth it without them.

What about flexbox?

With flexbox, the flex items are what define the layout, so it’s a little strange in that the sizes we apply on the items are what are important in the breakpoints.

It can still work, but there is a big issue that can arise if you do this with flexbox. Before we look at the issue, here is a quick example of how we can get this working with flexbox:

.flex-container {
  display: flex;
  gap: 1rem;
  flex-wrap: wrap;

  container-type: inline-size;
}

.flex-container > * {
  /* full-width at small sizes */
  flex-basis: 100%;
  flex-grow: 1;

  /* when there is room for 3 columns including gap */
  @container (width > calc(200px * 3 + 2rem)) {
    flex-basis: calc(200px);
  }
}

In this case, I used px to show it works as well, but you could use any unit there, as I did with the grid examples.

This might look like something you can use a media query for as well — you can use the calc() in them too! — but this would only work in one if the parent has a width that matches the viewport width, which most of the time isn’t the case.

This breaks if the flex items have padding

A lot of people don’t realize it, but the flexbox algorithm doesn’t take padding or borders into account, even if you change your box-sizing. If you have padding on your flex items, you’ll basically have to magic number your way to getting it to work.

Here’s an example where I added some padding but I haven’t changed anything else, and you’ll notice one of those awkward two-columns with one stretched on the bottom layouts at one point:

Because of this, I do generally find myself using this type of approach more often with grid than flexbox, but there are definitely situations where it can still work.

Like before, because we’re aware of how many columns we have, we can leverage that to make more dynamic and interesting layouts depending on the space available for a given element, or elements.

Opening up some interesting possibilities

I’ve only started playing around with this type of thing, and I’ve found that it’s opened up some new possibilities that we never had with media queries, and that makes me excited to see what else is possible!

---

“Smart” Layouts With Container Queries originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

“This isn’t a website. Or even a blog. It’s a conversation.”

That’s the idea! Jay Hoffman and I’ve been chatting a long time now, back since he began writing a series on web history. It’s easy-going talking with someone with all that knowledge about the web’s interesting nooks and crannies.

Anyway, I always look forward to those chats. Sometimes, though, one of can’t make it for whatever reason. At the time, we’d been talking about different approaches to blogging and were particularly keen on the whole “digital garden” concept. We weren’t going to plant one or anything, but that inspired us to move our long-running conversation to a blog — you know, one of the best mediums ever in web history.

We didn’t want something linear in the sense that the blog is an archive of posts in chronological order. No, instead we wanted it to start as a seed that grows into a vine that twists and turns at different bends.

That’s where the “Dialogues” idea came in. It’s all Jay’s, really. He starts by asking me a question that I answer in the form of a post with a follow-up question that he, in turn, answers in a post with a follow-up question, and on and on.

The first question is already up there, and it’s a nice little ice breaker: What was the moment the web clicked for you? I had to take a few moments to let that one sink in and reflect on myself as a web user from 30 years ago. What a great little mind exercise and thing to talk about!

---

Dialogues Blog originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

You might recall that Alvaro suggests bumping up font-size to 1.25rem from the default user agent size of 16px. Sebastian Laube pokes at that:

I wouldn’t adopt Alvaro’s suggestion without further ado, as I would waste so much space on a smartphone, for example, and many users would probably be irritated by the large font.

I set a font size of 1.2rem from a certain viewport size. But this also has to be done carefully, because then grey areas arise in which media queries suddenly fall back into another area…

I personally agree with Alvaro that the default 16px size is too small. That’s just how I feel as someone who is uncomfortably close to wearing the bottoms of actual Coke bottles to see anything clearly on a screen.

On the flip side, I professionally agree with Sebastian, not that many users would probably be irritated by the large font, but to openly question an approach rather than adopting someone else’s approach wholesale based on a single blog post. It may very well be that a font-size bump is the right approach. Everything is relative, after all, and we ought to be listening to the people who use the thing we’re making for decisions like this.

The much bigger question is the one Sebastian poses right at the end there:

Should browsers perhaps use a larger font size on large screens from the outset if the user does not specify otherwise? Or do we need an information campaign to make them aware that they should check their system settings or set a different default font size in the browser?

Fantastic, right?! I’m honestly unsure where I’d draw the viewport breakpoint for 16px being either too large or small and where to start making adjustments. Is 16px the right default at any viewport size? Or perhaps user agents ought to consider a fluid type implementation that defines a default font scale and range of sizes instead? It’s great food for thought.

---

font-size Limbo originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Mental health is always tough to talk about, especially in an industry that, to me, often rewards ego over vulnerability. I still find it tough even after having written about my own chronic depression and exploring UX case studies about it.

But that’s exactly the sort of discussions that Schalk Venter and Schalk Neethling host on their Mental Health in Tech podcast. They invited me on the show and we got deep into what it’s like to do your best work when you’re not feeling your best. We got so deep into it that we didn’t realize two hours blew right by, and the interview was split into two parts, the second of which published today.

---

Mental Health in Tech Podcast Interview originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Heydon with a reminder that

isn’t for, you know, mailing addresses.

---

Quick Hit #9 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Welcome to our collection of sites to inspire you this month.

Ever search for CSS info and run into some article — perhaps even one or a dozen on this site — that looks promising until you realize it was published when dinosaurs roamed the planet? The information is good, but maybe isn’t the best reflection of modern best practices?

I’ve wondered that a bunch. And so has Chris. But so has Brecht De Ruyte and he’s actually doing something about it, along with other folks who make up the W3C CSS-Next community group. I worked with him on this article for Smashing Magazine and was stoked to see how much discussion, thought, and intention have gone into “versioning” CSS.

The idea? We’d “skip” CSS4, so to speak, slapping a CSS4 label on a lot of what’s released since CSS3:

CSS3 (~2009-2012):
Level 3 CSS specs as defined by the CSSWG. (immutable)

CSS4 (~2013-2018):
Essential features that were not part of CSS3 but are already a fundamental part of CSS..

From there?

CSS5 (~2019-2024):
Newer features whose adoption is steadily growing.

CSS6 (~2025+):
Early-stage features that are planned for future CSS

The most important part of the article, though, is that you (yes, you) can help the CSS-Next community group.

We also want you to participate. Anyone is welcome to join the CSS-Next group and we could certainly use help brainstorming ideas. There’s even an incubation group that conducts a biweekly hour-long session that takes place on Mondays at 8:00 a.m. Pacific Time (2:00 p.m. GMT).

---

It’s Time To Talk About “CSS5” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Christian Heilmann gave this talk at Typo3 Developer Days. I’m linking it up because it strikes an already stricken nerve in me. The increasing complexity of web development has an inverse relationship with the decreasing number of entry points for those getting into web development.

I love how Christian compares two hypothetical development stacks.

He’s definitely a bit glib, but the point is solid. Things are more complex today than they were, say, ten years ago. I remember struggling with Grunt back then and thinking I’d never get it right. I did eventually, and my IDE was never the same after that.

It’s easy to get swept up in the complexity, even for those with experience in the field:

This world is unfortunately becoming lost or, at least, degraded — not because it is no longer possible to view the source of a webpage, but because that source is often inscrutable, even on simple webpages.

— Pixel Envy “A View Source Web”

Christian’s post reminds me that the essence of the web is not only still alive but getting better every day:

• Browsers are constantly updated.
• The web standardisation process is much faster than it used to be.
• We don’t all need to build the next killer app. Many a framework promises scaling to infinity and only a few of us will ever need that.

He goes on to suggest many ways to remove complexity and abstractions from a project. My biggest takeaway is captured by a single headline:

The web is built on resilient technologies – we just don’t use them

Which recalls what Molly White said earlier this year that there’s always an opportunity to swing the pendulum back:

The thing is: none of this is gone. Nothing about the web has changed that prevents us from going back. If anything, it’s become a lot easier. We can return. Better, yet: we can restore the things we loved about the old web while incorporating the wonderful things that have emerged since, developing even better things as we go forward, and leaving behind some things from the early web days we all too often forget when we put on our rose-colored glasses.

We can return. We can restore all the things. So, tell me: do you take the red pill or the blue one?

To Shared Link — Permalink on CSS-Tricks

---

Christian Heilmann: Let’s make a simpler, more accessible web originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.