Category: CSS Topics

Ahmad Shadeed recently wrote:

I like to think of CSS as a conditional design language.

It totally is! We tend to think of stuff like @media queries as the conditional part:

@media (max-width: 550px) {
  .grid {
    grid-template-columns: 1fr;
  }
}

That’s true, and new stuff like container and style queries are giving us more “conditional” stuff to work with. But it might be better to think of literally everything in CSS as conditional. Every selector you can write is conditional in some way. Just a sector like aside is conditional — it says, only style elements that match that selector. To grok CSS, you are grokking a massive set of conditions. As Ahmad indicated:

.alert p:empty {
  display: none;
}

This is a big logical if statement. IF the element is a paragraph. IF that paragraph is empty. IF it is a child of another element with a class of alert. All those IFs have to be true for the styles to apply.

You could take conditional CSS another step up though, meaning conditions by which to load the entire .css file at all.

Vadim Makeev wrote up some interesting experiments around all this. Say you do:

<link rel="stylesheet" href="style.css" media="print">

The browser is smart enough not to load that CSS file at all (unless you’re printing, natch).

You can also do this:

<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="mobile.css"
  media="(max-width: 767px)"
>

Butttttt, the browser will actually load both of those files regardless if the media matches or not. So no obvious immediate benefit, but that’s where Vadim’s research comes in. While all the files with non-matching media (queries) still load, the browser is smart enough to make the non-matching stylesheets load with a lower priority. At least in Chrome and Firefox — Safari has some bug that makes the priority levels not provide the perf benefits.

Pretty cool I think. Doing this kind of work by hand feels onerous though, I’d love to see build processes deal with it automatically.

Ya know I was scared for Mozilla & Firefox for a while. Those big layoffs in 2020 included many browser engine engineers and it seemed like it would be hard to continue to be a viable browser engine alternative without a strong team there. But I was essentially wrong. Since then they’ve shipped plenty of important web platform features at a decent pace, including the ever-important Container Queries and new color formats. Putting MDN on GitHub happened after the layoffs too and that seems like a massive thing to get shipped.

Last year WIRED asked Is Firefox OK? There wasn’t really an answer there, but some good information. We know Google provides the bulk of their income, but they showed really strong growth with their own products and services, saying 14% of all revenue was that back in 2021. They’ve clearly been trying new stuff to increase that, so things look on the right track to me.

I like to see little stories like this: Mozilla fixed an 18-year old CSS bug in the Firefox browser. So they aren’t just playing catch up, they are getting details right along the way too. Better late than never. This one was a weird bug with ::first-letter, the real ticket for doing drop caps:

They said it was kind of a bandaid for now but still cool. Speaking of drop caps though… ::first-letter was always fraught for this purpose. Much better would be to support initial-letter. C’mon Firefox, you can do it!

Michelle Barker on Resizing with CSS:

One drawback is the resize control is only positioned in the bottom right corner of the element, and it’s not possible to style it. It would be nice to have this customiseable ability, and increase the area of the resize control.

Yes!

That’s literally my opening thing in Things CSS Could Still Use Heading Into 2023. Just imagine the CodePen editors. So many things resize, and the ability to do that in HTML and CSS alone would be super sweet. But probably with JavaScript callbacks so we can do stuff like save/persist what has changed in the UI.

And ya know, that makes me think about how we only just got a scrollend event in JavaScript, maybe we should get a resizeend event too.

CSS hyphenation support is pretty good — just a -webkit- prefix left for Safari I’d love to see them yank off. Toss it on a parent, let it cascade, and you’ll see text hug the ragged edge a little closer and a little more consistently. You don’t have to use it, it’s a bit of an aesthetic choice.

I was thinking about this because I saw Hyphenopoly.js — a polyfill for hyphenation in JavaScript that’s come out in the last few months. I kinda don’t get it with the browser support being so good, but it does work in Node which might be interesting, and I suppose this would be extensible to written languages where hyphenation isn’t supported yet.

Update from Mathias Nater:

Hyphenopoly.js came out 2018 and its predecessor – Hyphenator.js –  around 2008, some time before hyphens:auto; was available.
There are still many languages that are not supported natively in all browsers.

Hyphenopoly.js supports 72 languages and, yep, it is extensible: we’ll just need hyphenation patterns (the same patterns TeX uses) or a huge list of pre-hyphenated words where I can compute the patterns from.

