Chris’ Corner: Interesting CSS Explanations

Let’s do CSS stuff this week. Why not — kinda my thing.

Did you know Alvaro Montoro has a whole site of comics on the subject of CSS? There is a lot of satire in there, which I really enjoy.

So they changed CSS nesting a bit. I heard that the usage of it was low enough that it was under some threshold where the powers that be felt comfortable messing with a shipped platform feature like this. (I wonder what that threshold is??).

You probably won’t notice. It mostly has to do with how the parser rearranged rules and represents nested rules. If you put nested stuff at the bottom of blocks, like an orderly sane person, you’re cool. If you’re an agent of chaos that does stuff like:

.card {
  color: white;

  @media (width <= 500px) {
    background: pink;
  }

  background: green;

  &, header {
    padding: 1rem;
  }
}

Then god help you because that’s just weird and whatever you probabaly embrace the chaos anyway. (But really this is definitely an improvement in logical handling and I’m glad the CSS Working Group thinks about this stuff.)

See the interactive playground for a deeper (visual) explanation.

It’s been said for ages that you realllllly don’t need to worry about CSS selector performance. Just not an optimization that’s worth thinking about or working on except in ultra heavy DOM situations. Trys Mudford proves it once again.

Buried at the bottom of Michelle Barker’s Oh No, Overflow! is a demo of sidebar menu tooltips that “escape” the overflow. The idea is: you can’t escape the overflow very easily (except when you can), so don’t bother, just position the tooltips outside the overflow element and reveal them with clever :has() usage. The positioning is a bit buggy, but the soon-to-be-usable anchor positioning will make this entirely usable.

Miriam Suzanne’s dive into zooming is really great: Zoom, zoom, and zoom. You probably intuitively understand some of it and not so much other parts. For instance, when you Command – +, stuff, uhhhh, zooms. Text, and everything else on the page, gets bigger. But the viewport width stays the same, so the page re-lays out to accommodate the bigger stuff. This is quite useful as it’s good for reading and maintaining preference. Then there is pinch-zoom on trackpads, which behaves more like a real life magnifying glass where there is no re-layout, everything gets bigger including the viewport, which means immediately you’re getting horizontal scrolling (Miriam draws analogy to browsing microfiche lolz). This is quite different behavior, but it feels fine and expected and I’d think largely users get it and use both as needed.

But then there is zooming that can be done at the CSS level. We’ve got transform: scale() (just scale now if you’re cool) and well as the wildly unknown zoom property.

I don’t think I’ve ever paid much attention to the zoom property in 20-some years of writing CSS.

Same. I knew it was there but there never seems to be an appropriate time to use it, especially since it’s so similar to scale. But it is different!

If e.g. transform: scale(0.6) is used on the html or body element then it resizes the entire page, showing a minified page with huge white margins around it, whereas zoom: 0.6 scales the elements on the page, but not the page itself on which the elements are drawn.

This Pen shows the difference in behavior nicely.

Should we do * { min-width: 0; }? I get the idea. Without something allowing elements to be smaller than their intrinsic size, we get stuff like the occational grid blowout. e.g.

.grid {
  /* auto minimum width, causing problem */
  grid-template-columns: 1fr 300px;

  /* fix: minimum width of 0 */
  grid-template-columns: minmax(0, 1fr) 300px;
}

I’m used to doing that now, but we wouldn’t have to if the element had a min-width of 0 already (or inline-size if you’re cool). Kevin’s video gets into some situations where it’s not always what you want, so I’d hesitate from putting it in a reset.