Author: Chris Coyier

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

We’ve zoomed right into 2023, so let’s keep up the pace and talk about making the web speedy.

– Chris Coyier, proffessional newsletter writer.

Uhm but anyway I do have some choice web performance links I’ve been saving up for you this week though.

Turns out HTML is good.

Perhaps my favorite performance-related post of 2022 was Scott Jehl’s Will Serving Real HTML Content Make A Website Faster? Let’s Experiment!. It makes logical sense that a website that serves all the HTML it needs to render upfront will load faster than a website that loads an HTML shell, then loads JavaScript, and the JavaScript makes subsequent requests for the data, which is turned into HTML and then rendered. But it’s nice to see it completely apples to apples. Scott took websites that serve no “useful HTML” up front, and used a new feature of WebPageTest called Opportunities & Experiments to re-run a performance test, but with manipulations in place (namely “useful HTML” instead of the shell HTML).

The result is just a massive improvement in how fast the useful content renders. Server-side rendering (SSR) is just… better.

As always, Scott has a classy caveat:

Now, it’s very important to note that while the examples in this post helpfully display this pattern, the architectural decisions of these sites are made thoughtfully by highly-skilled teams. Web development involves tradeoffs, and in some cases a team may deem the initial performance impact of JS-dependence a worthy compromise for benefits they get in other areas, such as personalized content, server costs and simplicity, and even performance in long-lived sessions. But tradeoffs aside, it’s reasonable to suspect that if these sites were able to deliver meaningful HTML up-front, a browser would be able render initial content sooner and their users would see improvements as a result.

I suspect it’ll be rarer and rarer to see sites that are 100% client rendered. The best developer tooling we have includes SSR these days, so let’s use it.

Fortunately, there are all kinds of tools that point us in this direction anyway. Heavyweights like Next.js, which helps developers build sites in React, is SSR by default. That’s huge. And you can still fetch data with their getServerSideProps concept, retaining the dynamic nature of client-side rendering. Newer tech like Astro is all-in on producing HTML from JavaScript frameworks while helping you do all the dynamic things you’d want, either by running the dynamic stuff server-side or delaying client-side JavaScript until needed.

So if your brain goes well my app needs to make API requests in order to render, well now you have your answer. There are all kinds of tools to help you do those API requests server side. Myself, I’m a fan of making edge servers do those requests for you. Any request the client can do, any other server can do too, only almost certainly faster. And if that allows you to dunk the HTML in the first response, you should.

It’s all about putting yourself in that HTML-First Mental Model, as Noam Rosenthal says. Letting tools do that is a great start, but, brace yourself, not using JavaScript at all is the best possible option. I really like the example Noam puts in the article here. JavaScript libraries have taught us to do stuff like checking to see if we have data and conditionally rendering an empty state if not. But that requires manipulation of the DOM as data changes. That kind of “state” manipulation can be done in CSS as well, by hiding/showing things already in the DOM with the display property. Especially now with :has() (last week’s CodePen Challenge, by the way), this kind of state checking is getting trivial to do.

.dynamic-content-area {
  display: none;
}
.loader {
  display: block;
}

.dynamic-content-area:has(:first-child) {
  display: block;
}
.dynamic-content-area:has(:first-child) + .loader {
  display: none;
}

I like that kind of thinking.

The async attribute is the way.

Harry Roberts digs into a somewhat old JavaScript loading pattern in Speeding Up Async Snippets. Have you ever seen this?

<script>
  var script = document.createElement('script');
  script.src = 'https://third-party.io/bundle.min.js';
  document.head.appendChild(script);
</script>

We’re getting over a decade in major browsers where that pattern just isn’t needed anymore, and worse, it’s bad for performance, the very thing it’s trying to help with:

For all the resulting script is asynchronous, the <script> block that creates it is fully synchronous, which means that the discovery of the script is governed by any and all synchronous work that happens before it, whether that’s other synchronous JS, HTML, or even CSS. Effectively, we’ve hidden the file from the browser until the very last moment, which means we’re completely failing to take advantage of one of the browser’s most elegant internals… the Preload Scanner.

As Harry says:

…we can literally just swap this out for the following in the same location or later in your HTML:

<script src="https://third-party.io/bundle.min.js" async></script>

Gotta preserve that Aspect ratio on images before loading.

It’s worth shouting from the rooftops: put width and height attributes on your <img> tags in HTML. This allows the browser to preserve space for them while they load and prevent content from jerking around when they load. This is a meaningful performance benefit.

It’s actually just the aspect-ratio of those two numbers that actually matters. So even if you won’t actually display the image at the size indicated by the attributes (99% chance you won’t, because you’ll restrict the maximum width of the image), the browser will still reserve the correct amount of space.

Jake Archibald puts a point on all this.

You can achieve the same effect with aspect-ratio in CSS, but in practice, we’re talking about content <img>s here, which are usually of arbitrary size, so the correct place for this information is in the HTML. There is a little nuance to it as you might imagine, which Jake covers well.

