Everyone is exited about CSS Nesting but are you ready for it? Answer the below quiz 👇

What would be the result of the following code (without cheating! 😈)

“`
body {
@media all {
background: red;
}
background: blue;
}
“`

No spoil in the comments!#CSS

— T. Afif @ CSS Challenges (@ChallengesCss) June 13, 2023

Take a moment to come up with your own answer (or vote), then read on.

Now, I initially got it wrong. Here was my thinking pattern:

1. @media doesn't add specificity, so both declarations have a specificity of 0,0,1
2. background: blue comes later, so it wins

But no, the background is red! It turns out that has to do with the way browsers transform your nested CSS rules to individual rules it can apply. So lets dive into how browsers do that.

A related gotcha, :is()

Last week was CSS Day (which was amazing) and of course a bunch of the presentations mentioned CSS Nesting. Unfortunately, some had a simplified explanation of how rules get resolved.

The & in nested CSS isn't just replaced by the ancestor, which is what you might think, but it's ancestor is also wrapped in :is():

body {
    & div {
        ...
    }
}

/* Doesn't become this: */
body div { ... }

/* It becomes this: */
:is(body) div { ... }

Now that doesn't sound like there is much of a difference between body div and :is(body) div, indeed both have a specificity of 0,0,2, but remember that:is() takes on the highest specificity of the selectors in it. So when you have the following:

main, #intro {
    & div {
        ...
    }
}

The resulting selector, even when targeting a div in main, ends up as:

