CSS has been getting so many awesome features lately, and some of the items on this list are already being worked on, while others should totally be achievable in the near future. But just for fun, I will also include a few stretch goals that might only be possible with some magic wand 🪄.

Arbitrary mixins

What I mean by this is basically Sass mixins. I want to be able to include any arbitrary set of declarations or rules inside another rule. This arbitrary CSS could also come from a different file.

@import url('./utils.css') mixins(visually-hidden);.skip-to-content:not(:focus, :active) {  @apply visually-hidden;}

We're kinda getting there with style queries, but the problem is that a container cannot query itself so the "trigger" needs to be set on the parent element.

Edit: The more I think about this, the more I just want classes to be able to extend other classes. It feels simpler and is more "CSS-y".

Visually hidden

Sure would be nice if I didn't have to define an esoteric set of declarations for hiding content visually while keeping it accessible to assistive technologies.

.skip-to-content:not(:focus, :active) {  display: visually-hidden;}

Scoping

I talk about this one a lot. Scoping is one of the essential features missing from CSS currently. Naturally, this leads to developers (including me!) coming up with their own hacky ways to manage scoping.

The good news is that @scope is being worked on, even if it's a little confusing. The most interesting bit there is that it allows defining a lower boundary (aka CSS donuts).

🪄 The dream would be to extend native CSS module scripts (and constructable stylesheets) to behave more like non-native CSS modules so that the classes can be referenced in JavaScript or HTML. One of the challenges here is that this needs to also work at build time (outside the browser) for optimal performance.

import sheet from './styles.css' assert { type: 'css' };const styles = sheet.scopedClasses;const App = () => /*html*/`  <div class=${styles.wrapper}>    <span class=${styles.inner}>hi</span>  </div>`;

Auto color contrast

I want to be able to dynamically find colors that sufficiently contrast with the background. There are ongoing discussions about a color-contrast() function, and some version of it is even implemented in Safari TP.

.foo {  background: var(--bg);  color: color-contrast(var(--bg) vs white, black);}

But as I understand, this feature is currently blocked because the WCAG contrast algorithm is not perfect. Very unfortunate, because this is not something that can be easily achieved at build time - CSS variables only exist at runtime. Can I just have the "imperfect" version in the meantime and switch to a better algorithm when it's available? 🥺

SVG-in-CSS

We can use svgs from a url in a background-image, but we can't change its fill. To change the fill, we need to do the whole dance of using mask with background-color, which is a lot. And it's not perfect, as we don't get granular control over the paths inside the svgs.

Wouldn't it be nice if we could just use svgs inside CSS and do whatever we want with them, including inline CSS variables? 🪄

.icon[data-icon=sun] {  --_fill: orange;  background: svg('<svg fill="var(--_fill)" viewBox="0 0 512 512"><path d="M256 118a22 ..."/></svg>');}.icon[data-icon=moon] {  --_fill: wheat;  background: svg('<svg fill="var(--_fill)" viewBox="0 0 20 20"><path d="M17.39 15.14A7.33..."/></svg>');}

Animateable display

First we got animateable grid, so the natural next step is to be able to animate between height: 0 / height: auto and also to/from display: none.

Static variables

Custom properties are extremely powerful, but they are just properties, which means they have many limitations, such as not being able to use outside style rules.

What if we could have a less powerful (and therefore more flexible) version of variables, similar to Sass? We'd be able to use them anywhere, including inside strings and media queries. 🪄

__mobile: calc(500 / 16 * 1rem);@media (width > __mobile) { ... }

Tooltips

It shouldn't require a delicate contraption of precisely authored HTML+CSS+JS to make a damn tooltip. The challenge here is to make it show in the top-layer (which traditionally requires portaling the markup out near the root) and pin it to a reference element (which requires JavaScript to calculate position) and adjust the position when near the edge of the viewport (which requires even more JS).

Maybe 2023 will be the year of CSS anchor positioning which addresses all of these issues. (edit: maybe 2024)

Double slash comments

To end on a lighter note, as a frequent Sass user, I often find myself writing // double slash comments even in vanilla CSS files. I'm sure there is a technical, parsing-related reason why this cannot be made to work, but it certainly would be nice. 😅

Other wishlists

• Chris Coyier: Things CSS Could Still Use Heading Into 2023

• Ahmad Shadeed: My CSS Wishlist

• Eric Meyer: CSS Wish List 2023

• Manuel Matuzovi: My CSS wish list

• Stephanie Eckles: My CSS Wishlist 2023

• Dave Rupert: CSS Wishlist 2023

• Tyler Sticka: Tylers CSS Wish List for 2023

• Jim Nielsen: My 2023 CSS Wishlist

Fast forward to today, where just thinking about CSS makes me giddy. I obsess over tiny CSS details, like theming scrollbars. I see a well-designed UI out in the wild, and the very first thing I do is pop open dev tools to try and figure out how it was made. I'm unafraid. I enjoy CSS.

So what changed? Well, I took the time to learn CSS. Oh and also the fact that CSS is now Good and only keeps getting better year after year. Even the smallest of things, like flexbox gap, make CSS feel more ergonomic and approachable.

Still, most new CSS features don't help with its maintainability, at least until recently... In 2021, we got the much needed :where pseudo-class, which lets us control the specificity of selectors. In 2022, we got cascade layers, which let us bypass selector specificity altogether (even for third-party styles!) and directly control the order of large chunks of styles. This is by far my favorite recent addition to CSS.

But it's only half of the equation.

Scoping

You see, CSS maintainability is a two-dimensional problem. Layers solve the vertical aspect of it ("order"), but we still need something to manage its horizontality ("reach"). Just like we don't want our global reset styles overriding our component styles, similarly we don't want the styles for one component interfering with other components. If we do this right, we would also know exactly what is being used and where, meaning we can confidently remove dead code (something that has been historically too difficult to do in CSS).

