236: Initialisms and Layout Shifts - CSS-Tricks

[Robin]: “Unnecessary initialisms are exclusionary,” writes Jeremy Keith in this particularly excellent blog post about performance, web design, and how initials for terms such as CLS make thing much more difficult for everyone to understand:

I feel sorry for anyone trying to get into the field of web performance. Not only are there complex browser behaviors to understand, there’s also a veritable alphabet soup of initialisms to memorize. Here’s a really good post on web performance by Harry, but notice how the initialisms multiply like tribbles as the post progresses until we’re talking about using CWV metrics like LCP, FID, and CLS—alongside TTFB and SI—to look at PLPs, PDPs, and SRPs. And fair play to Harry; he expands each initialism the first time he introduces it.
But are we really saving any time by saying FID instead of first input delay? I suspect that the only reason why the word “cumulative” precedes “layout shift” is just to make it into the three-letter initialism CLS.

I think initialisms make things easier for the writer to type out but makes things way more difficult for readers. And I hadn’t really thought about this until the other day when I tried to remember what the Core Web Vital CLS and FID stood for. And yet I’ve probably read somewhere in the region of ten billion blog posts about this stuff.

Cumulative Layout Shift and First Input Delay. Ugh.

Lately, I’ve also noticed how UIs are starting to throw these web perf metrics around the place with initialisms alone and with no further explanation. This is sort of funny since ideally, the point of web performance is access: making sure that everyone can view a website without unnecessary blockers.

This isn’t just about performance though; initialisms creep into our work from all sorts of directions. And I think that, like Jeremy, from here on out I’m going to be a bit of a jerk about things and push folks to stop speaking in riddles. Because if we really care about performance and making sure the web is for everyone then we need to ensure the words we use to describe our work aren’t masked in complexity, too.

How to avoid layout shifts caused by web fonts

Speaking of layout shifts, earlier this month Simon Hearne created this comprehensive (read: extremely impressive) guide to layout shifts and webfonts. This can be annoying as you navigate to a new website and all the text shifts about once the fancy webfont loads. (One possibility on fixing it is one of the great CSS tricks: perfect font fallbacks.)

Simon writes about this particularly neat trick though:

The dirty little secret of this blog post is that you can resolve layout shifts due to fonts with a single line of CSS:

font-display: optional

This directive lives in your font-face declaration and tells the browser to use a fallback system font if the web font is not available at the time of rendering text (plus 100ms). This means that on uncached page loads there is a chance that the fallback font will be used, but all subsequent page loads should be rendered with the web font, as it will be downloaded and available in cache.

Huh. I was completely unaware of this which is embarrassing because at work people call me Fonts. But regardless, the way you’d use it is like this as you declare the font in your stylesheet:

@font-face {
  font-family: 'Roboto';
  src: url('Roboto.woff');
  font-weight: 300;
  font-style: normal;
  font-display: optional;
}

I think I’m going to explore using this for personal projects for a while. I wonder if the experience of loading up a webpage and seeing the default—then going to the next page with a custom font—is a wonky experience though. To the blog!

Beware of stacking contexts

Earlier this week I was working on a table where if you hovered over a bit of data in a row then more information would be shown in a popover. What I wanted to do was make some rows semi-transparent with the following CSS:

.row--state-change {
  opacity: 0;
}

The problem is that I forgot that changing the opacity of an element also changes its stacking context. What this meant is that once you hovered hover a bit of information in a row then the tooltip would be hidden by the next row in the table. Agh!

Thankfully I discovered this great post by Praseetha KR all about how opacity changes stacking context. There’s a tiny error in the example there on the site but I’ve corrected it in this illustration here:

In short: changing opacity will throw some elements behind others and it’s a good reminder that this is how CSS is supposed to work.

The Holy Grail Layout with CSS Grid

This is one of those blog posts about CSS Grid where you sit back and sort of gasp at how janky the web used to be and far we’ve come. A reader writes in to ask how to make the following layout with Flexbox…

…but Chris argues that we should use CSS Grid for this sort of layout because it was designed to do just that:

See, kids, layout on the web used to be so janky that the incredible simple diagram above was relatively difficult to pull off, particularly if you needed the “columns” there to match heights. I know, ridiculous, but that was the deal. We used super weird hacks to get it done (like huge negative margins paired with positive padding), which evolved over time to cleaner tricks (like background images that mimicked columns). Techniques that did manage to pull it off referred to it as the holy grail. (Just for extra clarity, usually, holy grail meant a three-column layout with content in the middle, but the main point was equal height columns).
CSS is much more robust now, so we can use it without resorting to hacks to do reasonable things, like accomplish this basic layout.

If you’re ever wondering when to use Flexbox or when to reach for CSS Grid then here’s how I tend to remember it:

Flexbox: left/right OR up/down layouts
CSS Grid: left/right AND up/down layouts