(I was under the impression it had just come out in the last few months!)

There is a ton more to the CSS art of controlling where words break through. One of the most comprehensive reads on the subject is Will Boyd’s Deep Dive into Text Wrapping and Word Breaking.

While we’re on type for a second, I do need you to know that Stabby exists:

More good news (in a sec). You know how the content of a page can shift around when a custom font loads after a fallback font has rendered? This is one of the great tradeoffs of display websites right now. Delay rendering until the custom font is ready means no layout shift (good!), but then you’re… delaying rendering (bad!). To my great surprise, the web has shifted toward not delaying rendering, largely thanks to CSS’ font-display: swap;

It is possible to have your cake and eat it too have non-shifting custom font loading without delayed rendering through CSS trickery. It involves using a font loader so that you know when the custom font loads and can adjust CSS to make sure none/little layout shift happens. The tricks were adjusting things like font-size, letter-spacing, and those classics.

The good news is that that old slightly hacky way of dealing with font fallbacks is out and a new school way of dealing with font fallbacks is in. Here’s Katie Hempenius’ recent article:

This article is a deep dive into font fallbacks and the size-adjust, ascent-override, descent-override, and line-gap-override APIs. These APIs make it possible to use local fonts to create fallback font faces that closely or exactly match the dimensions of a web font. This reduces or eliminates layout shifts caused by font swapping.

Improved font fallbacks

Four new things just for fallbacks! Wow. Say you’re loading a custom font called Poppins, it ends up looking like this:

body {
  font-family: Poppins, "fallback for poppins";
}

@font-face {
  font-family: "fallback for poppins";
  src: local("Times New Roman");
  ascent-override: 105%;
  descent-override: 35%;
  line-gap-override: 10%;
}

My brain immediately went uhmmmmm wouldn’t these metrics totally depend on the combination of the custom font and the fallback font? Apparently not though!

Because font metric overrides are calculated using measurements that come from the metadata of the web font (and not the fallback font), they stay the same regardless of which font is used as the fallback font.

That’s really great. So you can basically figure out (or look up) the overrides for your custom font, put them in place, and you’re straight up good to go. That’s a good API.

Welp I didn’t really intend for this whole issue to be about typography stuff, but here we are. You gotta see Adam Argyle’s Text Replace Transitions!

You could code any number of ways. But Adam did it using the new View Transitions API (so you’ll only be able to see the demo in Chrome Canary). It’s such a fun way to play with animating things because the API is so tidy: call document.startViewTransition, change the DOM, let it animate (control with CSS if you want). Hopefully, the CSS properties will be all that is needed entirely from cross-page View Transitions (I think that’s the case, I just haven’t seen it really work well yet).

Radial gradients do represent a bit of a leap up in complexity compared to linear gradients in CSS. With linear gradients, you sorta pick a direction and plop some stops on there. The default direction, to bottom, you don’t even have to include if that’s the direction you want, and two color stops with no additional values just mean “all the way at the top to all the way at the bottom”. Something like this linear-gradient(darkblue, blue).

Good news: radial gradients do maintain making most parameters optional, so radial-gradient(darkblue, blue) is still functional and half-decently-useful. But the complexity goes up from there.

• Radial gradients need to be told to behave like a circle if that’s the shape you want, not the default ellipse.
• You can tell a radial gradient where to stop, before you even get to the color stops.
• You can choose a starting position for the radial gradient, it doesn’t have to be dead center.
• There are keywords that tell radial gradients to extend to certain relevant points of the container, like closest-side and furthest-corner and such.

It was enough for Patrick Brosset to ask Do you really understand CSS radial-gradients?, which, ya know, fair.

There is no built-in way to generate a random number in CSS. Maybe there should be, as there are countless demos that use some other technology to feed random numbers into CSS. The use case is often generative art or decorative effects, but there is so much of that and the results can be so cool, it’s almost shame we don’t have it. So what do we do to get random numbers in CSS?

• We use the random function in a CSS processor (e.g. random() works in Sass) — but then it’s only random at build time.
• We use a random number created in JavaScript, then set a --custom-property with it. Maybe even Houdini.
• We use user input somehow to make a value feel random.