(Diagram based on Miriam Suzanne's guide to cascade layers)

There is a spec being developed for @scope which will help with this across the board. Maybe we'll see it shipped in 2023? But until then, we're on our own.

Scoping is one of those problems that developers have attempted to solve the most. One of the simpler forms of scoping is achieved by using naming conventions like BEM. More formally, it is solved through tooling. CSS modules (not the native ones) is probably the most popular and robust solution for scoping it has been implemented by countless tools and has spawned similar variations in many other tools. It worked well then and continues to work well now, despite so many years of innovation both in browsers and in the developer ecosystem.

Colocation

Having a solution only for scoping can often be enough, but we can do better. We often want better. We want our styles to live close to the markup that they are scoped to. This makes it easier to keep them in sync, change/delete them together, etc. (This is also the whole promise of a utility-first approach, right?)

This is where BEM, CSS modules, et al start to feel a bit unergonomic. The styles and markup live in different locations the closest we can get is a CSS file in the same folder. And we still need to manually make the association. There is no Intellisense or "Go to definition" to travel back and forth between the two. It is easy for things to get out of sync. And the bigger the size of the team, the greater the chance of human error.

Admittedly, web components (specifically shadow DOM) have somewhat solved this problem. But, in my opinion, shadow DOM goes too far with its style encapsulation. I don't want to throw away the entire cascade, I simply want some (but not all) parts of it to be closely tied to specific elements.

That's where CSS-in-JS comes in. There are very clear DX benefits to libraries like styled-components and emotion*. They provide scoping and colocation on top of the full power of CSS. But remember: CSS was missing some key features back then, and developers really enjoy writing JavaScript. So why not use JavaScript as a pre-processor, post-processor, runtime-processor, everything-processor for theming, breakpoints, "variants", "style objects", "polymorphism", "critical CSS", "extending styles", even global styles.

...eh, what? I just wanted scoping and colocation. Why is JavaScript eating everything up? And isn't there a tangible cost to all of this?

*The idea of CSS-in-JS actually predates CSS modules (but not BEM). But it was a very different form of CSS-in-JS from what we see today with styled-components and emotion, so I've chosen to skip past that.

Performance

Calculating all styles in JavaScript at runtime kills performance (perhaps obviously). Even with SSR, it takes time for the page to become interactive. I have personally seen multi-second page loads on sites that use runtime CSS-in-JS.

It took a few years but the JavaScript community has started recognizing this issue. You might recall a recent blog post from Sam Magura, one of the maintainers of emotion: "Why we're breaking up with CSS-in-JS". In that post, Sam goes into a performance deep dive, illustrating the problem with practical measurements and an insider perspective.

I should (again) briefly mention that web components can kinda fix this, through constructable stylesheets. Even better, that API can be used outside web components to potentially improve the performance of runtime CSS-in-JS for light DOM (see github issue). But we may be past that point, considering that maintainers are "breaking up" with the whole idea, and a large portion of their userbase has moved on to utility classes.

Besides, even the React core team now recommends static solutions over runtime:

"You could however build a CSS-in-JS library that extracts static rules into external files using a compiler. That's what we use at Facebook."

Compile all the things!

It starts to become clear by now that if we want the DX benefits of CSS-in-JS and the UX benefits of static CSS files, then we might need to do things at compile/build time. Pretty much all of the downsides of CSS-in-JS we've seen so far can be traced back to doing things using JavaScript at runtime.

In the same article where Sam Magura discusses the runtime performance of CSS-in-JS, they also briefly attempt to speculate on the downsides of compile-time CSS-in-JS libraries (without actually having tried any of those libraries, mind you). In response to that, Mark Dalgleish (co-creator of CSS modules and Vanilla Extract) called out the falseness of these claims.

While we're talking about Vanilla Extract, I should mention that I think it is solving a different problem than most CSS-in-JS libraries. Its main focus is to help build type-safe design systems, not websites or applications. Now, one could argue that many applications could benefit from using a design system (one that could be built on top of Vanilla Extract perhaps), and I would generally agree, but that is a different conversation.

Back to the topic at hand: remember, we want scoping, colocation, and performance. If the goal remains focused on those three points, then this becomes a much narrower, simpler problem to solve. Let me show you my attempt at solving it.

Since scoping happens at the class level (or more broadly, selector level), we'll use it as the singular point in our API. This has the added benefit of being framework-agnostic. And it's all we really need.

From a DX perspective, the API is quite intuitive too, especially for those coming from other CSS-in-JS libraries (the idea for the css function actually comes directly from emotion). We also get to use real CSS syntax here, so the authored code feels instantly recognizable to everyone. There is no learning curve, and the styles are copy-pasteable across different projects and codepens.

So now we just need to replace the whole CSS string with a hashed class name and use it to populate a CSS file. Sounds simple enough. And honestly? It is! Building the original proof of concept only took about 50 lines of code (and a few drinks).

I want to emphasize again that this is all at build time, which enables us to do all kinds of shenanigans with the extracted CSS, without affecting runtime performance. That's how we're able to get & nesting for free (using PostCSS). We can use this idea to go one step further and support Sass too, because Sass is awesome!

Sweet! So we've basically taken verbatim what would have been in a .css or .scss file, and instead put it inside our .jsx/.tsx files with scoped class names that have all the same benefits of JavaScript variables - being importable, tree-shakeable, "Go to definition"-able, etc. It's like inline (S)CSS modules!

Closing thoughts

Scoped + colocated + performant styling totally should have been an already-solved problem. There were definitely attempts made: Linaria is a static CSS-in-JS library designed to address exactly this; except I have had trouble getting it to work with cascade layers or with Vite SSR (a la Astro). In fact, I have had trouble with most CSS-in-JS libraries in Astro.

I am notably more disappointed in React for not taking this problem seriously. To illustrate this, you need only to look at the competition. Most frameworks that use a non-JSX language for templating Svelte, Vue, Astro, Angular, WebC have a mechanism for scoping CSS (if you use one of these non-JSX frameworks, you were probably waiting for me to mention this). There is no reason React, and by extension JSX, can't support scoping when others have done so for ages. React, in its quest to be unprescriptive, has led to years of arguably suboptimal attempts by the community, to solve a problem that the framework is best equipped to solve. The same goes for other JSX frameworks like Preact and Solid, but there is no doubt that once React figures it out (and there are signs they might), others will soon follow.

My goal for ecsstatic is to make it the closest thing possible to CSS so that it supports all CSS features (including ones that don't exist yet) but more importantly, so that when the time comes, migrating off of it feels painless.

If you've made it all the way to the end, have a balloon: 🎈. And maybe check out ecsstatic.dev. Thanks for reading.

Usually, we want to use an empty string as the value for the content property. This ensures that the pseudo-element is purely decorative and will not lead to unexpected announcements by assistive technologies.

::before {  content: "";}

However, we might sometimes get the urge to use unicode characters in the content. A few common examples include:

• * at the end of labels for required inputs

• # or 🔗 near clickable headings (fragment links)

• to indicate expandable content

• or between breadcrumbs

If these symbols are used with content, it could cause a confusing experience for users who rely on assistive technologies.

::before {  /*  don't do this! */  content: "#";}

In the future, we might be able to specify an empty alt text (Adrian Roselli has a great article on this topic), but support is lacking currently.

::before {  /* someday */  content: "#" / "";}

So what do we do?

Use svgs! The mask technique that I demonstrated above in the custom checkbox demo is a great way to use svgs without leaving CSS.

::before {  --svg: url(...); /* can be a remote url or a data url */  content: "";  background-color: currentColor;  -webkit-mask-image: var(--svg);  mask-image: var(--svg);}

Okay but text is nice

Fine! I get it. Good news: I may have just found a way to do this accessibly. Let me show you.

We will still use the mask technique, but instead of using a real svg icon, we will construct one on the fly using a data url. And we will put our text inside the svg using a <text> element. For the purposes of this guide, let's use the * character to put at the end of a required label.

<svg xmlns="http://www.w3.org/2000/svg">  <text>*</text></svg>

Let's add some attributes for positioning and styling the text. You can adjust these to your liking.

• 16x16 viewBox to correspond with default font size

• font-family='system-ui' so it adapts to the system font

• font-size='1rem' should be the default but you can adjust for your desired size

• text-anchor='middle' for horizontally centering the text

• x='50%' and y='100%': I will admit I kept adjusting these randomly until the symbol was close to the center of the box 😅

<svg viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg">  <text font-family="system-ui" font-size="1rem" text-anchor="middle" x="50%" y="100%">*</text></svg>

We can now put that in a data url and assign it to a custom property for ease of use. Note that some symbols might need to be replaced (for example, # becomes %23).

--svg: url('data:image/svg+xml;utf8,<svg viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg"><text font-family="system-ui" font-size="1rem" text-anchor="middle" x="50%" y="100%">*</text></svg>');

Sweet, now we can use it with the mask technique. We'll use the ::after element because we want this to appear after the label text. We do need to give it a width and height explicitly (or use position: absolute). And let's also add forced-colors support.

label::after {  content: "";  -webkit-mask: var(--svg) no-repeat center;  mask: var(--svg) no-repeat center;  background-color: red;  display: inline-block;  width: 1em;  height: 1em;  @media (forced-colors: active) {    background-color: CanvasText;  }}

And we're done!

Pretty neat, if you ask me. 😄

Initial focus

By default, when the dialog is shown, it will focus the first focusable element inside it. If it's a modal dialog, it will trap focus so that the rest of the page is "inert". When closed, focus will return to the dialog trigger.

This default behavior works well when the very first thing inside the dialog is a close button.

But when there is a bunch of text before the first focusable element (e.g. a link in a paragraph), it could result in a confusing experience for screen readers as focusing that element would skip all the prior content. It could also be confusing for sighted users if the prior content is so lengthy that it scrolls off screen.

Solution: Manually set initial focus on what makes the most sense. This is achievable, without any JavaScript, by specifying tabindex="-1". This makes the element focusable but not tabbable. For example, we could set tabindex="-1" on the first heading inside the dialog, and it would be automatically focused when the dialog opens.

If you want to learn more, Scott O'Hara has a good article that goes into more detail on this topic and links to github discussions.

Prevent page scroll

By default, a modal dialog makes the rest of the page "inert". Ideally, this means the user can't interact with anything outside the page, but I found one scenario that it doesn't fully cover: The user can still scroll the page when the dialog is open.

Thankfully, the solution is quite simple: we can use :has to check if the page has a :modal dialog and that it is currently open. If it is, then we set overflow: hidden to disable scrolling.

html:has(dialog[open]:modal) {  overflow: hidden;}

This will probably cause layout shift, so let's fix that with scrollbar-gutter.

html {  scrollbar-gutter: stable both-edges;}

While we're waiting for Firefox to ship :has, we could use JavaScript to set overflow: hidden on the page, or we could treat this as progressive enhancement and leave the default behavior unchanged.

Something I've also noticed is that when the root scroller is not the <html> but some child element inside <body>, then the page is no longer scrollable, even though the scrollbar is still visible. That makes it even easier for us to treat this as progressive enhancement.

.root-scroller {  block-size: 100dvb;  overflow: auto;  scrollbar-gutter: stable both-edges;  &:has(dialog[open]:modal) {    overflow: hidden;  }}

Here's a codepen you can play around in:

Light dismiss

There are three ways to dismiss a dialog:

• Pressing the Esc key

• Submitting a <form> with method=dialog

• Explicitly calling .close() on the dialog using JavaScript

But we usually also want to close all modal dialogs when clicking the "backdrop" area (this is called "light dismiss" sometimes).

This is a bit tricky. There is nothing like a "backdropclick" event, so we need to rely on regular click events and call close() in the correct place.

I've found two ways of doing this. Unfortunately, both of them require wrapping the dialog's contents in a separate element that takes up the entire space inside the dialog. This means there must be no padding on the dialog itself (we even need to undo its default padding). And we need to propagate any explicit sizes (e.g. max-height, width, etc) to the content wrapper.

<dialog>  <dialog-contents>    ...  </dialog-contents></dialog><style>  dialog {    padding: 0;  }</style>

After this, we can go one of two ways.

We can set up two separate click listeners: one on the <dialog> where we call close, and one on the content wrapper where we call stopPropagation.

const dialog = document.querySelector('dialog');const dialogContents = document.querySelector('dialog-contents');dialog.addEventListener('click', () => dialog.close());dialogContents.addEventListener('click', (e) => e.stopPropagation());

Alternatively, we can add a single click handler to <dialog> and conditionally call close only if the event target is the dialog itself, and not any nested elements.

const dialog = document.querySelector('dialog');dialog.addEventListener('click', (e) => {  if (e.target === e.currentTarget) { // or e.target === dialog    dialog.close();  }});

Looks weird, but it makes sense when you consider that the ::backdrop is actually part of the <dialog> element.

And here's a codepen you can play with:

Update: Jonathan Neal has found a way to achieve this without a content wrapper (see codepen). This can be neat for basic use cases, but be careful when using it together with a popover component.

Bonus: setting display

You may have encountered this already if you've worked with <dialog> before. When the dialog element has a display property (usually grid or flex for layout purposes), then it will no longer stay hidden when it's closed. That's because we are overriding this rule from the user-agent stylesheet:

dialog:not([open]) {  display: none;}

Normally, fixing this would involve repeating that same rule in our own stylesheet, or setting display only for dialog[open] (thanks Kilian). But since we are already using a content wrapper for light dismiss, this is a non-issue. We can set our display property on the wrapper.

<dialog>  <dialog-contents>    ...  </dialog-contents></dialog><style>  dialog-contents {    display: grid;  }</style>

Bonus 2: close animation

Currently, it is straightforward to animate a dialog on entry. Not so much on exit, because of display: none that gets applied by the UA stylesheet. (It will be possible to animate display: none in the future though 👀).

Now, you could override the UA stylesheet and do all sorts of hacks with visibility/pointer-events, but you don't need to. There is a much simpler and robust solution.

Instead of only calling dialog.close(), firstly call .animate() with your desired keyframes and options. And then when it is finished, commit the styles and call close(). Job done.

dialog .animate([{ opacity: 0 }], { duration: 200 }) .finished.then(animation => {   animation.commitStyles();   dialog.close(); });

If you've never heard of Astro, it's a new metaframework built on top of Vite. I know! Some of you are probably rolling your eyes at the thought of yet another framework, but hear me out. It just makes sense!

Minimal API surface

Framework churn is a real thing. No one wants to learn a new tool just to see it go away in a year. But with Astro, there is barely anything to learn.

The markup syntax used in .astro files is literally just HTML with the ability to use JS expressions inside {curlies}. It's like JSX but without the weird quirks. You get to use regular <svg> attributes and <style> tags like normal HTML. No more className or {' '}.

Besides the markup, all the code that runs before the page generation goes in the "frontmatter" at the top of the file. Any variables declared here will be available in the markup. And because we have access to the full power of JavaScript, we can do all the standard stuff like import and fetch and await.

---import { format, parseISO } from 'date-fns';const data = await fetch('/my-api').then(r => r.json());const { title, content, publishDate } = data;const publishDateParsed = typeof publishDate === 'string' && format(parseISO(publishDate), 'MM/dd/yyyy');---<h1>{title}</h1>{publishDateParsed && <aside>Published on: {publishDateParsed}</aside>}<p>{content}</p>

It feels like modern-day PHP, and I mean that in the best way possible. 😄

There is so much going on in that little snippet:

• ESM imports
• npm packages
• web fetch API
• top level await
• typescript!

All of those pieces feel natural and make sense but if you try to assemble it all yourself, you'll realize why this is such a big deal (Node + ESM + TS is way harder than it should be!). What's more, even though Astro is handling all of that for you, the only code that is specific to Astro is the (ab)use of the frontmatter syntax (---).

In fact, other than the .astro file syntax, most of the Astro-specific things can be covered by three categories: an Astro global object, a few template directives for hydration, and file-based routing. You won't need to spend hours perusing the Astro docs (which are fantastic btw) because Astro tries to defer everything else to the platform (e.g. web APIs) or to other tools (e.g. Vite or React). There is an astro config file but the astro add CLI takes care of most of the things in there.

Bring your own UI framework(s)

When you need more than what is possible inside a .astro template, Astro lets you use components from your framework of choice. This in particular is a breath of fresh air in a world where we see one of two trends: either the author of a UI framework builds their own metaframework to go with it, or the author of a metaframework decides to build it around React.

Astro inverts this idea and goes even further by letting you mix and match frameworks. Imagine using SolidJS as the default for its very solid primitives, utilizing Svelte for its animation utilities, and leveraging React for its ecosystem. All on the same page. What's more, you can even nest frameworks. 🤯

<div>  <MySolidComponent client:load>    <MyReactComponent client:load>      <MySvelteComponent client:load />    </MyReactComponent>  </MySolidComponent></div>

Again, this just makes sense. Why reinvent a UI framework when so many excellent options already exist and have different strengths?

Client-side JS is opt-in

Over the course of the last decade, web frameworks have gravitated to a JS-first approach. Astro goes the opposite way by requiring JS to be manually turned on, and it does so quite elegantly, allowing JS to be toggled at a component level rather than page-level.

Ever since Jason Miller's original post on Islands Architecture, I've been curious about actually using it in practice. Previously your options were:

• ship all of the JavaScript (no islands) or none of it (all land)
• ditch frameworks and use <script> tags
• roll your own islands on top of something like 11ty

But Astro is specifically designed around the idea of islands so you get to use components just like you normally would in your favorite framework, and then turn on JS with a template directive. I appreciate the client:idle directive in particular.

<Header /> // <-- this will output static HTML<LoginButton client:load /> // <-- this will load the JS immediately<Carousel client:idle /> // <-- this will load the JS via requestIdleCallback

To me, this approach just makes sense. Not everything on the page needs to be hydrated with tons of JavaScript. Think of all the icons that live rent-free in your JavaScript bundle.

(I would be remiss not to mention all the work going on over at Qwik. I'll be giving that a try very soon as well.)

Conclusion

That's all for today. Astro is refreshingly simple and I've been enjoying using it a lot. One quick note: you may have noticed that I refer to Astro as a "metaframework" rather than a "static site generator". This is on purpose because I think Astro does so much more than what you would get from something like Hugo. I plan to elaborate in another article so stay tuned. (edit: maybe some other day)

"A great tool becomes so successful it becomes obsolete. They are like R&D for the web platform and become polyfills when they get implemented in browsers"

@adactio #cssday @Una, June 9, 2022

I think his intention there was to imply that Sass has helped the web evolve (which is very much true). But to call it a polyfill is absurd.

So let's take another look at Sass and some of the things it is still useful for in 2022.

Sass is for static things

We can't "run" CSS outside of a browser. This is by design, as the same line of CSS can mean vastly different things in different contexts. But this also means that we need to make the browser do all those things even if they can be done statically.

The calc function, combined with custom properties, is often used as an example of a feature that makes Sass obsolete.

Let's say we want to calculate a size derived from other lengths. This is a common requirement for aligning one element (e.g. a header logo) with another (e.g. a sidebar). We might write something like:

width: calc(var(--icon-size) + var(--padding) * 2 + var(--border-width) * 2);

This is great if we are using fluid sizes ( la Utopia). calc is the perfect tool when our lengths are in a mixture of different units.

But what if we already know the sizes beforehand? Then we can probably do the calculation beforehand.

I'm all for letting the browser do its job, but to do that, it has to actually download the code. And we should generally strive to send less code to the client if we can.

That's where Sass comes in. If we can statically access those sizes (e.g. either in pixels or in rems), then Sass can generate the final result for us.

// outputs final value, e.g. width: 68pxwidth: $icon-size + $padding * 2 + $border-width * 2;

This was a very small example, but we could easily extrapolate this to our entire codebase. Imagine if we had a custom property for every little thing in every little corner of our website. 😬

The beauty of Sass is that it "compiles away", which means we can write the most expressive, readable, even verbose, code without worrying about sending any extra bytes to the browser.

Sass can work together with modern CSS

CSS features are often more powerful than the Sass equivalents. A somewhat obvious example: CSS variables (custom properties) exist at runtime and can change dynamically, whereas Sass variables only exist at build time.

This static nature of Sass used to be considered a "limitation", but here's the thing: just because CSS is adding features that used to be exclusive to Sass doesn't mean we need to go all in one and stop using the other. Once we realize their differences, we can use them together to get the best of both worlds.

Let's say we have a set of design tokens. We can define them all as Sass variables at the top level, even if not all of them are consumed yet, because they will be stripped away during compilation.

$border-radius-1: 2px;$border-radius-2: 4px;// ...$background-1: hsl(0 0% 0%);$background-2: hsl(0 0% 10%);// ...

Now if we're building a component that needs to look decent by default but also needs to be customizable, then we can bring in CSS variables.

border-radius: var(--button-border-radius, #{$border-radius-1});background: var(--button-background, #{$background-2});

This will allow us (or our user) to do the customizations without having to change any of the actual properties. We might even expose a nice API for these custom properties using JavaScript (e.g. React props), drastically simplifying the usage.

<Button borderRadius={3} background='rebeccapurple'>Hi</Button>

Sass adds a lot of "nice" features

Sass has nesting and double-slash comments. Those alone should be worth the cost of admission in my opinion.

Even though nesting is coming to CSS, the Sass version is here today and it has more features than the native CSS nesting will have.

For instance, we don't ever need the & in Sass, making it feel more intuitive.

button {  svg { // instead of & svg    // ...  }}

And we can nest at-rules inside selectors.

button {  &:is(:hover,:focus) {    @media (prefers-reduced-motion: no-preference) {      transition: transform 0.2s;      transform: translateY(4px);    }  }  @layer overrides {    @media (forced-colors: active) {      border: 1px solid;    }  }}

And we can use nesting to generate incremental class names.

.button {  &-active { // results in .button-active     // ...  }}

Sass also has functions, including some handy built-in ones. The color module is especially useful.

$accent: hsl(250 50% 50%);$accent-overlay: color.change($accent, $alpha: 0.1);$accent-darkened: color.scale($accent, $lightness: -30%);

We can't do any of that in CSS today.

Sass is really good for reusing code

With mixins, Sass can help us generate a lot of repetitive CSS without having to manually duplicate the code.

A very common example is theming, where we need to use the cascade to handle every theme using both a preference query (for OS) and as an override (for custom theme switcher). Imagine duplicating dozens of variables and forgetting to update one of them in the future.

Sass lets us handle this rather elegantly.

:root {  @include light-theme;  @media (prefers-color-scheme: dark) {    @include dark-theme;  }  &[data-theme=light] {    @include light-theme;  }  &[data-theme=dark] {    @include dark-theme;  }}@mixin light-theme {  --background: hsl(0 0% 90%);  --text: hsl(0 0% 10%);  // ...}@mixin dark-theme {  --background: hsl(0 0% 10%);  --text: hsl(0 0% 90%);  // ...}

We can even put those theme mixins in separate files and import them granularly, something we can't do with pure CSS yet.

And of course Sass has loops and conditionals and interpolation, which let us generate "variants" extremely quickly.

@each $status in positive, negative, warning {  .component-#{$status}    background: var(--bg-#{$status});    color: var(--fg-#{$status});    @if ($status == negative) {      border: 2px solid;    }  }}

Sass is super easy to use

Because of how prevalent Sass has been historically, it has amazing support in a large number of environments. In most build systems, using Sass is as simple as installing a package and maybe adding a line of config. Vite, which is one of my preferred build tools, doesn't even require any config.

This low friction makes it hard to say no to Sass, considering all the value it provides without much of a cost.

But what about PostCSS?

PostCSS is great for a lot of things, such as autoprefixing, discarding comments, minification, and even writing tomorrow's CSS today. We can even solve nesting with PostCSS. So why use Sass?

In my experience, PostCSS can suffice for smaller projects, but Sass really shines at scale where it almost serves like a bundler.

And despite some of the overlap, I think these tools serve different needs. They also happen to work great together, allowing us to take advantage of the best parts of both.

LightningCSS?

LightningCSS looks like a really promising alternative to PostCSS. It requires some manual configuration (unlike PostCSS, which is usually baked into build tools) but it works pretty well. That being said, it's an alternative to PostCSS, not Sass. And of course, that means it works well as a postprocessing step after Sass.

Conclusion

Hopefully, this clears any doubts about the relevancy of Sass in 2022 (and beyond). CSS is making great progress at adding a lot of the missing features that originally made Sass so attractive, but I don't think we are at a point where vanilla CSS can replace Sass yet. At best, the role of Sass has changed to help make better use of modern CSS.

The basics

When the content of an element is too big to fit in it, we can use overflow: auto to make it scrollable. There's more to it, but this is all you need to make the default scrollbars show up.

As for styling the scrollbars, you can use the -webkit prefixed scrollbar properties combined with the standard scrollbar-width and scrollbar-color properties. There have been countless posts on this topic, so I won't bother repeating those parts. I recommend Ahmad Shadeed's scrollbar guide if you're not already familiar with these properties.

I do want to mention the postcss-scrollbar plugin that generates the -webkit prefixed scrollbar properties from the standard ones. Which means you can get cross-browser styles with just this:

.scroll-container {  overflow: auto;  scrollbar-width: thin;  scrollbar-color: hsl(0 0% 50%);  /* postcss-scrollbar will add the -webkit version automatically! */}

Looks simple enough. Now let's get to the more interesting bits.

Theming scrollbars

If you've decided you still want to rely on the default scrollbars, fair enough. But you need to be careful here if your site supports a dark theme. I see way too many sites implement a dark mode with their scrollbars still stuck in light mode. Here's what the remix.run docs look like on Windows in dark mode:

This can be fixed using the color-scheme property or meta tag. You should probably be doing this anyway, for non-scrollbar reasons too. Thomas Steiner has a great article on web.dev if you want to learn more.

html {  /* defer to OS preference */  color-scheme: dark light;  /* override, assuming the theme toggler sets a data-theme attribute */  &[data-theme=light] { color-scheme: light; }  &[data-theme=dark] { color-scheme: dark; }}

The scrollbar quirks of various operating systems

In this section, I will rant about different environments, the expectations, the behaviors, and the problems that come with them, as well as some future speculation. If all you care about is the code, feel free to scroll to the end of this section. 😅

Windows

As I demonstrated in the previous section, Windows has always had some of the ugliest-looking scrollbars of any platform. Windows 10 specifically has the ugliest scrollbars in all browsers. Even if you set the right color scheme, they look too boxy and thick.

Windows 11 is attempting to modernize the scrollbars by making them thinner and overlay. This can be noticed in the various first-party interfaces (e.g. the Settings app) across the OS. As for the browsers, Firefox 100+ is already shipping it, while Edge/Chrome have it in some form behind a flag.

The Firefox implementation in particular worries me because the scrollbar is razor thin and disappears unless you're actively interacting with it. To make things worse, there seems to be no way to change this behavior programmatically. Firefox does respect the "Always show scrollbars" setting in Windows 11 but it's off by default and we can't reasonably expect most users to turn it on. I really hope this will be addressed in a future update. For now we can't do anything.

On Chromium, things are simpler: if you specify even one of those -webkit-scrollbar prefixed properties, you become responsible for providing the entire scrollbar styling. This is exactly what we want, at least until the Windows 11 scrollbars ship in Chromium.

macOS

While macOS scrollbars look less offensive, they come with their fair share of problems.

The first one is a bit of nitpick but I find it super frustrating that I can't just move my cursor to the right edge of a browser window and use it to scroll. This is because macOS reserves the edges for resizing/moving the window, even if the cursor is still hovering on the scrollbar thumb. This effectively makes the already-thin scrollbar even thinner (albeit only for the viewport scroller).

The second is a more relatable problem: automatically disappearing scrollbars. They can offer a nice and clean interface... if the user knows that a part of the page is scrollable. In practice, they are very frustrating to deal with. Recently I had an experience where I literally couldn't find the ticket to a conference because it was hidden outside the scrollport and the scrollbar was invisible. In other words, disappearing scrollbars can literally cost you money. To work around this, you could maybe force the height of the scrollport to be such that the last item is half visible. Or you could use some JavaScript to detect scroll position and add a scroll shadow.

Both of these issues can be avoided by specifying custom scrollbar styling, so we should be good here.

Android, iOS, and touchscreens

Touchscreen devices are interesting. They have the same thin, overlaying, disappearing scrollbars that I framed as a problem in macOS, but the usage is quite different: the user doesn't interact directly with the scrollbar and instead drags their thumb against the scrollport. Also, because the screen is usually smaller, content overflows more often and the user is expected to scroll a lot more to find content. This is also why there are special features designed specifically for this modality, such as (1) momentum-based (inertia) scrolling, and a (2) visual highlight or spring animation when reaching the edge of a scrolling container. Android is even more thoughtful about this and decides to always show the scrollbar when a scrollable element first appears, and then switch to the regular auto-disappearing behavior after the user has scrolled at least once (signalling that they are now aware the area is scrollable).

All that to say, I quite like the default behavior of these scrollbars and would like to preserve it. This is achievable using the pointer media query, which will let us conditionally style scrollbars based on whether the user is on a high-accuracy pointing device (e.g. mouse) or a low-accuracy one (e.g. touchscreen).

@media (pointer: fine) {  .scroll-container {    /* ...custom scrollbar styles only for desktop */  }}

I've used this approach on multiple projects and feel pretty good about the results.

Preventing layout shift

One problem with overflow: auto is that it only shows the scrollbar if the content is actually overflowing, meaning it can cause a layout shift if a scrollbar suddenly appears. Historically, this has been possible to fix using overflow: overlay (in Chrome) to avoid having the scrollbar ever occupy space, and/or using overflow: scroll to always have it occupy space.

These days we can explicitly tell the browser to reserve space for scrollbars using scrollbar-gutter: stable. It's supported in Chrome and Firefox, and we can fallback to overflow: scroll for Safari. If you use an invisible scrollbar track, this fallback should work identically to scrollbar-gutter.

.scroll-container {  overflow: scroll;  @supports (scrollbar-gutter: stable) {    overflow: auto;    scrollbar-gutter: stable;  }}

Worth noting here is that if you want scrollbar-gutter on the viewport, it's tricky to make it work on the <body> and might be easier to move it either to the :root or to a child.

More scrollbar goodies from modern CSS

While not directly related to scrollbar styling, there are a few more properties I want to briefly mention that can help improve the scrolling experience. The wealth of tools CSS provides us today never ceases to amaze me.

Scroll padding

scroll-padding allows creating an offset at the edge of the scrollport. This is incredibly useful when you have a sticky header that would otherwise cover up headings scrolled to via in-page jump links or fragment urls.

.scroll-container {  scroll-padding-top: var(--header-height);}

There's also scroll-margin which behaves similarly, except it is applied on the individual elements rather than the scroll container.

Scroll behavior

scroll-behavior lets you enable smooth scrolling, which is also super neat for in-page jump links. Don't forget to guard it in a reduced motion check for better accessibility!

@media (prefers-reduced-motion: no-preference) {  .scroll-container {    scroll-behavior: smooth;  }}

Overscroll behavior

Named similarly as the previous one, overscroll-behavior does something quite different: it lets you prevent scroll-chaining in nested scrolling areas. This is especially handy in common nested regions like dialogs and sidebars, where you don't want the underlying page to start scrolling when you reach the end of the current scrolling container.

.scroll-container {  overscroll-behavior: contain;}

From a UX perspective, I think contain should be the default for all scrollable regions, and auto should be used in very few places.

Scroll snapping

Introduced a while ago, CSS scroll snapping has gone through numerous improvements and patches. Today it is a fairly reliable way of building scrollable components without a lot of JavaScript.

This is what it looks like in its most basic form (not that you would ever build a carousel... right?):

.scroll-container {  scroll-snap-type: x mandatory;  & > * {    scroll-snap-align: start;  }}

There are a lot more interesting things you can do with scroll snapping, especially when combined with some of the other properties mentioned above. Did you know you can use it to build a stories component or a sliding menu?

I also highly recommend watching Adam Argyle's excellent talk titled "Oh Snap!" to see even more cool things that you can do with scroll snapping.

Conclusion

I could rant about scrollbars all day, but that wouldn't be very respectful of your time. So if you've managed to come this far, I just want to say thanks for reading and I hope this inspires you to go forth and build better scrolling experiences. If you have any thoughts/questions, feel free to reach out! 👋

A small but familiar example of this is using media queries to change the layout based on screen width. A more modern example is using the prefers-color-scheme query to set light or dark theme.

But those are just bits and pieces. For full-blown user-adaptive design, you can look at Material You.

"If done correctly, the user may never know that the interface has even adapted" - Adam Argyle on building user-adaptive interfaces.

Most interfaces that I build these days tend to be adaptive (to the best of my ability). Not only does this result in a better experience for the user, but it's also less mental overhead for me. Instead of picking a font, I can just use system-ui. Instead of finding the perfect button height that works for mobile and desktop, I can just adjust spacing based on the pointer media query.

There's also CSS system colors (e.g. Canvas, CanvasText) that can be used to theme parts of the UI without hardcoding a shade of black or white. Jim Nielson wrote about this last year.

But there is something missing.

Every modern interface needs some kind of accent color. Without one, your website would look very dull. Unless that is your brand and you know you can pull it off (looking at you, Heydon 👀).

CSS does have an accent-color property for changing the color of some native form controls, but you, the designer/developer, are still responsible for picking the actual color (on most platforms anyway). To me, this usually feels like an unnecessary decision that I would rather leave to the user. Many of my UIs fall under affirmative design, and I don't need a strong brand identity. I just want the user to feel at home.

All modern operating systems (except notably iOS) let you pick an accent color, which is then used throughout the OS in different places. macOS even uses it as the default accent-color of native browser controls and text selection. But that only goes so far, as there's no way to use that value to build a custom CSS component.

Which is why we need... 🥁 Accent. Or AccentText or AccentColor. The name doesn't matter. What's important is that this value is set by the user.

Combined with relative color syntax, this would open up so many possibilities. Imagine extracting a whole palette of colors from the user's preferred hue, and delivering a super polished interface using that.

:root {  --accent: Accent; /* <-- I want this */  --accent-1: hsl(from Accent h s 20%);  --accent-2: hsl(from Accent h s 40%);  --accent-3: hsl(from Accent h s 60%);  --accent-4: hsl(from Accent h s 80%);}

All that to say, I just want the sites I use to show me a hint of purple 🥺

Update (6/22/2022): Bramus has informed me that AccentColor and AccentColorText have been added to the spec! This is amazing news 🥳

In this post, I will be going over some of the interesting decisions I made when building wordel. Are you excited? Because I am.

But first...

The problem with Wordle

Wordle is delightful at its best, but it is famously inaccessible in pretty much every way. Even the built-in "high contrast mode" has extremely poor color contrast 😬

The worst part is that the inaccessibility of Wordle extends beyond the player. I'm talking, of course, about the emoji grid that gets dumped on social media. It is painful for screen reader users to go through those tweets full of emojis.

Anna E Cook wrote a wonderful piece going over this in more detail, which I highly recommend reading if you like sharing your results on social media.

And those are just two of the most obvious problems with Wordle. There's a lot more, but I'd rather talk about what I did than complain about The New York Times not using a fraction of their millions of dollars to make this game more inclusive.

Enter wordel

Let's get the name out of the way first. It's not a typo. I just like writing wordel. All lower case. Pronounced the same as Wordle (even by screen readers). Don't ask me why.

Now for the fun parts.

Accessible right from the beginning

When building something from scratch, you have the opportunity to consider accessibility at every step of the way. And that's exactly what I did!

Note: I spent a fair bit of time testing all these things through screen readers, keyboard navigation, emulations, etc. While it all worked fine in my testing, I may have still missed something. If you find any issues, I'd love to hear from you so I can fix them

Colors

Choosing accessible colors is a relatively easy task. I tried to meet a contrast score of 7:1 (AAA) in most places. The WebAim Contrast Checker is a great website for comparing colors and for learning about color contrast in general.

Additionally, it is important to make sure the app is accessible to folks with color vision deficiencies. So I added small checkmarks next to the correct (green) letters.

Lastly, I should also mention Windows forced high contrast mode. The linked article does a great job explaining how to support this mode, but it basically just involves making sure borders are present around elements, and using forced-color-adjust: none in some places (e.g. the letter backgrounds).

Semantic HTML

Building from scratch, without any component libraries, gives you complete control over your markup. That means I was able to use semantically correct HTML elements in every component, instead of creating a div soup. Here are a few examples:

• The page layout is split into <header> and <main>.
• The word guess uses a real <input> element that can be typed into using the device keyboard.
• For the guess distribution, I use the <dl>, <dt> and <dd> element, which creates semantic name-value pairs.
• I make use of the <output> element in a few places (e.g. toast notifications), which automatically announces updates to screen readers.
• I use <button> for a button and <a> for a hyperlink (revolutionary, I know), even if they look exactly the same.
• I use the native <dialog> element which has automatic focus management, speaking of which...

Focus management

It is important to make sure focus behaves properly in your app for it to be accessible to keyboard users (which often includes sighted users too). This usually just means having a sensible tab order with visible focus styles, but sometimes involves manually moving focus around.

Using semantic elements, like I did, can get you pretty damn far. So it's really impressive (and not in a good way) that the original Wordle has literally no tabbable elements!

Anyway, there are two places I had to manage focus:

• I mentioned I'm using a real <input> element for the guess, but it is visually hidden (and replaced with the letter grid which shows the typed value from the input in big bold letters). Normally you shouldn't visually hide focusable elements, but I think it's fine here because this is the only focusable element on the main page well, there are multiple of these <input> elements, but only the current guess is active and the page is not scrollable. So the only thing left is to make sure this input gets focused, which I'm doing manually by calling .focus().
• I also mentioned that the native <dialog> has automatic focus management, i.e. it automatically moves and traps focus inside the dialog. But my dialog has two screens, so I need to manually move focus when the screen changes.

Emoji grid

What to do with the infamous emojis-as-results? Inaccessible to screen reader users, but sighted users love them. Well, we can get the best of both worlds.

I'm showing the emoji grid but disabling text selection on it, and not providing any easy way to copy the emoji text. Instead, I have a button which copies the "alt text" that describes the results of the game. The expectation is that the player will screenshot this emoji grid and share it on social media (or IMs) with the alt text that's already in their clipboard.

Tech stack

Let's talk tech! I wanted this to be lightweight, fast and have a good development experience, which is why I chose the following technologies:

• Preact: I keep hearing how awesome Preact is, so I went with it. I'm super comfortable with React, but it would have been overkill for this little project, so Preact was a great fit. Why not something like Svelte? Well, I didn't want to learn a new framework. 🤷

• TypeScript: Many influential people will tell you to stay away from TypeScript for small, fun projects. But the thing is, I really enjoy using TypeScript (usually). It leads to fewer bugs, it offers better developer experience, but above all, it makes me feel... safe. 🥺

• PostCSS: These days you can get very far with just vanilla CSS. There is no need for styled-components in a small project like this. I didn't use any component libraries because I didn't want new dependencies, and I was actively avoiding Tailwind because I enjoy writing real CSS syntax. So the only thing left is PostCSS, for nice things like autoprefixer. And with postcss-preset-env, I even get to use nesting (without Sass!) 😮

• Vite: This one's a no-brainer. Vite has an official template for Preact + TypeScript, and it provides a super fast development server with esbuild. Plus, I was able to easily add vite-plugin-pwa to generate a service worker for free! 🥳

• eslint + prettier: Both of these are are worth mentioning, even though they are part of literally every project I work on. It took me longer than it should have to get eslint working because TS+preact+prettier requires a very specific combination of rules in the eslintconfig. But it's worth it, even if only for two things: enforcing Rules of Hooks and auto formatting on save. 👍

Performance

Since the app and the components are so small, it's hard to have any performance issues.

Worth mentioning though, is the bundle size which is around 60KB, including the huge list of words and all assets. This is all thanks to using Preact and avoiding any other dependencies.

Just for fun, here's what the network tab looks like on a fresh load:

And here it is on subsequent loads, with all the service worker magic:

Polyfill

I didn't go over any code snippets anywhere, but I should show you how I'm conditionally loading the polyfill for the <dialog> element only in older browsers.

(async () => {  if (typeof HTMLDialogElement !== 'function') {    const css = document.createElement('link');    css.href = 'https://unpkg.com/dialog-polyfill@0.5.6/dist/dialog-polyfill.css';    document.head.appendChild(css).rel = 'stylesheet';    await import('https://unpkg.com/dialog-polyfill@0.5.6/dist/dialog-polyfill.js');    dialogPolyfill.registerDialog(document.querySelector('dialog'));  }})();

That's a dynamic import from a CDN. Browser support for dynamic imports is surprisingly good, so I can just throw that in a <script> tag in my index.html. Pretty neat.

Wrapping up

And there you have it. An accessible, and dare I say beautiful, version of the word game we all know and love. Because there is no reason a word game shouldn't be inclusive.

You can play wordel at https://wordel.app and find the source code at https://github.com/mayank99/wordel.

Until next time 👋

Problems

Personally, I mostly like it, even if only for the inclusion of dark mode. From my initial experience, I've found only two things that I would change:

• Currently, the dark mode uses hsl(250deg 13% 9%) as the background color, which creates a bit too much contrast.
• The new browser compatibility section doesn't present enough information at first glance.

And I'm not the only one who finds both of those things problematic. There have already been github issues created: mdn/yari#5378 and mdn/yari#5366.

Solutions

So while these issues will probably get fixed, we don't need to wait. With the help of browser extensions, we can take matters into our own hands. I'm going to show you what I did, but you can easily extend this approach to do all kinds of fancy stuff.

CSS: Changing the background color

I already use the Stylus extension to inject userstyles into many websites, so this one was extremely simple.

All I needed to do is slightly change the value of the --background-primary CSS variable.

:root {  --background-primary: hsl(250deg 15% 20%);}

JavaScript: Adding a link to caniuse

Like every other frontend developer, I love caniuse.com, so I thought "why not just include a link to caniuse in the MDN page?"

So I wrote a userscript that I am injecting into MDN pages using Tampermonkey. I will include the code below, but all it does is:

1. search the MDN page title on caniuse.com
2. get the url to the top search result
3. visit the url and parse the browser compatibility percentage
4. on the MDN page, add an anchor element that links to the above url and displays the percentage

Here's what the result looks like:

And here's the code (feel free to modify it as you see fit):

// ==UserScript==// @name         Add caniuse link to MDN docs// @namespace    http://tampermonkey.net/// @version      0.1// @description  searches the feature name on caniuse and adds the % and link to the BC section// @author       You// @match        https://developer.mozilla.org/en-US/docs/Web/*// @icon         https://www.google.com/s2/favicons?sz=64&domain=mozilla.org// @grant        GM_xmlhttpRequest// @grant        window.onurlchange// @connect      caniuse.com// ==/UserScript==(async function () {  'use strict';  async function addCaniuseLink() {    const browserCompatHeading = document.querySelector('#browser_compatibility');    if (!browserCompatHeading) return;    const featureName = window.location.pathname.split('/').at(-1);    const searchUrl = `https://caniuse.com/process/query.php?search=${encodeURIComponent(featureName)}`;    const caniuseUrl = await new Promise((resolve, reject) => {      GM_xmlhttpRequest({        url: searchUrl,        method: 'GET',        onload: ({ response, status, responseType }) => {          if (status !== 200) reject('oopsie');          resolve(`https://caniuse.com/${JSON.parse(response).featureIds[0]}`);        },      });    });    const compatPercent = await new Promise((resolve, reject) => {      GM_xmlhttpRequest({        url: caniuseUrl,        method: 'GET',        onload: ({ response, status, responseType }) => {          if (status !== 200) reject('oopsie');          const dom = (new DOMParser()).parseFromString(response, 'text/html');          resolve(dom.querySelector('.support').textContent);        },      });    });    const caniuseElement = `      <a        class='external'        href=${caniuseUrl}        style='font-size: 1.5rem; font-weight: 300; line-height: 1.5; position: absolute; inset-inline-end: 0; display: inline-flex; align-items: baseline; color: var(--text-secondary);'      >        <span style='font-size: 0.8rem; margin-inline-end: 0.25rem;'>caniuse</span>        ${compatPercent}      </a>    `;    browserCompatHeading.style.position = 'relative';    browserCompatHeading.insertAdjacentHTML('beforeend', caniuseElement);  }  await addCaniuseLink();  window.addEventListener('urlchange', addCaniuseLink);})();

Conclusion

And there you have it. Hopefully goes without saying but this approach of modifying websites on your end is very fragile. Your code will probably break in the future, especially if the site gets updated regularly. But I choose to do it anyway just because it's fun. 😅

But maybe it sounds too daunting to learn a whole programming language just to enhance your CSS. Turns out that most use cases can be reduced to just a handful of "recipes". In this post, I will show you some of those common recipes and how they can help you take your UIs to the next level.

This post is meant to be beginner friendly (including for designers who haven't used JS much), so you may already be familiar with a lot of the content in here. I encourage you to use the table of contents to skip to the parts that interest you the most.

Basics ("ingredients")

We'll start with some very simple recipes (you can even think of them as "ingredients" for the advanced recipes). You can try these in the browser console.

Accessing DOM elements

DOM elements represent html elements such as <button> and <div>. The webpage itself is represented by document.

There are many ways to access a DOM element, but my favorite way is to use the built-in querySelector and querySelectorAll functions. Both of these functions accept a CSS selector as the argument, and can be called from document or even from another element. querySelector returns the first instance of the selector that it finds, whereas querySelectorAll returns a list of all instances of that selector.

In the example below, we find the first <section> element in the page and store it in a variable called firstSection. Then inside that section, we find all <button> elements with the class .text-button and store them in a variable called textButtons. Since this is an array, we can then access the individual buttons from it.

let firstSection = document.querySelector('section');let textButtons = firstSection.querySelectorAll('button.text-button');let firstTextButtonInSection = textButtons[0];

There are also a couple special elements which you don't have to query for: document.documentElement will give you the <html> element, and document.body will give you the <body> element.

You can access the parent of an element (let's say the element is stored in a variable called el) using el.parentElement and you can access its first or second child using el.children[0] and el.children[1] respectively.

Lastly, you can create an empty DOM element such as <div></div> using document.createElement('div').

Modifying DOM elements

Now that we have access to the elements, we can make changes to certain aspects of it. For these examples, let's assume we have a DOM element in a variable called el.

Changing attributes

You can get the current attribute value using getAttribute, assign a new value using setAttribute, toggle a boolean value using toggleAttribute, and remove an attribute using removeAttribute. The following snippet shows how to toggle the value of aria-hidden using a ternary operator. We can't use toggleAttribute in this case because aria-hidden is not a boolean attribute.

let oldVal = el.getAttribute('aria-hidden');let newVal = oldVal === 'true' ? 'false' : 'true';el.setAttribute(`aria-hidden`, newVal);

In many cases, you can actually access the attributes directly using dot notation. For example, you can make a checkbox use the indeterminate state (which is only possible using JavaScript):

let el = document.querySelector('[type=checkbox]');el.indeterminate = true;

However, with this method, the attribute names are camelCase instead of kebab-case.

el.ariaHidden = 'true';

There is also a special way of accessing data-* attributes: using dataset. The following snippet sets data-active="true" on the element.

el.dataset.active = 'true';

Changing styles and class names

Possibly the most common thing you would want to do is programmatically change the styles or class names.

The following snippet is the equivalent of setting style="color: rebeccapurple; background-color: thistle" on an element.

el.style.color = 'rebeccapurple';el.style.backgroundColor = 'thistle';

This is particularly useful when combined with CSS custom properties which you can manipulate with getPropertyValue and setProperty. The following snippet reads the old value of --x, converts it to a number and increments it, then sends the new value back the --x.

let oldX = el.style.getPropertyValue('--x');let newX = Number(oldX) + 1;el.style.setProperty('--x', newX);

For accessing class names, we have two ways: className will give you a single value where all the class names on an element are separated by spaces, and classList will give you a list of those classes. I prefer classList because it provides a way to easily add/remove/toggle classes.

el.classList.add('new-class');el.classList.remove('old-class');el.classList.toggle('is-active');el.classList.toggle('is-active', true); // force this class to be present

Changing inner content

For accessing the inner text of an element, you can use textContent.

el.textContent = 'hi';

You can add a new element inside another element using appendNode. This is useful if you programmatically created an element using document.createElement.

let newChildEl = document.createElement('div');el.appendNode(newChildEl);

You can also replace the entire markup of an element using innerHTML but be careful with this as it can create a security risk.

el.innerHTML = '<div>hi</div>';

Recipes

Now that we know how to manipulate the DOM, we can start doing more advanced stuff. You could try these recipes in the browser console, but you probably want to use a <script> tag or even a separate .js file. I've also included a few codepen examples showing practical uses for these recipes.

Respond to clicks

Perhaps the most common use case: make things clickable. You may already be doing this today by adding onclick directly in your HTML. But there's a better, more maintainable approach that doesn't require you to manually add onclick to all your buttons.

Let's first define a function called handleClick that will be called on every click. For now I'm simply logging this action to the browser console, but you can do pretty much anything in here (e.g. change some styles) now that you've learned how to manipulate the DOM.

function handleClick() {  console.log('Clicked!');}

Now let's find our button and add an "event listener" to it. Every DOM element has an addEventListener function which takes two arguments: the name of the event (in this case 'click') and the name of the function (in this case handleClick).

let primaryButton = document.querySelector('button.primary-button');primaryButton.addEventListener('click', handleClick);

That's it! In fact, you're not limited to just 'click' events. You have the ability to add listeners to all kinds of events; check out the list of event types on MDN.

Toggle and store state

CSS doesn't offer much in the way of state management, so in the past you might have found yourself reaching for hacks like using an invisible checkbox. Fortunately, it's quite easy to do using JavaScript.

One of my favorite places to store state is in a data attribute, which can be easily toggled using JavaScript and also easily styled in CSS.

let button = document.querySelector('.toggle-button');function toggleActive() {  button.dataset.active = button.dataset.active !== "true" ? "true" : "false";}button.addEventListener('click', toggleActive);

[data-active="true"] {  border: 2px solid;}

Check out this CodePen where I'm using multiple data attributes and nested functions to create button groups that have independent state yet still share the same code.

Media queries

Media queries are not just a CSS thing. You can access them in JavaScript to build some really powerful UIs. To do that, you can use window.matchMedia. In the following snippet, we check if the user prefers reduced motion, access the boolean result using the matches property, and store the opposite of that result (using !) in a variable called motionOk.

let motionOk = !window.matchMedia('(prefers-reduced-motion: reduce)').matches;

We can also add an event listener that will be called every time the media query returns a new value. The following snippet will print true or false in the browser console every time the query runs.

window.matchMedia('(max-width: 500px)').addEventListener(e => {  console.log(e.matches);});

Here's a practical example showing how to change default state and colors based on user's OS theme.

Window resizing

You have the ability to add a listener on the browser 'resize' event, which will be called for each pixel change on the browser's window dimensions. I don't want to go into too much depth here for two reasons:

1. You can do a lot with just media queries (and soon container queries).
2. This method can be a bit expensive, and it is recommended to use ResizeObserver instead, although that is a bit harder to use.

But it can still be useful in some cases, so here's the syntax.

function doSomethingWithWindowSize() {  console.log(window.innerHeight, window.innerWidth);}window.addEventListener('resize', doSomethingWithWindowSize);

And here's the syntax for ResizeObserver which lets you observe dimension changes on any element (not just the browser window). Notice how we need to create a resize observer separately, and then manually call observe on the element.

let el = document.querySelector('div');let elResizeObserver = new ResizeObserver(([{ contentRect }]) => {  console.log(contentRect.height, contentRect.width);});elResizeObserver.observe(el);

Detect scroll position

This is a fun and powerful one, as it opens up quite a few possibilities. Similar to the 'resize' event, the browser has a 'scroll' event that we can listen to. And we can get the current scroll position using window.scrollX and window.scrollY.

window.addEventListener('scroll', handleScrollEvent);function handleScrollEvent() {  console.log(window.scrollX, window.scrollY);}

You can also read an element's current scroll position by calling getBoundingClientRect() on it, which will give you access to a bunch of information about the size and position of the element. In this case, we care about the top and bottom properties (or left and right for horizontal scrolling). I like to do this in a helper function where I can cleanly destructure those properties. The following function also uses window.innerHeight to return true if either the element's top or bottom are in viewport.

function isElementInViewport(el) {  const { top, bottom } = el.getBoundingClientRect();  return top <= window.innerHeight && bottom > 0;}

Lastly, we can force the page (or even an element) to scroll to a certain position by calling scrollTo.

window.scrollTo(0, 0);

Let's look at a practical example. In this codepen, I'm adding a scroll listener to achieve two things:

• show a "scroll to top" button only after the page is scrolled down a bit
• change the "active" color in the header to match the currently visible color

Conclusion

That's all folks! I hope you enjoyed reading this article as much as I enjoyed writing it. These recipes were based on my observations over the last few years. If you feel there is a pattern not covered here that is common enough in your workflow, I'd love to hear about it.

Background

If you're unfamiliar, :focus-visible allows you to get rid of the annoying focus outline on mouse clicks, while letting you specify the focus styling only for keyboard users (as well as other "tabbing" devices like joysticks)

2021 was a good year for this pseudo-class:

• Firefox shipped focus-visible.
• Chrome and Firefox both started using it for default focus styles in their User Agent stylesheets.
• And now Safari is on the cusp of shipping it.

What's wrong with the popularly suggested fallback?

Maybe you're using the polyfill (hopefully not) or maybe you're using Patrick H. Lauke's CSS-only fallback (or even the two in combination).

  :focus {    /* your custom focus outline */  }  :focus:not(:focus-visible) {    /* undo the focus styling for mouse users */  }

There are two main problems with this "undo" approach. First, it increases the specificity, which can have unexpected consequences if you rely on the cascade, for say, defining hover styles later. Fortunately you can fix the specificity problem using the :where pseudo-class, which has similar browser support.

Here's a codepen to demonstrate. Try tabbing through the 3 buttons. Then try clicking and hovering on them. You'll notice that the first button does not respect its :hover and :active rules after it's clicked.

The second problem is with code complexity. Undoing focus styling is not trivial, especially if you've taken the extra care to make your component look beautiful in its various states. This problem gets compounded with every new state that you add to your component. Even a seemingly innocuous component like a button can have tons of extra states active, active + focused, disabled, disabled + focused, and so on.

Using :focus-visible directly

Since this is still a fairly new feature, you might feel like it's not ready to start using just yet. However, there is good news if you know these two bits of trivia:

1. Safari already uses :focus-visible-ish logic for buttons and anchor links. That's right, buttons and anchors are not click-focusable in Safari, so regular :focus styles will only be visible to keyboard users.

2. The @supports rule can test for a selector. It is fairly new, but has decent browser support (compare stats with your user base as always).

This means you can write code like this:

button:focus-visible {  outline: 2px solid rebeccapurple;}@supports not selector(:focus-visible) {  button:focus {    outline: 2px solid rebeccapurple;  }}

Buttons and anchors make up most of the interactable web, so using this trick will get you most of the way there. For text inputs, there is no difference between :focus and :focus-visible behavior, so that's a non-issue. What remains is the custom interactable elements defined using tabindex=0. Those will still continue to behave as they have, until Safari users can get their hands on :focus-visible.

In older browser versions where neither :focus-visible or @supports selector is supported, the default focus ring should show instead. Now that's progressive enhancement without any compromises.

Sass mixin

Since we are duplicating the focus outline styles, there is an opportunity for creating a "helper" of some sort. We can define a handy Sass mixin, utilizing a @content block to defer the actual styles to the user of this mixin.

@mixin focus-visible {  &:focus-visible {    @content;  }  @supports not selector(:focus-visible) {    &:focus {      @content;    }  }}

Now we can use it throughout our codebase without duplicating any focus styles.

button {  @include focus-visible {    outline: 2px solid rebeccapurple;  }}

Sweet!

What about :focus-within?

The last piece of the puzzle is :focus-within. While a little niche, you may have used it before. It's especially handy for giving forms an extra bit of polish. Unfortunately, there is no :focus-visible-within. However, with the :has() pseudo-class (which is already available in Safari now!), this will be a trivial matter as you'll be able to just use :has(:focus-visible).

Update: Safari 15.4 is now shipping :focus-visible! 🥳