:is(main, #intro) div { ... }

Which makes it go from 0,0,1 for main div to 1,0,1 making it vastly more specific. That gotcha gets lost when examples fail to include the way ancestors are wrapped in :is() (and yes, they also nest :is()!)

Back to the original gotcha

So back to the challenge up top. You can intermingle properties and nesting. You shouldn’t to keep your code readable, but the following CSS works just fine and applies all the styling:

body {
  filter: blur(5px);
  
  @media all {
    background: red;
  }
    
  background: blue;
  
  @media all {
    color: deeppink;
  }
  
  rotate: 20deg;
}

It's when the browser parses this CSS into individual rules that the sneaky thing happens:

1. The browser adds a new ruleset, body, and starts adding the properties to it/
2. The browser then adds another new ruleset for the nested media query and starts adding its properties to it/
3. When it exits the nested media query, it adds the rest of the properties to the original ruleset again until that is exited.

So if we look at this CSS again:

body {
    @media all {
        background: red;
    }
    background: blue;
}

That actually resolves to these two rules in this specific order:

body {
    background: blue;
}
@media all {
    :is(body) {
        background: red;
    }
}

Now from this CSS, it makes more sense that red wins. It has the same specificity but it comes after the first rule so it wins. And that's the gotcha.

This post originally claimed that only @-rules could be intermingled with properties but this was incorrect. Thanks @ChallengesCSS for correcting me.

I first encountered this issue with ::backdrop: Backdrop doesn't inherit from anywhere but after a recent rendering engine update to Polypane I noticed that all my custom selection colors (also powered by CSS custom properties) suddenly stopped working.

Turns out, ::selection is also not supposed to inherit styles, and Chromium 111+ is running an experiment to see what effect changing that has. Polypane runs with experimental features turned on, and so my selection styles became broken.

This is going to catch a lot of people off-guard because I, like many others, expect CSS Custom properties defined on :root to just be available everywhere.

So if :root isn't global, what is?

Well, the jury's still out.

Discussions are happening in this GitHub issue: Custom properties on :root with a few options being discussed:

• Use @property with an initial value (not cross-browser supported yet, only uses the initial value).
• Make :root special.
• Create a new :document pseudo-class that does propagate custom properties.
• Create an new at-rule called @global, @root or @document that you could define custom properties in.
• Make ::selection etc inherit from their originating element (e.g. "their parent").

That last item would solve both the problems people run into (it not inheriting, and it potentially inheriting directly from :root so you can't overwrite custom properties in the cascade). I hope spec writers choose to do this regardless.

Specifically, I want/expect this to work:

p {
    --selection-bg: #0f0;
    &::selection {
        background: var(--selection-bg);
    }
}

When it comes to "a place to store global variables" I have no strong opinion, though I think it's interesting to keep in mind that in JavaScript there is now window, global and globalThis because the naming across contexts didn't work.

In that light, :document or @document seem potentially problematic. For that reason, I like @global or :global (I haven't actually seen :global as a pseudo-class suggested yet, but it seems to be closest to how people expect things to work now).

In the mean time, you can use the suggestion I made in my ::backdrop post and replace :root { } with :root, ::backdrop, ::selection { }. Sorry about that.

When you have a piece of business logic, frequently that depends on a a certain value being true. An if statement:

if ( status === 'active' ) { … }

This is easy to parse for me and I can quickly see what it does. What often ends up happening though is that the business logic gets a second possibility, for example status being active or status being trialing:

if ( status === 'active' || status === 'trialing') { … }

This is still relatively easy to read but there’s repetition with ‘status’ and I always need a second to think about the difference between || and && to understand the behavior. So whenever I move from checking from one value to more than one, I switch to a different pattern:

if (['active', 'trialing'].includes(status)) { … }

I make an array of all possible values and then use Array.includes() to check if the status is contained in that array.

This pattern comfortably grows to many items and can also more easily be read aloud, helping understanding.

There is no repetition so as a small bonus it’s shorter. It has also helped me learn the difference between includes, contains and has.

Partial string matching

I get a lot of mileage out of the above pattern, but it only works when you’re matching the full string. Sometimes you need to check just the beginning or the end of a string and then .includes() won’t cut it because it only accepts values, not a function.

We don’t want to go back to multiple checks and the repetition that gives so if we need to check for a part of the string we need to change the function we use:

if (
  ['http://', 'https://', 'file://', 'www.']
    .some(s => clipboard.startsWith(s))
) { … }

Array.some() takes a function and returns a Boolean. It’s a little longer but we’re still not repeating ourselves. A nice benefit is that like includes() it will stop evaluating when it returns true, so we usually don’t have to loop over all the elements.

In the examples above I inlined the array but of course you can also store it in a global variable. That gives you the additional benefit of only instantiating a single array that you can reuse and that lets you update many checks in one go, should the business requirements change.

As I said, I get a lot of use out of this pattern. I hope this helps you recognize when it’ll be useful in your code in the future!

To me it was clear that they served different purposes: one was to indicate a preference for an implemented design, just with more (or less) contrast, the other wanted 100% certainty that their colors were respected. Clear difference, clear implementation.

Except that turned out to be wrong.

While macOS sees prefers-contrast as a discrete thing, the spec (and Windows) intricately links it to forced-colors. There, prefers-contrast:more matches when forced-colors with a high contrast theme is active, and prefers-contrast: custom is active with a contrast theme that has anything other than a full black or white background.

So now I’m left wondering: What on earth do spec makers expect website builders to do with prefers-contrast? If forced-colors already overwrites all the colors, what contrast is there left for us to change?

prefers-contrast is a useless media query, and I don't understand why.

This isn’t the first time I’ve voiced concerns about prefers-contrast: earlier versions of the spec had a forced value that would match only when forced-colors was active. I thought this was a really dumb idea, wrote about it and to my surprise, the forced value got removed from the spec. Victory!

…Except they put it back as custom and apparently retooled the entire media query to match with forced-colors: active.

Worse still, the spec only mentions this in the forced-colors section, while the prefers contrast section only mentions prefers-contrast: custom matching when forced-colors: active matches. Under forced colors however, this is what the latest version of the spec says:

In addition to forced-colors: active, the user agent must also match one of prefers-contrast: more or prefers-contrast: less if it can determine that the forced color palette chosen by the user has a particularly high or low contrast, and must make prefers-contrast: custom match otherwise.
Similarly, if the forced color palette chosen by the user fits within one of the color schemes described by prefers-color-scheme, the corresponding value must also match.

Contrast this to what the version before it said:

The UA will provide the color palette to authors through the CSS system color keywords and, if appropriate, trigger the appropriate value of prefers-color-scheme so that authors can adapt the page.

That's a whole new section essentially fusing prefers-contrast to forced-colors.

Coupling forced-colors and prefers-contrast like this completely breaks the ‘contract’ that the prefers-* prefix gives: a user has preference and it’s up to you to implement it. This is in contrast to other media queries, like width and, indeed, forced-colors, that tell us that something is a more intrinsic state of the device being used to access your site.

Prefers-* in media queries is no longer something you can depend upon, and CSS is a little bit less explainable and a little less consistent.

Why do this?

I have no idea why they decided this was a good idea. Maybe the spec makers are confused by the name of ‘contrast themes’ on Windows and decided that contrast is contrast and no further research was needed?

I also have no any idea what to do with prefers contrast. It exists, and there is literally no reason to use it on its own.

This is doubly annoying for macOS, which has a very clear implementation for prefers-contrast: more. If you want to adapt your design for macOS, you can no longer use just that. You need to check if prefers-contrast: more is active, and if forced-colors isn’t:

@media (prefer-contrast: more) and (forced-colors: none) {
    /* Only now can you apply styling for the macOS implementation */
}

No one is going to do that, and the spec makers know this because "adoption being low" is a common argument made by the CSS working group against any new media queries (like prefers-reduced-complexity, which is also tacked onto prefers-contrast by using it without a value). Usage being low is a great way to stop any discussion dead in the water, and is far from consistently applied throughout the specs being written.

So that leaves me with this: I no longer understand prefers-contrast. I can’t explain why you would use it, I don’t know who it’s for or what developers are expected to do with it. Do you?

December 2023 update! The specification got updated to say that ::backdrop inherits from “it’s originating element” (the dialog in this article). The change has been made it all three browser engines, but currently hasn’t shipped yet. Thanks @Schepp for letting me know.

February 2024 update! The specification update is now live in Polypane 18, Chromium 122, Safari 17.4 and Firefox 120!

Earlier this month I was implementing a lightbox for devtoolstips.org using <dialog>. I'll be writing about that soon but you can find the implementation in that link, it's remarkable how little code you need. While styling, I made use of the CSS custom properties that where already defined in the CSS to style the dialog and it's backdrop. Or so I thought.

For some reason, the color of the backdrop wasn't what I expected, even though devtools picked up the right css var being set. It was just that the CSS var was not define. This puzzled me because it was clearly defined earlier in the CSS under the :root selector. So why couldn't devtools find it?

Turns out ::backdrop doesn't inherit from anywhere. It says so clearly in the spec:

"It does not inherit from any element and is not inherited from."

And honestly, that's pretty annoying. You'll either have to duplicate your vars in a specific declaration for ::backdrop, or add ::backdrop to your :root declaration containing all your CSS vars:

:root, ::backdrop {
    --my-var-1: #fff;
    --my-var-2: #000;
}

If you use :root only to set CSS vars this isn't that much of an issue, but since it targets the html element anyway, I usually also add my page styling straight away.

Both the ::before and ::after pseudo elements behaved like this in the past though those got updated, and I'm not sure why the same hasn't been done for ::backdrop, it seems like an oversight.

In any case, Florens came up with the idea of introducing a :globalThis in CSS, similar to globalThis in JavaScript, which just always refers to the global environment, be it window, global or something else. That would be a great solution for the use case of CSS custom properties that you just want available throughout your CSS. We can dream.

Anyway, now you know to look out for this situation.

Spread the word

Feel free to share this tweet or toot to tell other people.

You can find the episode and show notes here: Supper Club × Polypane with Kilian Valkhof. Fingers crossed someone can help me and Scott out with my “Sick Pick” ;)

As you’ve probably read elsewhere by now, that feeling obviously didn’t stay with me.

Still, I’ve pondered writing an article of my own. The run-up to the conference was full of red flags that I could write up that would’ve been somewhat interesting as a cautionary tale.

My interactions with the organiser, a woman named Gen Ashley, had been few and always somewhat antagonistic. At the time I thought it was just a result of the huge undertaking a conference like this is. I myself also aren’t the kindest person when under stress. Whatever, we’re all human.

But my experience has been far easier compared to what other speakers, all of the attendees and sponsors had to go through.

I got lucky. I got my travel and hotel paid for. I had a full room listen to me. I very much enjoyed meeting people I had only interacted with online before and chatting with speakers and attendees I hadn’t known before at all. I’m Dutch, so any lunch that’s above a piece of bread with a slice of cheese just registers as “fancy” in my head. I can’t help it. A cheese sandwich with green bits sticking out of it? Boom. Fancy.

I decided pretty early on (honestly, after Cassie bowed out and the red flags really started stacking up) to accept whatever was gonna happen and make the best of it. As a speaker, I owe that to every person that comes to listen to what I have to say.

Others weren’t as lucky as I was. Speakers paid out-of-pocket based on the promise of speaking in front of hundreds, if not thousands of people, and ended up speaking to a few. Attendees paid upward of 600 pound to attend, for something that should’ve been a year-closing celebration of the web community. Sponsors likewise anticipated interacting with thousands of devs, and from what I’ve understood, paid in accordance.

I can underwrite everything Cassie, Jo, Hidde, Kent, Todd, Niamh, JD, Chris, Mike, Vladyslav, Patty, Dylan and James have said, and want to explicitly focus your attention to Cassie and Jo, who very early on made very clear statements, risking ire and being labeled troublemakers (they’re not, except in the very best way!) They’re brave and we owe them.

So go and read the experiences linked up there. None of them are exaggerated. What happened was disgraceful and fraudulent. The only reason the conference went as smoothly as it did was that every single speaker decided to be there for the attendees and give their best, even if that did mean managing essentially everything not handled by the conference center.

The reason I ended up writing something anyway is because the organisers next event is already lined up, and it looks like they’re gonna try and do the same trick again. It’s called tech(k)now day.

You should probably not go there.

And that sucks, because it has a fantastic, all female (and non-binary) lineup. Hosting a conference featuring and celebrating an underrepresented group is admirable and awesome, but only if you don’t exploit that group at the very same time. It seems she’s treating them as poorly as she did some of the speakers at Modern Frontends and they don’t deserve that.

They deserve better, and we as a community also deserve better. So don’t let her get away with it.

Screencapture

Screencapture is a command-line interface to all the screenshot and screen capturing tools that are built into macOS, and that will let use screenshot VoiceOver because you can create a screenshot with a delay using the following:

$ screencapture -T10 filename.png

-T is the command line flag to set a timeout, and 10 is the number of seconds it should wait. Lastly, filename.png is what it should save the resulting screenshot as. If you don't want to save, you can replace the filename with -c to copy the result to clipboard instead

Steps

1. The first time screencapture is called, your Mac will show a popup asking you if you want to give your terminal access to screen recording. Make sure to allow it, otherwise it won't be able to make screenshots.
2. Then, start a screencapture with enough time to configure VoiceOver to look the way you want it to look. I defaulted to 10 seconds, you might be faster.
3. Open VoiceOver (cmd + F5) and then open the Rotor (ctrl + alt + u) and use the arrow keys to go to the view you want to show.
4. Wait until screencapture is done, find your image in the folder you saved it in.

Unfortunately I haven't found a way yet to capture just the Rotor as an image, because when you configure screencapture to capture a window instead (with -W) the timeout is discarded. So the above will make a screenshot of your entire desktop, and you'll have to crop it yourself.

If you've been photographing your mac screen to get images of VoiceOver in action, I hope this helps! To get an overview of everything screencapture can do, you can execute screencapture -h to show the help page.

Update: capturing just the Rotor

After sharing this in the Fronteers Slack community, Gijs mentioned there was a way to capture the rotor as a standalone image:

• Open VoiceOver (cmd + F5).
• Press shift cmd 4 to start a screenshot capture.
• Press Spacebar to switch to Window mode.
• Open the Rotor (ctrl + alt + u) and navigate to desired dialog with arrow keys
• Hover over the rotor with the mouse so it turns blue (indicating it’s selected for the screenshot).
• Click or press enter to capture screenshot.

This definitely works but it’s also very finnicky. If you do anything out of order you will either not be able to switch to window selection mode or you won’t be able to navigate in the rotor. Making a screenshot with a delay is a little more forgiving, but you won’t end up with an image of just the rotor.

Another update: Screenshot tool in Dock

This one is by Sylvia

• Open Launchpad
• Search for Screenshot
• Drag the Screenshot tool to your dock
• Open Rotor in VoiceOver
• Click on Screenshot-Tool in your dock
• Make a Screenshot with this tool

Thanks Sylvia!

Of course, it's a button! Because it opens the theme selector at the top of the page. It does something! Add an aria-expanded to the button, make sure focus is set and you're good to go. It's obviously a button.

But what if it's not?

After Manuels excellent talk I was discussing this with a group of folks and I was adamant that it obviously was a button because it clearly opened a thing but… I didn't have a great argument for why it also couldn't also be a link. After all, all the arguments for a link are pretty sound. It stuck with me and in this article I want to explore both.

When to use links and buttons

The "common" logic for when to use links or buttons is as follows:

1. If it goes somewhere, it's a link.
2. If it does something, it's a button.

But if you ask me, those two things aren’t always mutually exclusive. I'll give implementation examples of both that I think are fine.

What we're building

The functionality we're building is the following: The top right button on mxb.dev opens a theme selector at the top of the page, and the theme selector has a close button that closes it again. That's it. Here's a video:

Using a button

This is the example Manuel gave and it's essentially the same as what I wrote in The perfect responsive menu.

The button looks like this:

<button aria-expanded="false" aria-controls="theme-selector">
    Open Theme Selector
</button>

and the theme selector looks like this:

<div id="theme-selector" hidden="true">
  … pretend there's a theme controller here
  <button aria-expanded="false" aria-controls="theme-selector">
    Close
  </button>
</div>

Then when clicking the button, using javascript, the hidden attribute of theme-selector is removed, the aria-expanded of the button is set to true, the JS moves the focus to the theme selector and then adds some CSS makes the theme selector appear (in the live implementation it's using an additional class, but you could also use the [hidden] attribute being there or not instead).

In the theme selector, we have a close button that does the same in reverse.

Here's how it works in a codepen:

See the Pen
Button opening theme selector by Kilian Valkhof (@Kilian)
on CodePen.

Using a link

Okay, here we go. Why this can be a link: Links go somewhere, including different parts of the same page. So we can add a link that goes to #theme-selector:

<a href="#theme-selector" id="theme-selector-controller">
    Open Theme Selector
</a>

Using the :target pseudo-class, we can make the theme controller appear after clicking the link:

#theme-selector:target {
  display: block;
}

This will make the theme selector stay open while we interact with it. Inside #theme-selector we add a second link that links back to our original button:

<a href="#theme-selector-controller">
    Close Theme Selector
</a>

After clicking that, the #theme-selector no longer matches the target, so it's hidden again. You can see it in action here:

See the Pen
Button opening theme selector by Kilian Valkhof (@Kilian)
on CodePen.

What's wrong with the link solution?

The browser gives us all the building block for a link solution. It works without javascript and as far as I can tell, the accessibility is decent too: using display means the theme selector is hidden from assistive technologies and the browser itself makes sure the focus is managed.

The only things you lose is that the "button" is no longer aware of the expanded status and can’t be used as a toggle anymore. The toggle functionality I don’t have a solution for, but you could also say that now that the browser is maintaining a target that's what holds that status.

In short, it's simple, doesn't need javascript, manages focus and the link clearly goes somewhere. It follows all the rules.

So why do I still prefer the (much more complex!) button example?

Addendum

Here’s what Ben had to say about this: the above is accurate, but it’s not something he would recommend in practice for a few reasons:

• Buttons can explicitly convey the expanded/collapses state, which is useful information in itself.
• Links and buttons have different keyboard triggers (both can be triggered with enter but buttons can also be activated with a space) and if you’re a sighted used, you might expect a button and be surprised when space does nothing.

He also brought up the point of links opening in a new tab when you middle-click. Does it make sense to have that functionality on a new tab?

All in all, he helped me understand why I still preferred the button and explained it as such: links are a semantically okayish way to do this; buttons are a more semantic way to do it. Thanks Ben!

Thanks to Manuel and Ben for feedback on drafts of this article.

Two years ago I requested something similar to the Chromium team: making it possible to emulate arbitrary media queries in the devtools. At the time I also wrote about that on this blog: I want my own media queries in browsers

That never went anywhere, but this is more or less a continuation of that thought. Combining it with Kitty's imaginary "prefers-main-side", and the idea that browsers should expose media query settings on a per-origin basis like page zoom, here's an idea that would be even more amazing to have in browsers:

Arbitrary media feature support

What if a site could register a media feature:

window.registerMediaFeature({
    name: "prefers-main-side", 
    options: ['right', 'left'],
    default: 'right',
});

After which a browser would:

• Understand the media feature in your CSS
• Match the default value and apply the CSS
• Provide an appropriate toggle UI in the address bar

This doesn’t just give you more ways to offer a customized experience for your visitors, at the same time this frees up real estate on the site itself because it no longer has to reserve space to provide a fully custom UI.

It should work both for known media features, like prefers-color-scheme, completely imagined ones like prefers-main-side, or not-yet-implemented features like prefers-reduced-transparency.

Overwriting known media queries

Furthermore, it should allow overwriting the values of known media features to provide more options. For example, Twitter comes with two dark modes: "dim" and "lights out". prefers-color-scheme only has "light" and "dark", so they would extend prefers-color-scheme with a new value, and update the names to match their brand:

window.registerMediaFeature({
  name: "prefers-color-scheme", 
  options: {
    light: "Default",
    dim: "Dim"
    dark: "Lights out",
  }
  default: 'light',
});

This way, a browser could still match the OS level setting (light or dark) to the options offered by Twitter as well as provide a UI to switch to "Dim", allowing Twitter to get rid of a piece of custom in-page UI that does the same thing.

UI

The browser UI could be exposed in a dropdown similar to how Polypane has been showing it for a while, with big toggles that make it easy to see both which options have been selected as well as which options there are.

Browsers could automatically detect usage of regular media features and show those in the same UI, storing the selection per-origin. That way the choices a user made will get remembered next time they visit your site.

To prevent abuse, a website could ask for permission before they're allowed to register media features, or they could be limited to a fixed number of registered media features. Edit: Evan suggested explicitly mentioning that the options would be same-origin restricted to prevent them from being used for fingerprinting.

But that's getting ahead of myself. What do you think of the concept? Reply on Twitter with your thoughts!

Update Looks like Kitty wrote about it themselves too: Dominant hand respecting design and they came up with a very similar API (though I think their use of the CSS global is better!):

CSS.registerMedia({
  name: 'prefers-dominant-hand',
  syntax: 'start | end | no-preference',
  initialValue: 'no-preference',
})

Now we just need to get the browsers on board ;)