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

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

Making a CSS-only Clock

Smart stuff from Mate Marschalko where he tries to torture himself by making a clock that works without any JavaScript whatsoever. There’s a lot of interesting notes in here—from how he placed the hands of the clock and then animated them to make a digital clock afterward, too.

Meta Theme Color

Manuel Matuzovic has been experimenting with the theme-color meta tag that you can place in the <head> of your website like this…

<meta name="theme-color" content="#319197">

…and many browsers and platforms will take that color and apply it to the UI of the browser window. Safari is the latest to do so with there rather controversial design that set the front-end world on fire recently:

This is all neat and very much worth experimenting with. But another interesting note that Manuel points to is how Safari 15 is the first browser to support these new color functions:

body {
  background-color: hwb(27 10% 28%);
  background-color: lch(67.5345% 42.5 258.2);
  background-color: lab(62.2345% -34.9638 47.7721);
}

I haven’t read anything about hwb, lch, or lab, and after taking a look at MDN and scanning the super information highway for more information, I’m a little uncertain as to what the benefits of these new color functions have over the ol’ regular rgba or the ever-so-useful hsl. Be sure to check in next week once I finish figuring that out.

A Bashful Button Worth $8 Million

I really enjoyed this piece from Jason Grigsby where he talks about the cost of having a single button malfunction on a website. Jason walks through the accessibility problems, how to fix them, and then gives us this great takeaway:

Let’s focus on what we can learn from these sites:
• 100vh does not necessarily work as you expect it in every context
• There is no substitute for testing on real devices

I love well-researched rants like this and I wish I could read more pieces about websites in this way.

Better Target Sizes

This is a rather good reminder by Todd Libby that we should take care of the target sizes of links and buttons:

Mice and similar input devices use a pointer on the screen, which is considered “fine” precision because it allows a user to access an element on the screen with exact precision. Fine precision makes it easier to access smaller target sizes in theory. The trouble is, that sort of input device can be tough for some users, whether it’s with gripping the device, or some other cognitive or motor skill. So, even with fine precision, having a clear target is still a benefit.

I always notice whenever I hit the wrong button on my phone and each time I do it reminds me that we should make our interfaces as forgiving as possible.

`hyphenate-limit-chars`

This is an interesting CSS property I’ve never seen before:

.element {
  hyphens: auto;
  hyphenate-limit-chars: 10 3 4;
}

This is from an almanac post by Idorenyin Udoh where he explains how this is another CSS property that we can’t use today because it’s a draft proposal but, heck yes, I love the sound of this:

In the CSS rule above, the last declaration indicates to the browser that it should hyphenate only words of 10 characters or more and, when it does, three is the minimum number of characters before the hyphen and four is the minimum after the hyphen.

Controlling hyphenation on the web has always been a major pain in the peach emoji and so anything that makes this experience even slightly better is a-okay with me. Even if we might have to wait a rather long time for it to land in browsers.

The `:fullscreen` CSS pseudo-class

Huh! This is yet another extremely neat CSS property I’d never heard of before: the :fullscreen pseudo-class, as Mojtaba Seyedi explains:

The :fullscreen CSS pseudo-class allows you to select and style any element that is currently in fullscreen mode. You know those times you allow an image or some other element to take up the full screen? Well, we can style elements when they’re in that state and that’s what :fullscreen lets us do.

You can use it like this:

section:fullscreen {
  background: #eee;
}

And this ties into the FullScreen API that I’d never heard of before either. I am learning so many things today! Please make it stop!

3 Successful customer-centric monitoring strategies

Customers are why we make software, and understanding who they are and how they interact with your application is crucial to the success of your business. Follow these 3 monitoring strategies to ensure users are having flawless digital experiences.

WooCommerce is the premier eCommerce plugin for WordPress. MailPoet brings a fancy email builder right into WordPress. Combine the two and you get a powerful way to engage your customers. For one thing, you get extra powerful eCommerce email abilities — things like abandoned cart emails. Better, you can combine them to make a paid subscription newsletter, but powered by your own site!

Learn about MailPoet

[Chris]: As a terrible offender in introducing scope creep to projects, I appreciate this gentle push the other direction from Tim Daub:

I don’t think, however, that scope creep is ever unjustified. Every scope creeper has a reason for creeping. It may be that their proposal is flawed and unnecessarily blown up. But ultimately, assuming that all contributors are good-natured towards the project, I’ve made the experience that a scope creeper (a person that blows up scope) is looking at the problem from a unique point of view and is seeing something others aren’t.