In the example above we want to create rows (header, main content area, and footer) and also columns within that main content area(aside/nav+article). That means we ought to pick CSS grid if we don’t want to do some particularly bonkers stuff with flexbox.

[Chris]: While I think the single-direction vs. multi-direction distinction largely works for flexbox vs. grid, it doesn’t account for the value of single-direction CSS grid usefulness. I find that most of my work with CSS grid is just setting up some columns (single direction) and letting things fall into them. So I prefer the distinction:

Flexbox: The elements themselves impact the layout
Grid: I need to impose specific sizing

I think of a navigation bar in how the elements along it are all of variable width, and we use flexbox because we want to appart some alignment and spacing. But as soon as we’re starting to force the widths of those elements for any reason, it’s likely it should become a grid. It’s not a perfect system, because there is overlap in concepts like flex-grow and 1fr and it doesn’t mean you can force widths in flexbox as well. But think of how forcing widths works in flexbox: you’re applying things like width and/or flex-basis directly to elements that are flex children. In a grid, you’re making a grid cell of that size and placing the item within that cell. It just hits different. It’s almost like:

Flexbox: Inside, Out
Grid: Outside, In

That’s not perfect either. The right answer, probably, is learning them both so you have a strong mental model of what they can do, and picking based on what you need to do. The article we linked up the other day, Bulletproof flag components, is a great example of thinking through a layout situation and using the possibility to grid layout to get something done.

Re-Creating the Porky Pig Animation from Looney Tunes in CSS

Kilian Valkhof describes his buck wild journey here: from experimenting with perspective with simple rectangles and shapes like this with a single div…

…to recreating the Porky Pig animation from Looney Tunes:

I haven’t played around with CSS and perspective at all yet so this is a wonderful bit of inspiration and kick in the butt to go play with all this stuff. It’s sort of bonkers that this animation is just a single div.

But! One tiny point that stood out to me in this post was this bit of CSS:

div::before {
  background: url("Porky_Pig.svg") no-repeat center/contain;
}

…excuse me? What on earth is that center/contain bit? I’ve never seen that before—but:

You might have noticed that slash in “center/contain” for the background. That’s the syntax to set both the position (center) and size (contain) in the background shorthand CSS property. The slash syntax is also used in the font shorthand CSS property where it’s used to set the font-size and line-height like so: <font-size>/<line-height>.

Huh. Neato.

Text filling effect in CSS

This tweet by CodyHouse stood out to me the other day. It shows how to take a bunch of text in an element and then like this…

.element {
  -wekit-text-fill-color: transparent;
  -webkit-text-stroke: thin red;
}

.element {
  -wekit-text-fill-color: red;
}

…you can make neon-esque letters where the fill of that text is replaced by simple lines:

I wonder why I haven’t seen more experiments like this because it’s pretty striking and visually interesting.

CSS Floating Disk

Another tweet, this time by Amit Sheen, caught my eye, too. He linked to a pen where he built a floating disk which ever so slowly rotates in an enormous dark void:

Beware this demo though because it is bad for performance (and yet excellent for the eyes).

Raygun Real User Monitoring

Real User Monitoring helps you to take back control of your front-end performance. See user experience metrics and measure trends in application performance so you can build great experiences for your customers. Learn more in this article.

Use Jetpack Backup to Restore Your WooCommerce Store

Say you update WooCommerce on your WordPress site and — blammo! — you get the white screen of death. That’s no problem with Jetpack Backup! Roll your site back to a point before the update and — phew! — everything is back to normal. It even makes sure any orders that happened after the rollback point are still in place, without duplicating or overwriting anything. That peace of mind is well worth the $9.99/mo. price tag.

Get JetPack Backup

Psst… Automattic is hiring! If you’ve been hunting for a new job, there are tons of openings and one of them might just have your name written all over it. Check them out!

[Chris]: Reading Robin (and Jeremey’s) rant above on initialisms, it makes me think about where we draw the line. HTML and CSS are acronyms too, but we don’t stop to define them as they are widely understood. More on the fence is something like “a11y” meaning accessibility. I’ve admitted that it took me far too long to understand what people were talking about when they used that numeronym, but Eric Bailey made a stronger point, and I think he’s right: “The genie is out of the bottle. The ship has sailed. The egg is scrambled.” Poking at the term a11y is gatekeeeping at a minimum. So then what do we do with brand new terms like CLS (Cumulative Layout Shift)? Perhaps just what I’ve done there, which is what we should do with any initialism where we have any doubt that the reader would understand it: use both the initialism and spell it out. And apply good taste! Don’t overdo it.

In other news, I enjoyed Brandon Smith’s take on Michael Pollan’s famous quote: Write code. Not too much. Mostly functions.

At the risk of stretching the analogy, maybe the equivalent is “code only those things that people at a junior level would recognize for what they do”. Code in simple, straightforward terms. Don’t get too clever.