Kacper Kula’s Randomness in CSS kinda gets into all three of those. He uses a hand-built random number generator in Sass based on prime numbers. The @property syntax is used to ensure a custom property is an integer and is sometimes used as a seed that comes in via JavaScript.

Let me leave you this week with just a tiny classy snippet of CSS from CodyHouse:

.component {
  /* inner glow 👇 */
  box-shadow: 
    inset 0 0 0.5px 1px hsla(0, 0%, 100%, 0.075),

  /* shadow ring 👇 */
    0 0 0 1px hsla(0, 0%, 0%, 0.05),

  /* multiple soft shadows 👇 */
    0 0.3px 0.4px hsla(0, 0%, 0%, 0.02),
    0 0.9px 1.5px hsla(0, 0%, 0%, 0.045),
    0 3.5px 6px hsla(0, 0%, 0%, 0.09);
}

That’s just a nice look right there.

How about some accessibility quick hits!

It’s a bit hard to keep track of when using certain CSS value types is bad. For a while, using pixel (px) values in media queries was considered a bad practice as the breakpoints didn’t trigger as expected when a user zoomed in. But then that changed, and media queries do now, and using pixels for media queries isn’t really a bad practice any more.

But is using px still a bad practice in other cases? Yes, says Josh Collingsworth.

… when or if the user changes their preferred font size, if you’re using em and rem, all the text on your website will change accordingly, like it should. 2rem is still double that font size; 0.5rem is still half of it.

By contrast, px values are static. 20px is just 20px, regardless of the container’s, browser’s, or user’s font size. No matter how large or small the user’s font preference may be, when you set a value in static pixels, it clobbers that choice and overrides it with the exact value you specified.

Critically, that means if your stylesheet uses px to set font-size anywhere in it, any and all text based on that value will be impossible for the user to change.

Did you know that it was, up until fairly recently, specced that heading elements (e.g. <h1>, <h2>, etc) would “reset” inside of a new <section> (and similar) elements? I admit I thought that was kind of a neat idea. For example, if you’re building a site with HTML partials, and one of those as a little <aside> that I plunked into a sidebar or something, that I could have an isolated set of headings that would be valid and squoosh into the proper hierarchy going on on the rest of the page, without knowing or caring about headers scattered around the rest of the page.

Well, despite being specced, and despite general liking of that idea, no browser ever implemented it, and it was removed from the spec. Pour one out for the Document Outline Algorithm.

Doesn’t make me want to hold my breath for browsers implementing a tab order fixer-upper that follows the visual order of grid or flex items, like has been tossed around a bit.

Léonie Watson:

… you may be surprised to learn that there is no way for authors to design the aural presentation of web content, in the way they can design the visual presentation.

Why we need CSS Speech

All the major browsers now have “listening” features built right into them, and still no way to control that experience.

The good news is that there is a spec for CSS speech. Léonie thinks it’s too old and too big, so offered to take it on and trim it down (hopefully into something browsers will take on). Looks like that’s starting to happen based on the names on the spec.

This is a wild story: Safari’s date-picker is the cause of 1/3 of our customer support issues.

Shortly after I read it, I had to use this exact date picker a number of times while filling out online forms on an iPad at a doctor office and I friggin get it. Using that date picker for birthdays is horrible. Even knowing exactly how to do it, I tripped up several times in a row.

The danger of all this is companies, sometimes rightfully, going “screw it we’ll just build our own”, and having that home-grown picker perhaps solve this one UX issue, but cause accessibility issues that harm another group of people.

A smidge of good news. We can Use the dialog element (reasonably) says Scott O’Hara. There have been some recent updates that solve some the focus handling issues that apparently gave it a red flag before. I’m glad about this, as I think it suffers from exactly what I described above: people build dialogs in-house instead and get some (if not most) of the accessibility requirements wrong. Focus-trapping alone is brutally difficult to get right, and it’s just a freebie with <dialog>.

Web hosting is a service that allows individuals and organizations to make their websites accessible on the internet. When you create a website, you need a place to store all of your website's files, such as HTML, CSS, and images. Web hosting companies provide servers, which are powerful computers that are connected to the internet, where you can store and run your website's files.

When you sign up for a web hosting service, you are essentially renting space on a server to host your website. Depending on the type of web hosting plan you choose, you may have access to a range of features and resources, including disk space, bandwidth, email accounts, and databases.