JPEG XL, we hardly knew thee.

Speaking of images, it looks like Chrome threw in the towel on supporting the JPEG XL format for now. It was behind a flag to begin with, so no real ecosystem harm or anything. They essentially said: flags are flags, they aren’t meant to live forever. We would have shipped it, but it’s just not good enough to warrant the maintenance, and besides no other browser was that into it either.

That actually sounds pretty reasonable of Chrome at first glance. But Jon Sneyers has a full-throated response in The Case for JPEG XL to everything aside from the flags shouldn’t last forever thing. I’d consider these things pretty darn excellent:

• JPEG XL can be used to re-encode any existing JPEG entirely losslessly and have it be 20% smaller on average. There are a boatload of JPEGs on the internet, so this seems big.
• JPEG XL can do the progressive-loading thing, where once 15% of the data has arrived, it can show a low-res version of itself. The popularity of the “blur up” technique proves this is desirable.
• JPEG XL is fast to encode. This seems significant because the latest hot new image format, AVIF, is quite the opposite.

So even if JPEG XL wasn’t much of a leap forward in compressed size, it still seems worth supporting. But Jon is saying “in the quality range relevant to the web”, JPEG is 10-15% better than even AVIF.

Of course, Cloudinary is incentivized to push for new formats, because part of its business model is helping people take advantage of new image formats.

TL;DR — If you link to your Mastodon profile from CodePen, and your CodePen profile from Mastodon, your Mastodon profile will display your CodePen profile as a verified link, proving ownership.

How does that work? It’s just HTML!

There is a rel attribute that can go on anchor (<a>) links. The values for rel have a variety of functionality. For example, you can tell search engines not to follow or rank a link and that it is user-generated:

<a 
  href="https://user-generated.com" 
  rel="nofollow ugc">
    User Link
</a>

There are safety and performance-gaining possibilities for using values like noreferrer and noopener as well.

Here’s another value: rel="me" (you can space-separate multiple values). The me value is a rather old-school Microformats thing. It’s pretty neat! The purpose is that you put it on links that point to other things that you own or control. Then, if the link you’re pointing to points directly back also with a rel="me" link that is a verification-of-ownership situation. As the wiki puts it:

Thus establishing a bi-directional rel-me link and confirming that the two URLs represent the same person.

The federated social networking site Mastodon (here’s me!) uses this exact setup to verify personal links. Here’s an image of my Mastodon profile:

Notice there are three links, the first two of which are highlighted with checkmarks and green:

• ✅ My personal website: https://chriscoyier.net
• ✅ My CodePen profile: https://codepen.io/chriscoyier
• An affiliate link for Advil: https://amzn.to/3WIHs84

Those “verified” links are verified because they follow the bi-directional rel="me" linking exactly as Mastodon requires.

On CodePen, we’re now adding that me value to all the links you add to your profile. Mastodon does the same, and thus verification is achieved. On my third link, that link to Amazon.com (obviously) doesn’t contain a link back to my Mastodon profile, so it doesn’t verify.

The Other Possible HTML to Verify

While CodePen is now properly putting the me value on profile URLs — that actually didn’t work for Mastodon verification on our first attempt. There were actually two problems:

• CodePen profiles are client-side rendered, and the Mastodon crawler can only see server-side rendered HTML.
• We needed to ensure the Mastodon crawler didn’t get trapped by the firewall.

With that second one taken care of via DevOps magic, we still needed a way to make sure the server-rendered HTML had something to verify against.

We aren’t yet server-rendering most of our React-rendered pages (we’ll get there), so the HTML that comes across that first request (and what Mastodon crawls) is essentially a shell page with minimal HTML. We could have tossed the <a rel="me" ...> links into the <body> of that first response, but that seems a little awkward to only have them ripped away by client-side rendering immediately. Instead, there is another equally valid way to provide rel="me" links, and that’s like this:

<head>
  <link rel="me" href="https://chriscoyier.net/">
  <link rel="me" href="https://front-end.social/@chriscoyier">

So we’re actually doing both the <head> links and the <a> links now, and good news, it works great.

---

Thanks to Will Boyd for asking about this and Amelia Bellamy-Royds for all the back-and-forth on Mastodon as we figured all this out.

---

Related writings:

• The Markup / Dan Phiffer: How We Verified Ourselves on Mastodon — and How You Can Too
• Eric Meyer: How to Verify Site Ownership on Mastodon Profiles

Say you like how a particular element on a website looks and interacts. You can pluck it right off that site, HTML and CSS included, and pop it over to CodePen using the plugin CSS Pro. Watch me try it here:

The browser extension is not free, so you’d better be sure you’d use it! Exporting to CodePen is just one of many features. It seems like the core of it is more front-end developer-friendly inspection and alteration of sites.

There used to be a DevTools extension that would do this called SnappySnippet, but that appears to be dead now, so long live CSS Pro!

The post Move An Element from Any Website to CodePen appeared first on CodePen Blog.