CSS-TRICKS

<p>This issue of What’s !important is dedicated to our friends in the UK, who are currently experiencing a very miserable 43-day rain streak. Presenting: the five most interesting things to read about CSS from the last couple of weeks. Plus, the latest features from Chrome 145, and anything else you might’ve missed. TL;DR: lots of content, but also lots of rain.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/whats-important-5/">What’s !important #5: Lazy-loading iframes, Repeating corner-shape Backgrounds, and More</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>This issue of What’s !important is dedicated to our friends in the UK (aka me), who are currently experiencing a very miserable 43-day rain streak. Presenting: the five most interesting things to read about CSS from the last couple of weeks. <em>Plus</em>, the latest features from Chrome 145, and anything else you might’ve missed. TL;DR: lots of content, but also lots of rain.</p>



<span id="more-392302"></span>


<h3 class="wp-block-heading" id="why-you-can-only-code-for-4-hoursday">Why you can only code for 4 hours/day</h3>


<p>Don’t worry, you’re only coding for 52 minutes/day anyway.</p>



<p>Dr. Milan Milanović talks about the devastating impact of meetings, emails, Slack, and interruptions, and what you/your manager can do about it. <a href="https://newsletter.techworld-with-milan.com/p/you-can-code-only-4-hours-per-day" rel="noopener">This article</a> is a real eye-opener with a ton of shocking (but not surprising) statistics about the average developer’s flow state.</p>


<h3 class="wp-block-heading" id="why-you-shouldnt-switch-to-smaller-breakpoints-too-early">Why you shouldn’t switch to smaller breakpoints too early</h3>


<p>Ahmad Shadeed explains <a href="https://ishadeed.com/article/too-early-breakpoint/" rel="noopener">why you shouldn’t switch to smaller responsive breakpoints too early</a>, with examples of websites that’ve done so and scenarios in which users might hit those breakpoints.</p>



<figure class="wp-block-video"><video height="1476" style="aspect-ratio: 2234 / 1476;" width="2234" controls src="https://css-tricks.com/wp-content/uploads/2026/02/time-layout.mp4"></video><figcaption class="wp-element-caption">Source: <a href="https://ishadeed.com/article/too-early-breakpoint/" rel="noopener">Ahmad Shadeed</a>.</figcaption></figure>


<h3 class="wp-block-heading" id="how-to-lazyload-abovethefold-iframes">How to lazy-load above-the-fold iframes</h3>


<p><code>loading=lazy</code> only works for off-screen elements, so Stefan Bauer demonstrates a neat trick for <a href="https://frontendmasters.com/blog/performance-optimized-video-embeds-with-zero-javascript/" rel="noopener">lazy-loading above-the-fold <code>&lt;iframe&gt;</code>s using <code>&lt;details&gt;</code></a>.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_RNbKYXe/a831adc966239412c0eded6aabd6b39b" src="//codepen.io/anon/embed/RNbKYXe/a831adc966239412c0eded6aabd6b39b?height=450&amp;theme-id=1&amp;slug-hash=RNbKYXe/a831adc966239412c0eded6aabd6b39b&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed RNbKYXe/a831adc966239412c0eded6aabd6b39b" title="CodePen Embed RNbKYXe/a831adc966239412c0eded6aabd6b39b" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="how-to-create-repeating-cornershape-backgrounds">How to create repeating <code>corner-shape</code> backgrounds</h3>


<p>Preethi Sam shows us <a href="https://frontendmasters.com/blog/background-patterns-with-css-corner-radius/" rel="noopener">how to use <code>corner-shape</code> in <code>&lt;svg&gt;</code>s, which are then used as repeating <code>background</code>s</a>. I’ve done <a href="https://css-tricks.com/what-can-we-actually-do-with-corner-shape/">my own experiments with <code>corner-shape</code></a>, but this is wonderful and certainly something that I hadn’t considered.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_wBWjwoj" src="//codepen.io/anon/embed/wBWjwoj?height=450&amp;theme-id=1&amp;slug-hash=wBWjwoj&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed wBWjwoj" title="CodePen Embed wBWjwoj" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="the-css-selection-2026-edition">The CSS Selection (2026 edition)</h3>


<p>What do web developers actually do with CSS? While other research studies look at features, <a href="https://www.projectwallace.com/the-css-selection/2026" rel="noopener">The CSS Selection</a> (2026 edition) focuses on CSS patterns and techniques. It’s a very interesting read, and you’ll definitely laugh once or twice, especially as you discover the different typos for <code>!important</code>.</p>



<p>Here are some of my favorites:</p>



<ul class="wp-block-list">
<li><code>!IMPORTANT</code>: too shouty</li>



<li><code>!impotant</code>: too much information</li>



<li><code>!i</code>: that’s just lazy</li>



<li><code>!imPORTANT</code>: excellent annunciation</li>



<li><code>!importantl</code>: ah, so close…</li>
</ul>


<h3 class="wp-block-heading" id="chrome-features-and-quick-hits-you-mightve-missed">Chrome features and Quick Hits you might’ve missed</h3>


<p><a href="https://developer.chrome.com/release-notes/145" rel="noopener">Chrome 145</a> shipped a few days ago, and as always, we’ve been sharing some <a href="https://css-tricks.com/category/quick-hits/">Quick Hits</a> throughout the week. You can catch these in the sidebar of the homepage, so feel free to drop by if you’re ever in the ‘hood.</p>



<p>Coincidentally, most of the Quick Hits were related to the Chrome update in some way, so I’ll recap everything together:</p>



<ul class="wp-block-list">
<li><code>text-justify</code>, which you can combine with <code>text-align: justify</code> to specify whether you want the word spacing (<code>text-justify: inter-word</code>) or letter spacing (<code>text-justify: inter-character</code>) to be adjusted to make the text justified. <a href="https://css-tricks.com/almanac/properties/t/text-justify/">Geoff wrote about this</a> way back in 2017 when only Firefox supported it (sort of…), so by my calculation, Safari should support it by 2035. So not this decade, but before GTA 6. Just kidding… (I think).</li>



<li>Speaking of word and letter spacing, <code>word-spacing</code> and <code>letter-spacing</code> now accept <code>%</code> units, as they do in Safari and Firefox.</li>



<li>Similarly, <a href="https://css-tricks.com/almanac/properties/o/overscroll-behavior/"><code>overscroll-behavior</code></a> now works for non-root scroll containers, like in Safari and Firefox. WebDev RedFox’s <a href="https://webdevredfox.org/post/lets-stop-misusing-overscroll-behavior" rel="noopener">warning about <code>overscroll-behavior</code></a> couldn’t have come at a better time.</li>



<li><code>column-wrap</code> and <code>column-height</code> for better multicolumn layouts are also here now, but only in Chrome, unfortunately.</li>



<li>That also applies to customizable <code>&lt;select&gt;</code>, arguably the most exciting feature on this list. As I shared earlier in the week, Adam Argyle wonderfully boiled down this surprisingly complex feature to <a href="https://nerdy.dev/nice-select" rel="noopener">a simple outline</a> that’s extremely easy to understand.</li>



<li>Looking a little more to the future now, it seems that we’ll eventually be able to have <a href="https://bsky.app/profile/lea.verou.me/post/3mdjbojsf6s2h" rel="noopener">multiple borders and outlines on a single element</a> as well as <a href="https://x.com/Una/status/2019502817216503824"><code>border-shape</code></a>, as demonstrated by Dr. Lea Verou and Una Kravets respectively.</li>
</ul>



<p>Until next time!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/whats-important-5/">What’s !important #5: Lazy-loading iframes, Repeating corner-shape Backgrounds, and More</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


This issue of What’s !important is dedicated to our friends in the UK (aka me), who are currently experiencing a very miserable 43-day rain streak. Presenting: the five most interesting things to read about CSS from the last couple of weeks. Plus, the latest features from Chrome 145, and anything else you might’ve missed. TL;DR: lots of content, but also lots of rain.



Why you can only code for 4 hours/day
Don’t worry, you’re only coding for 52 minutes/day anyway.
Dr. Milan Milanović talks about the devastating impact of meetings, emails, Slack, and interruptions, and what you/your manager can do about it. This article is a real eye-opener with a ton of shocking (but not surprising) statistics about the average developer’s flow state.
Why you shouldn’t switch to smaller breakpoints too early
Ahmad Shadeed explains why you shouldn’t switch to smaller responsive breakpoints too early, with examples of websites that’ve done so and scenarios in which users might hit those breakpoints.
Source: Ahmad Shadeed.


How to lazy-load above-the-fold iframes
loading=lazy only works for off-screen elements, so Stefan Bauer demonstrates a neat trick for lazy-loading above-the-fold <iframe>s using <details>.
CodePen Embed Fallback
How to create repeating corner-shape backgrounds
Preethi Sam shows us how to use corner-shape in <svg>s, which are then used as repeating backgrounds. I’ve done my own experiments with corner-shape, but this is wonderful and certainly something that I hadn’t considered.
CodePen Embed Fallback
The CSS Selection (2026 edition)
What do web developers actually do with CSS? While other research studies look at features, The CSS Selection (2026 edition) focuses on CSS patterns and techniques. It’s a very interesting read, and you’ll definitely laugh once or twice, especially as you discover the different typos for !important.
Here are some of my favorites:
!IMPORTANT: too shouty
!impotant: too much information
!i: that’s just lazy
!imPORTANT: excellent annunciation
!importantl: ah, so close…
Chrome features and Quick Hits you might’ve missed
Chrome 145 shipped a few days ago, and as always, we’ve been sharing some Quick Hits throughout the week. You can catch these in the sidebar of the homepage, so feel free to drop by if you’re ever in the ‘hood.
Coincidentally, most of the Quick Hits were related to the Chrome update in some way, so I’ll recap everything together:
text-justify, which you can combine with text-align: justify to specify whether you want the word spacing (text-justify: inter-word) or letter spacing (text-justify: inter-character) to be adjusted to make the text justified. Geoff wrote about this way back in 2017 when only Firefox supported it (sort of…), so by my calculation, Safari should support it by 2035. So not this decade, but before GTA 6. Just kidding… (I think).
Speaking of word and letter spacing, word-spacing and letter-spacing now accept % units, as they do in Safari and Firefox.
Similarly, overscroll-behavior now works for non-root scroll containers, like in Safari and Firefox. WebDev RedFox’s warning about overscroll-behavior couldn’t have come at a better time.
column-wrap and column-height for better multicolumn layouts are also here now, but only in Chrome, unfortunately.
That also applies to customizable <select>, arguably the most exciting feature on this list. As I shared earlier in the week, Adam Argyle wonderfully boiled down this surprisingly complex feature to a simple outline that’s extremely easy to understand.
Looking a little more to the future now, it seems that we’ll eventually be able to have multiple borders and outlines on a single element as well as border-shape, as demonstrated by Dr. Lea Verou and Una Kravets respectively.
Until next time!
What’s !important #5: Lazy-loading iframes, Repeating corner-shape Backgrounds, and More originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

This issue of What’s !important is dedicated to our friends in the UK, who are currently experiencing a very miserable 43-day rain streak. Presenting: the five most interesting things to read about CSS from the last couple of weeks. Plus, the latest features from Chrome 145, and anything else you might’ve missed. TL;DR: lots of content, but also lots of rain.
What’s !important #5: Lazy-loading iframes, Repeating corner-shape Backgrounds, and More originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What’s !important #5: Lazy-loading iframes, Repeating corner-shape Backgrounds, and More

<p>This is the second part of a small two-part series. In this article, we will explore another type of grid: a pyramidal one. We are still working with hexagon shapes, but a different organization of the elements., while exploring other different shapes.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/making-a-responsive-pyramidal-grid-with-modern-css/">Making a Responsive Pyramidal Grid With Modern CSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


In the previous article, we built the classic hexagon grid. It was a responsive implementation without the use of media queries. The challenge was to improve a five-year old approach using modern CSS.




Support is limited to Chrome only because this technique uses recently released features, including corner-shape, sibling-index(), and unit division.
CodePen Embed Fallback
In this article, we will explore another type of grid: a pyramidal one. We are still working with hexagon shapes, but a different organization of the elements.
A demo worth a thousand words:
CodePen Embed Fallback
For better visualization, open the full-page view of the demo to see the pyramidal structure. On screen resize, you get a responsive behavior where the bottom part starts to behave similarly to the grid we created in the previous article!




Cool right? All of this was made without a single media query, JavaScript, or a ton of hacky CSS. You can chunk as many elements as you want, and everything will adjust perfectly.
Before we start, do yourself a favor and read the previous article if you haven’t already. I will skip a few things I have already explained there, such as how the shapes are created as well as a few formulas I will reuse here. Similar to the previous article, the implementation of the pyramidal grid is an improvement of a five-year old approach, so if you want to make a comparison between 2021 and 2026, check out that older article as well.
The Initial Configuration
This time, we will rely on CSS Grid instead of Flexbox. With this structure, it’s easy to control the placement of items inside columns and rows rather than adjusting margins.
<div class="container">
  <div></div>
  <div></div>
  <div></div>
  <div></div>
  
</div>
.container {
  --s: 40px;  /* size  */
  --g: 5px;   /* gap */

  display: grid;
  grid-template-columns: repeat(auto-fit, var(--s) var(--s));
  justify-content: center;
  gap: var(--g);
}

.container > * {
  grid-column-end: span 2;
  aspect-ratio: cos(30deg);
  border-radius: 50% / 25%;
  corner-shape: bevel;
  margin-bottom: calc((2*var(--s) + var(--g))/(-4*cos(30deg)));
}
I am using the classic repeated auto-fit to create as many columns as the free space allows. For the items, it’s the same code of the previous article for creating hexagon shapes.
You wrote var(--s) twice. Is that a typo?
It’s not! I want my grid to always have an even number of columns, where each item spans two columns (that’s why I am using grid-column-end: span 2). With this configuration, I can easily control the shifting between the different rows.




Above is a screenshot of DevTools showing the grid structure. If, for example, item 2 spans columns 3 and 4, then item 4 should span columns 2 and 3, item 5 should span columns 4 and 5, and so on.
It’s the same logic with the responsive part. Each first item of every other row is shifted by one column and starts on the second column.




With this configuration, the size of an item will be equal to 2*var(--s) + var(--g). For this reason, the negative bottom margin is different from the previous example.
So, instead of this:
margin-bottom: calc(var(--s)/(-4*cos(30deg)));
…I am using:
margin-bottom: calc((2*var(--s) + var(--g))/(-4*cos(30deg)));
CodePen Embed Fallback
Nothing fancy so far, but we already have 80% of the code. Believe it or not, we are only one property away from completing the entire grid. All we need to do is set the grid-column-start of a few elements to have the correct placement and, as you may have guessed, here comes the trickiest part involving a complex calculation.
The Pyramidal Grid
Let’s suppose the container is large enough to contain the pyramid with all the elements. In other words, we will ignore the responsive part for now. Let’s analyze the structure and try to identify the patterns:




Regardless of the number of items, the structure is somehow static. The items on the left (i.e., the first item of each row) are always the same (1, 2, 4, 7, 11, and so on). A trivial solution is to target them using the :nth-child() selector.
:nth-child(1) { grid-column-start: ?? }
:nth-child(2) { grid-column-start: ?? }
:nth-child(4) { grid-column-start: ?? }
:nth-child(7) { grid-column-start: ?? }
:nth-child(11) { grid-column-start: ?? }
/* etc. */
The positions of all of them are linked. If item 1 is placed in column x, then item 2 should be placed in column x - 1, item 4 in column x - 2, and so forth.
:nth-child(1) { grid-column-start: x - 0 } /* 0 is not need but useful to see the pattern*/
:nth-child(2) { grid-column-start: x - 1 }
:nth-child(4) { grid-column-start: x - 2 }
:nth-child(7) { grid-column-start: x - 3 }
:nth-child(11) { grid-column-start: x - 4 }
/* etc. */
Item 1 is logically placed in the middle, so if our grid contains N columns, then x is equal to N/2:
:nth-child(1) { grid-column-start: N/2 - 0 }
:nth-child(2) { grid-column-start: N/2 - 1 }
:nth-child(4) { grid-column-start: N/2 - 2 }
:nth-child(7) { grid-column-start: N/2 - 3 }
:nth-child(11){ grid-column-start: N/2 - 4 }
And since each item spans two columns, N/2 can also be seen as the number of items that can fit within the container. So, let’s update our logic and consider N to be the number of items instead of the number of columns.
:nth-child(1) { grid-column-start: N - 0 }
:nth-child(2) { grid-column-start: N - 1 }
:nth-child(4) { grid-column-start: N - 2 }
:nth-child(7) { grid-column-start: N - 3 }
:nth-child(11){ grid-column-start: N - 4 }
/* etc. */
To calculate the number of items, I will use the same formula as in the previous article:
N = round(down, (container_size + gap)/ (item_size + gap));
The only difference is that the size of an item is no longer var(--s)but 2*var(--s) + var(--g), which gives us the following CSS:
.container {
  --s: 40px;  /* size  */
  --g: 5px;   /* gap */

  container-type: inline-size; /* we make it a container to use 100cqw */
}

.container > * {
  --_n: round(down,(100cqw + var(--g))/(2*(var(--s) + var(--g))));
}

.container > *:nth-child(1) { grid-column-start: calc(var(--_n) - 0) }
.container > *:nth-child(2) { grid-column-start: calc(var(--_n) - 1) }
.container > *:nth-child(4) { grid-column-start: calc(var(--_n) - 2) }
.container > *:nth-child(7) { grid-column-start: calc(var(--_n) - 3) }
.container > *:nth-child(11){ grid-column-start: calc(var(--_n) - 4) }
/* etc. */
CodePen Embed Fallback
It works! We have our pyramidal structure. It’s not yet responsive, but we will get there. By the way, if your goal is to build such a structure with a fixed number of items, and you don’t need responsive behavior, then the above is perfect and you’re done!
How come all the items are correctly placed? We only defined the column for a few items, and we didn’t specify any row!
That’s the power of the auto-placement algorithm of CSS Grid. When you define the column for an item, the next one will be automatically placed after it! We don’t need to manually specify a bunch of columns and rows for all the items.
Improving the Implementation
You don’t like those verbose :nth-child() selectors, right? Me too, so let’s remove them and have a better implementation. Such a pyramid is well known in the math world, and we have something called a triangular number that I am going to use. Don’t worry, I will not start a math course, so here is the formula I will be using:
j*(j + 1)/2 + 1 = index
…where j is a positive integer (zero included).
In theory, all the :nth-child can be generated using the following pseudo code:
for(j = 0; j< ?? ;j++) {
  :nth-child(j*(j + 1)/2 + 1) { grid-column-start: N - j }
}
We don’t have loops in CSS, so I will follow the same logic I did in the previous article (which I hope you read, otherwise you will get a bit lost). I express j using the index. I solved the previous formula, which is a quadratic equation, but I am sure you don’t want to get into all that math.
j = sqrt(2*index - 1.75) - .5
We can get the index using the sibling-index() function. The logic is to test for each item if sqrt(2*index - 1.75) - .5 is a positive integer.
.container {
  --s: 40px; /* size  */
  --g: 5px; /* gap */

  container-type: inline-size; /* we make it a container to use 100cqw */
}
.container > * {
  --_n: round(down,(100cqw + var(--g))/(2*(var(--s) + var(--g))));
  --_j: calc(sqrt(2*sibling-index() - 1.75) - .5);
  --_d: mod(var(--_j),1);
  grid-column-start: if(style(--_d: 0): calc(var(--_n) - var(--_j)););
}
When the --_d variable is equal to 0, it means that --_j is an integer; and when that’s the case I set the column to N - j. I don’t need to test if --_j is positive because it’s always positive. The smallest index value is 1, so the smallest value of --_j is 0.
CodePen Embed Fallback
Tada! We replaced all the :nth-child() selectors with three lines of CSS that cover any number of items. Now let’s make it responsive!
The Responsive Behavior
Back in my 2021 article, I switched between the pyramidal grid and the classic grid based on screen size. I will do something different this time. I will keep building the pyramid until it’s no longer possible, and from there, it will turn into the classic grid.




Items 1 to 28 form the pyramid. After that, we get the same classic grid we built in the previous article. We need to target the first items of some rows (29, 42, etc.) and shift them. We are not going to set a margin on the left this time, but we do need to set their grid-column-start value to 2.
As usual, we identify the formula of the items, express it using the index, and then test if the result is a positive integer or not:
N*i + (N - 1)*(i - 1) + 1 + N*(N - 1)/2 = index
So:
i = (index - 2 + N*(3 - N)/2)/(2*N - 1)
When i is a positive integer (zero excluded), we set the column start to 2.
.container {
  --s: 40px; /* size  */
  --g: 5px; /* gap */

  container-type: inline-size; /* we make it a container to use 100cqw */
}
.container > * {
  --_n: round(down,(100cqw + var(--g))/(2*(var(--s) + var(--g))));

  /* code for the pyramidal grid */
  --_j: calc(sqrt(2*sibling-index() - 1.75) - .5);
  --_d: mod(var(--_j),1);
  grid-column-start: if(style(--_d: 0): calc(var(--_n) - var(--_j)););

  /* code for the responsive grid */
  --_i: calc((sibling-index() - 2 + (var(--_n)*(3 - var(--_n)))/2)/(2*var(--_n) - 1));
  --_c: mod(var(--_i),1);
  grid-column-start: if(style((--_i > 0) and (--_c: 0)): 2;);
}
Unlike the --_j variable, I need to test if --_i is a positive value, as it can be negative for some index values. For this reason, I have an extra condition compared to the first one.
But wait! That’s no good at all. We are declaring grid-column-start twice, so only one of them will get used. We should have only one declaration, and for that, we can combine both conditions using a single if() statement:
grid-column-start:
if(
  style((--_i > 0) and (--_c: 0)): 2; /* first condition */
  style(--_d: 0): calc(var(--_n) - var(--_j)); /* second condition */
);
If the first condition is true (the responsive grid), we set the value to 2; else if the second condition is true (the pyramidal grid), we set the value to calc(var(--_n) - var(--_j)); else we do nothing.
Why that particular order?
Because the responsive grid should have a higher priority. Check the figure below:




Item 29 is part of the pyramidal grid since it’s the first item in its row. This means that the pyramidal condition will always be true for that item. But when the grid becomes responsive, that item becomes part of the responsive grid, and the other condition is also true. When both conditions are true, the responsive condition one should win; that’s why it’s the first condition we test.
Let’s see this in play:
CodePen Embed Fallback
Oops! The pyramid looks good, but after that, things get messy.
To understand what is happening, let’s look specifically at item 37. If you check the previous figure, you will notice it’s part of the pyramidal structure. So, even if the grid becomes responsive, its condition is still true and it gets a column value from the formula calc(var(--_n) - var(--_j)) which is not good because we want to keep its default value for auto-placement. That’s the case for many items, so we need to fix them.
To find the fix, let’s see how the values in the pyramid behave. They all follow the formula N - j, where j is a positive integer. If, for example, N is equal to 10 we get:
10, 9, 8, 7, ... ,0, -1 , -2
At certain points, the values become negative, and since negative values are valid, those items will be randomly placed, disrupting the grid. We need to ensure the negative values are ignored, and the default value is used instead.
We use the following to keep only the positive value and transform all the negative ones into zeroes:
max(0, var(--_n) - var(--_j))
We set 0 as a minimum boundary (more on that here) and the values become:
10, 9, 8, 7, ... , 0, 0, 0, 0
We either get a positive value for the column or we get 0.
But you said the value should be the default one and not 0.
Yes, but 0 is an invalid value for grid-column-start, so using 0 means the browser will ignore it and fall back to the default value!
Our new code is:
grid-column-start:
  if(
    style((--_i > 0) and (--_c: 0)): 2; /* first condition */
    style(--_d: 0): max(0,var(--_n) - var(--_j)); /* second condition */
  );
And it works!
CodePen Embed Fallback




You can add as many items as you want, resize the screen, and everything will fit perfectly!
More Examples
Enough code and math! Let’s enjoy more variations using different shapes. I’ll let you dissect the code as homework.
Rhombus grid
CodePen Embed Fallback
You will notice a slightly different approach for setting the gap between the elements in the next three demos.
Octagon grid
CodePen Embed Fallback
Circle grid
CodePen Embed Fallback
And the other hexagon grid:
CodePen Embed Fallback
Conclusion
Do you remember when I told you that we were one property away from completing the grid? That one property (grid-column-start) took us literally the whole article to discuss! This demonstrates that CSS has evolved and requires a new mindset to work with. CSS is no longer a language where you simply set static values such color: red, margin: 10px, display: flex, etc.
Now we can define dynamic behaviors through complex calculations. It’s a whole process of thinking, finding formulas, defining variables, creating conditions, and so on. That’s not something new since I was able to do the same in 2021. However, we now have stronger features that allow us to have less hacky code and more flexible implementations.
Making a Responsive Pyramidal Grid With Modern CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

This is the second part of a small two-part series. In this article, we will explore another type of grid: a pyramidal one. We are still working with hexagon shapes, but a different organization of the elements., while exploring other different shapes.
Making a Responsive Pyramidal Grid With Modern CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Making a Responsive Pyramidal Grid With Modern CSS

<p>The new <code>contrast-color()</code> function is not fully supported yet. But can we still implement it in a cross-browser friendly way using other new CSS features?</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/approximating-contrast-color-with-other-css-features/">Approximating contrast-color() With Other CSS Features</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>You have an element with a configurable background color, and you’d like to calculate whether the foreground text should be light or dark. Seems easy enough, especially knowing how mindful we ought to be with accessibility.</p>



<p>There have been a few drafts of a specification function for this functionality, most recently, <a href="https://css-tricks.com/exploring-the-css-contrast-color-function-a-second-time/"><code>contrast-color()</code></a> (formerly <code>color-contrast()</code>) in the <a href="https://drafts.csswg.org/css-color-5/#contrast-color" rel="noopener">CSS Color Module Level 5 draft</a>. But with Safari and Firefox being the only browsers that have implemented it so far, the final version of this functionality is likely still a ways off. There has been a lot of functionality added to CSS in the meantime; enough that I wanted to see whether we could implement it in a cross-browser friendly way today. Here’s what I have:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">color: oklch(from &lt;your color> round(1.21 - L) 0 0);</code></pre>



<p>Let me explain how I got here.</p>



<span id="more-391853"></span>


<h3 class="wp-block-heading" id="wcag-2-2">WCAG 2.2</h3>


<p>WCAG provides the formulas it uses for calculating the contrast between two RGB colors and <a href="https://css-tricks.com/understanding-web-accessibility-color-contrast-guidelines-and-ratios/#aa-what-does-the-ratio-mean">Stacie Arellano has described in great detail</a>. It’s based on older methods, calculating the <em>luminance</em> of colors (how perceptually bright they appear) and even tries to clamp for the limitations of monitors and screen flare:</p>



<pre rel="" class="wp-block-csstricks-code-block language-none" data-line=""><code markup="tt">L1 + 0.05 / L2 + 0.05</code></pre>



<p>&#8230;where the lighter color (<code>L1</code>) is on the top. Luminance ranges from 0 to 1, and this fraction is responsible for contrast ratios going from 1 (1.05/1.05) to 21 (1.05/.05).</p>



<p>The formulas for calculating the luminance of RGB colors are even messier, but I’m only trying to determine whether white or black will have higher contrast with a given color, and can get away with simplifying a little bit. We end up with something like this:</p>



<pre rel="" class="wp-block-csstricks-code-block language-none" data-line=""><code markup="tt">L = 0.1910(R/255+0.055)^2.4 + 0.6426(G/255+0.055)^2.4 + 0.0649(B/255+0.055)^2.4</code></pre>



<p>Which we <em>can</em> convert into CSS like this:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">calc(.1910*pow(r/255 + .055,2.4)+.6426*pow(g/255 + .055,2.4)+.0649*pow(b/255 + .055,2.4))</code></pre>



<p>We can make this whole thing round to 1 or 0 using <a href="https://css-tricks.com/almanac/functions/r/round/"><code>round()</code></a>, 1 for white and 0 for black:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">round(.67913 - .1910*pow(r/255 + .055, 2.4) - .6426*pow(g/255 + .055, 2.4) - .0649*pow(b/255 + .055, 2.4))</code></pre>



<p>Let’s multiply that by 255 and use it for all three channels with <a href="https://css-tricks.com/css-color-functions/#aa-the-relative-color-syntax">the relative color syntax</a>. We end up with this:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">color: rgb(from &lt;your color>  
  round(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
  round(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
  round(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
);</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_xbOqZoK" src="//codepen.io/anon/embed/xbOqZoK?height=450&amp;theme-id=1&amp;slug-hash=xbOqZoK&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed xbOqZoK" title="CodePen Embed xbOqZoK" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>A formula that, given a color, returns white or black based on WCAG 2. It’s not easy to read, but it works&#8230; except <a href="https://git.myndex.com/" rel="noopener">APCA</a> is <a href="https://www.smashingmagazine.com/2025/05/wcag-3-proposed-scoring-model-shift-accessibility-evaluation/" rel="noopener">poised to replace it as a newer, better formula in future WCAG guidelines</a>. We can do the math again, though APCA is an even more complicated formula. We could leverage CSS functions to clean it up a little, but ultimately this implementation is going to be inaccessible, hard to read, and difficult to maintain.</p>


<h3 class="wp-block-heading" id="new-approach">New Approach</h3>


<p>I took a step back and thought about what else we have available. We do have another new feature we can try out: <a href="https://css-tricks.com/color-everything-in-css/#aa-color-spaces">color spaces</a>. The &#8220;<code>L*</code>&#8221; value in the CIELAB color space represents <em>perceptual lightness</em>. It is meant to reflect what our eyes can see. It’s not the same as luminance, but it’s close. Maybe we could guess whether to use black or white for better contrast based on perceptual lightness; let’s see if we can find a number where any color with lower lightness we use black, and higher lightness we use white.</p>



<p>You might instinctively think it should be 50% or .5, but it isn’t. A lot of colors, even when they’re bright, still contrast better with white than black. Here’s some examples using <a href="https://css-tricks.com/almanac/functions/l/lch/"><code>lch()</code></a>, slowly increasing the lightness while keeping the hue the same:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_xbOEPYM" src="//codepen.io/anon/embed/xbOEPYM?height=550&amp;theme-id=1&amp;slug-hash=xbOEPYM&amp;default-tab=result" height="550" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed xbOEPYM" title="CodePen Embed xbOEPYM" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>The transition point where it’s easier to read the black text than white usually happens between 60-65. So, I put together a quick Node app using <a href="http://Colorjs.io" rel="noopener">Colorjs.io</a> to calculate where the cut off should be, using APCA for calculating contrast.</p>



<p>For <a href="https://css-tricks.com/almanac/functions/o/oklch/"><code>oklch()</code></a>, I found the threshold to be between .65 and .72, with an average of .69.</p>



<p>In other words:</p>



<ul class="wp-block-list">
<li>When the OKLCH lightness is .72 or above, black will always contrast better than white.</li>



<li>Below .65, white will always contrast better than black.</li>



<li>Between .65 and .72, typically both black and white have contrasts between 45-60.</li>
</ul>



<p>So, just using <code>round()</code> and the upper bound of .72, we can make a new, shorter implementation:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">color: oklch(from &lt;your color> round(1.21 - L) 0 0);</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_VYjKyJM" src="//codepen.io/anon/embed/VYjKyJM?height=450&amp;theme-id=1&amp;slug-hash=VYjKyJM&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed VYjKyJM" title="CodePen Embed VYjKyJM" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>If you’re wondering where 1.21 came from, it’s so that .72 rounds down and .71 rounds up: <code>1.21 - .72 = .49</code> rounds down, and <code>1.21 - .71 = .5</code> rounds up.</p>



<p>This formula works pretty well, having put a couple iterations of this formula into production. It’s easier to read and maintain. That said, this formula more closely matches APCA than WCAG, so sometimes it disagrees with WCAG. For example, WCAG says black has a higher contrast (4.70 than white at 4.3) when placed on <code>#407ac2</code>, whereas APCA says the opposite: black has a contrast of 33.9, and white has a contrast of 75.7. The new CSS formula matches APCA and shows white:</p>



<figure class="wp-block-image size-full is-resized ticss-d30f5ea1"><img data-recalc-dims="1" loading="lazy" decoding="async" width="400" height="184" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/blue-bg-white-black-text.png?resize=400%2C184&#038;ssl=1" alt="A blue rectangle with white and black text compared on top. White says APCA and black says WCAG." class="wp-image-391869" style="width:181px;height:auto" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/blue-bg-white-black-text.png?w=400&amp;ssl=1 400w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/blue-bg-white-black-text.png?resize=300%2C138&amp;ssl=1 300w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>



<p>Arguably, this formula may do a better job than WCAG 2.0 because it more closely matches APCA. That said, you’ll still need to check accessibility, and if you’re held legally to WCAG instead of APCA, then maybe this newer simpler formula is less helpful to you.</p>


<h3 class="wp-block-heading" id="lch-vs-oklch">LCH vs. OKLCH</h3>


<p>I did run the numbers for both, and aside from OKLCH being designed to be a better replacement for LCH, I also found that the numbers support that OKLCH is a better choice.</p>



<p>With LCH, the gap between too dark for black and too light for white is often bigger, and the gap moves around more. For example, <code>#e862e5</code> through <code>#fd76f9</code> are too dark for black and too light for white. With LCH, that runs between lightness 63 through 70; for OKLCH, it’s .7 through .77. The scaling of OKLCH lightness just better matches APCA.</p>


<h3 class="wp-block-heading" id="one-step-further">One Step Further</h3>


<p>While &#8220;most-contrast&#8221; will certainly be better, we can implement one more trick. Our current logic simply gives us white or black (which is what <a href="https://css-tricks.com/exploring-the-css-contrast-color-function-a-second-time/#aa-the-shortcomings-of-contrast-color">the <code>color-contrast()</code> function is currently limited to</a>), but we can change this to give us white or another given color. So, for example, white or the base text color. Starting with this:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">color: oklch(from &lt;your color> round(1.21 - L) 0 0);  

/* becomes: */

--white-or-black: oklch(from &lt;your color> round(1.21 - L) 0 0);  
color: rgb(  
  from color-mix(in srgb, var(--white-or-black), &lt;base color>)  
  calc(2*r) calc(2*g) calc(2*b)  
);</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_KwMWVjB" src="//codepen.io/anon/embed/KwMWVjB?height=450&amp;theme-id=1&amp;slug-hash=KwMWVjB&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed KwMWVjB" title="CodePen Embed KwMWVjB" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>It’s some clever math, but it isn’t pleasant to read:</p>



<ul class="wp-block-list">
<li><strong>If <code>--white-or-black</code> is white</strong>, <a href="https://css-tricks.com/almanac/functions/c/color-mix/"><code>color-mix()</code></a> results in <code>rgb(127.5, 127.5, 127.5)</code> or brighter; doubled we’re at <code>rgb(255, 255, 255)</code> or higher, which is just white.</li>



<li><strong>If <code>--white-or-black</code> is black</strong>, <code>color-mix()</code> cuts the value of each RGB channel by 50%; doubled we’re back to the original value of the <code>&lt;base color&gt;</code>.</li>
</ul>



<p>Unfortunately, this formula doesn’t work in Safari 18 and below, so you need to target Chrome, Safari 18+ and Firefox. However, it does give us a way with pure CSS to switch between white and a base text color, instead of white and black alone, and we can fallback to white and black in Safari &lt;18.</p>



<p>You can also rewrite these both using <a href="https://css-tricks.com/css-functions-and-mixins-module-notes/">CSS Custom Functions</a>, but those aren’t supported everywhere yet either:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">@function --white-black(--color) {  
  result: oklch(from var(--color) round(1.21 - l) 0 0);  
}

@function --white-or-base(--color, --base) {  
  result: rgb(from color-mix(in srgb, --white-black(var(--color)), var(--base)) calc(2*r) calc(2*g) calc(2*b));  
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_xbOqVKK" src="//codepen.io/anon/embed/xbOqVKK?height=450&amp;theme-id=1&amp;slug-hash=xbOqVKK&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed xbOqVKK" title="CodePen Embed xbOqVKK" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="conclusion">Conclusion</h3>


<p>I hope this technique works well for you, and I’d like to reiterate that the point of this approach — looking for a threshold and a simple formula — is to make the implementation flexible and easy to adapt to your needs. You can easily adjust the threshold to whatever works best for you.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/approximating-contrast-color-with-other-css-features/">Approximating contrast-color() With Other CSS Features</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


You have an element with a configurable background color, and you’d like to calculate whether the foreground text should be light or dark. Seems easy enough, especially knowing how mindful we ought to be with accessibility.
There have been a few drafts of a specification function for this functionality, most recently, contrast-color() (formerly color-contrast()) in the CSS Color Module Level 5 draft. But with Safari and Firefox being the only browsers that have implemented it so far, the final version of this functionality is likely still a ways off. There has been a lot of functionality added to CSS in the meantime; enough that I wanted to see whether we could implement it in a cross-browser friendly way today. Here’s what I have:
color: oklch(from <your color> round(1.21 - L) 0 0);
Let me explain how I got here.



WCAG 2.2
WCAG provides the formulas it uses for calculating the contrast between two RGB colors and Stacie Arellano has described in great detail. It’s based on older methods, calculating the luminance of colors (how perceptually bright they appear) and even tries to clamp for the limitations of monitors and screen flare:
L1 + 0.05 / L2 + 0.05
…where the lighter color (L1) is on the top. Luminance ranges from 0 to 1, and this fraction is responsible for contrast ratios going from 1 (1.05/1.05) to 21 (1.05/.05).
The formulas for calculating the luminance of RGB colors are even messier, but I’m only trying to determine whether white or black will have higher contrast with a given color, and can get away with simplifying a little bit. We end up with something like this:
L = 0.1910(R/255+0.055)^2.4 + 0.6426(G/255+0.055)^2.4 + 0.0649(B/255+0.055)^2.4
Which we can convert into CSS like this:
calc(.1910*pow(r/255 + .055,2.4)+.6426*pow(g/255 + .055,2.4)+.0649*pow(b/255 + .055,2.4))
We can make this whole thing round to 1 or 0 using round(), 1 for white and 0 for black:
round(.67913 - .1910*pow(r/255 + .055, 2.4) - .6426*pow(g/255 + .055, 2.4) - .0649*pow(b/255 + .055, 2.4))
Let’s multiply that by 255 and use it for all three channels with the relative color syntax. We end up with this:
color: rgb(from <your color>  
  round(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
  round(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
  round(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
);
CodePen Embed Fallback
A formula that, given a color, returns white or black based on WCAG 2. It’s not easy to read, but it works… except APCA is poised to replace it as a newer, better formula in future WCAG guidelines. We can do the math again, though APCA is an even more complicated formula. We could leverage CSS functions to clean it up a little, but ultimately this implementation is going to be inaccessible, hard to read, and difficult to maintain.
New Approach
I took a step back and thought about what else we have available. We do have another new feature we can try out: color spaces. The “L*” value in the CIELAB color space represents perceptual lightness. It is meant to reflect what our eyes can see. It’s not the same as luminance, but it’s close. Maybe we could guess whether to use black or white for better contrast based on perceptual lightness; let’s see if we can find a number where any color with lower lightness we use black, and higher lightness we use white.
You might instinctively think it should be 50% or .5, but it isn’t. A lot of colors, even when they’re bright, still contrast better with white than black. Here’s some examples using lch(), slowly increasing the lightness while keeping the hue the same:
CodePen Embed Fallback
The transition point where it’s easier to read the black text than white usually happens between 60-65. So, I put together a quick Node app using Colorjs.io to calculate where the cut off should be, using APCA for calculating contrast.
For oklch(), I found the threshold to be between .65 and .72, with an average of .69.
In other words:
When the OKLCH lightness is .72 or above, black will always contrast better than white.
Below .65, white will always contrast better than black.
Between .65 and .72, typically both black and white have contrasts between 45-60.
So, just using round() and the upper bound of .72, we can make a new, shorter implementation:
color: oklch(from <your color> round(1.21 - L) 0 0);
CodePen Embed Fallback
If you’re wondering where 1.21 came from, it’s so that .72 rounds down and .71 rounds up: 1.21 - .72 = .49 rounds down, and 1.21 - .71 = .5 rounds up.
This formula works pretty well, having put a couple iterations of this formula into production. It’s easier to read and maintain. That said, this formula more closely matches APCA than WCAG, so sometimes it disagrees with WCAG. For example, WCAG says black has a higher contrast (4.70 than white at 4.3) when placed on #407ac2, whereas APCA says the opposite: black has a contrast of 33.9, and white has a contrast of 75.7. The new CSS formula matches APCA and shows white:




Arguably, this formula may do a better job than WCAG 2.0 because it more closely matches APCA. That said, you’ll still need to check accessibility, and if you’re held legally to WCAG instead of APCA, then maybe this newer simpler formula is less helpful to you.
LCH vs. OKLCH
I did run the numbers for both, and aside from OKLCH being designed to be a better replacement for LCH, I also found that the numbers support that OKLCH is a better choice.
With LCH, the gap between too dark for black and too light for white is often bigger, and the gap moves around more. For example, #e862e5 through #fd76f9 are too dark for black and too light for white. With LCH, that runs between lightness 63 through 70; for OKLCH, it’s .7 through .77. The scaling of OKLCH lightness just better matches APCA.
One Step Further
While “most-contrast” will certainly be better, we can implement one more trick. Our current logic simply gives us white or black (which is what the color-contrast() function is currently limited to), but we can change this to give us white or another given color. So, for example, white or the base text color. Starting with this:
color: oklch(from <your color> round(1.21 - L) 0 0);  

/* becomes: */

--white-or-black: oklch(from <your color> round(1.21 - L) 0 0);  
color: rgb(  
  from color-mix(in srgb, var(--white-or-black), <base color>)  
  calc(2*r) calc(2*g) calc(2*b)  
);
CodePen Embed Fallback
It’s some clever math, but it isn’t pleasant to read:
If --white-or-black is white, color-mix() results in rgb(127.5, 127.5, 127.5) or brighter; doubled we’re at rgb(255, 255, 255) or higher, which is just white.
If --white-or-black is black, color-mix() cuts the value of each RGB channel by 50%; doubled we’re back to the original value of the <base color>.
Unfortunately, this formula doesn’t work in Safari 18 and below, so you need to target Chrome, Safari 18+ and Firefox. However, it does give us a way with pure CSS to switch between white and a base text color, instead of white and black alone, and we can fallback to white and black in Safari <18.
You can also rewrite these both using CSS Custom Functions, but those aren’t supported everywhere yet either:
@function --white-black(--color) {  
  result: oklch(from var(--color) round(1.21 - l) 0 0);  
}

@function --white-or-base(--color, --base) {  
  result: rgb(from color-mix(in srgb, --white-black(var(--color)), var(--base)) calc(2*r) calc(2*g) calc(2*b));  
}
CodePen Embed Fallback
Conclusion
I hope this technique works well for you, and I’d like to reiterate that the point of this approach — looking for a threshold and a simple formula — is to make the implementation flexible and easy to adapt to your needs. You can easily adjust the threshold to whatever works best for you.
Approximating contrast-color() With Other CSS Features originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The new contrast-color() function is not fully supported yet. But can we still implement it in a cross-browser friendly way using other new CSS features?
Approximating contrast-color() With Other CSS Features originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Approximating contrast-color() With Other CSS Features

<p>Can we make pie chart that's semantic, with flexible markup, and avoids using a JavaScript library? Here's how I tackled it.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/trying-to-make-the-perfect-pie-chart-in-css/">Trying to Make the Perfect Pie Chart in CSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Speaking of charts… When was the last time you had to use a pie chart? If you are one of those people who have to give presentations right and left, then congratulations! You are both in my personal hell… and also surrounded by pie charts. Luckily, I think I haven’t needed to use them in ages, or at least that was until recently.
Last year, I volunteered to make ta webpage for a kids’ charity in México1. Everything was pretty standard, but the staff wanted some data displayed as pie charts on their landing page. They didn’t give us a lot of time, so I admit I took the easy route and used one of the many JavaScript libraries out there for making charts.
It looked good, but deep down I felt dirty; pulling in a whole library for a couple of simple pie charts. Feels like the easy way out rather than crafting a real solution.
I want to amend that. In this article, we’ll try making the perfect pie chart in CSS. That means avoiding as much JavaScript as possible while addressing major headaches that comes with handwriting pie charts. But first, let’s set some goals that our “perfect” should comply with.




In order of priority:
This must be semantic! Meaning a screen reader should be able to understand the data shown in the pie chart.
This should be HTML-customizable! Once the CSS is done, we only have to change the markup to customize the pie chart.
This should keep JavaScript to a minimum! No problem with JavaScript in general, it’s just more fun this way.
Once we are done, we should get a pie chart like this one:




Is this too much to ask? Maybe, but we’ll try it anyways.
Conic gradients suck aren’t the best
We can’t talk about pie charts without talking first about conic gradients. If you’ve read anything related to the conic-gradient() function, then you’ve likely seen that they can be used to create simple pie charts in CSS. Heck, even I have said so in the almanac entry. Why not? If only with one element and a single line of CSS…
.gradient {
  background: conic-gradient(blue 0% 12.5%, lightblue 12.5% 50%, navy 50% 100%);
}
We can have seemlessly perfect pie chart:
CodePen Embed Fallback
However, this method blatantly breaks our first goal of semantic pie charts. As it’s later noted on the same entry:
Do not use the conic-gradient() function to create a real pie chart, or any other infographics for that matter. They don’t hold any semantic meaning and should only be used decoratively.
Remember that gradients are images, so displaying a gradient as a background-image doesn’t tell screen readers anything about the pie charts themselves; they only see an empty element.
This also breaks our second rule of making pie charts HTML-customizable, since for each pie chart we’d have to change its corresponding CSS.
So should we ditch conic-gradient() altogether? As much as I’d like to, its syntax is too good to pass so let’s at least try to up its shortcomings and see where that takes us.
Improving semantics
The first and most dramatic problem with conic-gradient() is its semantics. We want a rich markup with all the data laid out so it can be understood by screen readers. I must admit I don’t know the best way to semantically write that, but after testing with NVDA, I believe this is a good enough markup for the task:
<figure>
  <figcaption>Candies sold last month</figcaption>
  <ul class="pie-chart">
    <li data-percentage="35" data-color="#ff6666"><strong>Chocolates</strong></li>
    <li data-percentage="25" data-color="#4fff66"><strong>Gummies</strong></li>
    <li data-percentage="25" data-color="#66ffff"><strong>Hard Candy</strong></li>
    <li data-percentage="15" data-color="#b366ff"><strong>Bubble Gum</strong></li>
  </ul>
</figure>
Ideally, this is all we need for our pie chart, and once styles are done, just editing the data-* attributes or adding new <li> elements should update our pie chart.
Just one thing though: In its current state, the data-percentage attribute won’t be read out loud by screen readers, so we’ll have to append it to the end of each item as a pseudo-element. Just remember to add the “%” at the end so it also gets read:
.pie-chart li::after {
  content: attr(data-percentage) "%";
}
CodePen Embed Fallback
So, is it accessible? It is, at least when testing in NVDA. Here it is in Windows:




You may have some questions regarding why I chose this or that. If you trust me, let’s keep going, but if not, here is my thought process:
We could easily write them inside each <li>, but using attributes we can get each percentage on CSS through the attr() function. And as we’ll see later it makes working with CSS a whole lot easier.
<figure>?      
  

The <figure> element can be used as a self-contained wrapper for our pie chart, and besides images, it’s used a lot for diagrams too. It comes in handy since we can give it a title inside <figcaption> and then write out the data on an unordered list, which I didn’t know was among the content permitted inside <figure> since <ul> is considered flow content.
We could have used an aria-description attribute so screen readers can read the corresponding percentage for each item, which is arguably the most important part. However, we may need to visually show the legend, too. That means there is no advantage to having percentages both semantically and visually since they might get read twice: (1) once on the aria-description and (2) again on the pseudo-element.
Making it a pie chart
We have our data on paper. Now it’s time to make it look like an actual pie chart. My first thought was, “This should be easy, with the markup done, we can now use a conic-gradient()!”
Well… I was very wrong, but not because of semantics, but how the CSS Cascade works.
Let’s peek again at the conic-gradient() syntax. If we have the following data:
Item 1: 15%
Item 2: 35%
Item 3: 50%
…then we would write down the following conic-gradient():
.gradient {
  background: 
    conic-gradient(
      blue 0% 15%, 
      lightblue 15% 50%, 
      navy 50% 100%
    );
}
This basically says: “Paint the first color from 0 to 15%, the next color from 15% to 50% (so the difference is 35%), and so on.”
Do you see the issue? The pie chart is drawn in a single conic-gradient(), which equals a single element. You may not see it, but that’s terrible! If we want to show each item’s weight inside data-percentage — making everything prettier — then we would need a way to access all these percentages from the parent element. That’s impossible!
The only way we can get away with the simplicity of data-percentage is if each item draws its own slice. This doesn’t mean, however, that we can’t use conic-gradient(), but rather we’ll have to use more than one.
The plan is for each of these items to have their own conic-gradient() painting their slice and then place them all on top of each other:




To do this, we’ll first give each <li> some dimensions. Instead of hardcoding a size, we’ll define a --radius property that’ll come in handy later for keeping our styles maintainable when updating the HTML.
.pie-chart li {
  --radius: 20vmin;

  width: calc(var(--radius) * 2); /* radius twice = diameter */
  aspect-ratio: 1;
  border-radius: 50%;
}
Then, we’ll get the data-percentage attribute into CSS using attr() and its new type syntax that allows us to parse attributes as something other than a string. Just beware that the new syntax is currently limited to Chromium as I’m writing this.




However, in CSS it is far better to work with decimals (like 0.1) instead of percentages (like 10%) because we can multiply them by other units. So we’ll parse the data-percentage attribute as a <number> and then divide it by 100 to get our percentage in decimal form.
.pie-chart li {
  /* ... */
  --weighing: calc(attr(data-percentage type(<number>)) / 100);
}
We still need it as a percentage, which means multiplying that result by 1%.
.pie-chart li {
  /* ... */
  --percentage: calc(attr(data-percentage type(<number>)) * 1%);
}
Lastly, we’ll get the data-color attribute from the HTML using attr() again, but with the <color> type this time instead of a <number>:
.pie-chart li {
  /* ... */
  --bg-color: attr(data-color type(<color>));
}
Let’s put the --weighing variable aside for now and use our other two variables to create the conic-gradient() slices. These should go from 0% to the desired percentage, and then become transparent afterwards:
.pie-chart li {
  /* ... */
   background: conic-gradient(
   var(--bg-color) 0% var(--percentage),
   transparent var(--percentage) 100%
  );
}
I am defining the starting 0% and ending 100% explicitly, but since those are the default values, we could technically remove them.
Here’s where we’re at:
CodePen Embed Fallback
Perhaps an image will help if your browser lacks support for the new attr() syntax:




Now that all the slices are done, you’ll notice each of them starts from the top and goes in a clockwise direction. We need to position these, you know, in a pie shape, so our next step is to rotate them appropriately to form a circle.
This is when we hit a problem: the amount each slice rotates depends on the number of items that precede it. We’ll have to rotate an item by whatever size the slice before it is. It would be ideal to have an accumulator variable (like --accum) that holds the sum of the percentages before each item. However, due to the way the CSS Cascade works, we can neither share state between siblings nor update the variable on each sibling.
And believe me, I tried really hard to work around these issues. But it seems we are forced into two options:
Hardcode the --accum variable on each <li> element.
Use JavaScript to calculate the --accum variable.
The choice isn’t that hard if we revisit our goals: hardcoding --accum would negate flexible HTML since moving an item or changing percentages would force us to manually calculate the --accum variable again.
JavaScript, however, makes this a trivial effort:
const pieChartItems = document.querySelectorAll(".pie-chart li");

let accum = 0;

pieChartItems.forEach((item) =>; {
  item.style.setProperty("--accum", accum);
  accum += parseFloat(item.getAttribute("data-percentage"));
});
With --accum out of the way, we can rotate each conic-gradient() using the from syntax, that tells the conic gradient the rotation’s starting point. The thing is that it only takes an angle, not a percentage. (I feel like a percentage should also work fine, but that’s a topic for another time).
To work around this, we’ll have to create yet another variable — let’s call it --offset — that is equal to --accum converted to an angle. That way, we can plug the value into each conic-gradient():
.pie-chart li {
  /* ... */
  --offset: calc(360deg * var(--accum) / 100);

  background: conic-gradient(
    from var(--offset),
    var(--bg-color) 0% var(--percentage),
    transparent var(--percentage) 100%
  );
}
We’re looking a lot better!
CodePen Embed Fallback




What’s left is to place all items on top of each other. There are plenty of ways to do this, of course, though the easiest might be CSS Grid.
.pie-chart {
  display: grid;
  place-items: center;
}

.pie-chart li {
  /* ... */
  grid-row: 1;
  grid-column: 1;
}
This little bit of CSS arranges all of the slices in the dead center of the .pie-chart container, where each slice covers the container’s only row and column. They slices won’t collide because they’re properly rotated!
CodePen Embed Fallback




Except for those overlapping labels, we’re in really, really good shape! Let’s clean that stuff up.
Positioning labels
Right now, the name and percentage labels inside the <figcaption> are splattered on top of one another. We want them floating next to their respective slices. To fix this, let’s start by moving all those items to the center of the .pie-chart container using the same grid-centering trick we we applied on the container itself:
.pie-chart li {
  /* ... */
  display: grid;
  place-items: center;
}

.pie-chart li::after,
strong {
  grid-row: 1;
  grid-column: 1;
}
Luckily, I’ve already explored how to lay things out in a circle using the newer CSS cos() and sin(). Give those links a read because there’s a lot of context in there. In short, given an angle and a radius, we can use cos() and sin() to get the X and Y coordinates for each item around a circle.
For that, we’ll need — you guessed it! — another CSS variable representing the angle (we’ll call it --theta) where we’ll place each label. We can calculate that angle this next formula:
.pie-chart li {
  /* ... */
  --theta: calc((360deg * var(--weighing)) / 2 + var(--offset) - 90deg);
}
It’s worth knowing what that formula is doing:
360deg * var(--weighing)) / 2: Gets the percentage as an angle then divides it by two to find the middle point.
+ var(--offset): Moves the angle to match the current offset.
- 90deg. cos() and sin(): The angles are measured from the right, but conic-gradient() starts from the top. This part corrects each angle by -90deg.
We can find the X and Y coordinates using the --theta and --radius variables, like the following pseudo code:
x = cos(theta) * radius
y = sin(theta) * radius
Which translates to…
.pie-chart li {
  /* ... */
  --pos-x: calc(cos(var(--theta)) * var(--radius));
  --pos-y: calc(sin(var(--theta)) * var(--radius));
}
This places each item  on the pie chart’s edge, so we’ll add in a --gap between them:
.pie-chart li {
  /* ... */
  --gap: 4rem;
  --pos-x: calc(cos(var(--theta)) * (var(--radius) + var(--gap)));
  --pos-y: calc(sin(var(--theta)) * (var(--radius) + var(--gap)));
}
And we’ll translate each label by --pos-x and --pos-y:
.pie-chart li::after,
strong {
  /* ... */
  transform: translateX(var(--pos-x)) translateY(var(--pos-y));
}
Oh wait, just one more minor detail. The label and percentage for each item are still stacked on top of each other. Luckily, fixing it is as easy as translating the percentage a little more on the Y-axis:
.pie-chart li::after {
  --pos-y: calc(sin(var(--theta)) * (var(--radius) + var(--gap)) + 1lh);
}
Now we’re cooking with gas!
CodePen Embed Fallback




Let’s make sure this is screenreader-friendly:



That’s about it… for now…
I’d call this a really good start toward a “perfect” pie chart, but there are still several things we could improve:
The pie chart assumes you’ll write the percentages yourself, but there should be a way to input the raw number of items and then calculate their percentages.
The data-color attribute is fine, but if it isn’t provided, we should still provide a way to let CSS generate the colors. Perhaps a good job for color-mix()?
What about different types of charts? Bar charts, anyone?
This is sorta screaming for a nice hover effect, like maybe scaling a slice and revealing it?
That’s all I could come up with for now, but I’m already planning to chip away at those at follow up with another piece (get it?!). Also, nothing is perfect without lots of feedback, so let me know what you would change or add to this pie chart so it can be truly perfect!
1 They are great people helping kids through extremely difficult times, so if you are interested in donating, you can find more on their socials. ↪️
Trying to Make the Perfect Pie Chart in CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Can we make pie chart that's semantic, with flexible markup, and avoids using a JavaScript library? Here's how I tackled it.
Trying to Make the Perfect Pie Chart in CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Trying to Make the Perfect Pie Chart in CSS

<p>CSS-only bar charts are one of those things we've tackled a bunch of times in different ways. But how can modern CSS features finally make it not only trivial, but fun?</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/css-bar-charts-using-modern-functions/">CSS Bar Charts Using Modern Functions</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>New CSS features can sometimes make it easier and more efficient to code designs we already knew how to create. This efficiency could stem from reduced code or hacks, or improved readability due to the new features.</p>



<p>In that spirit, let’s revamp what’s under the hood of a bar chart.</p>



<span id="more-391781"></span>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;ul class="chart" tabindex="0" role="list" aria-labelledby="chart-title">
  &lt;li class="chart-bar" data-value="32" tabindex="0" role="img" aria-label="32 percentage">32%&lt;/li>
  &lt;!-- etc. -->
&lt;/ul></code></pre>



<p>We begin by laying out a grid.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.chart {
  display: grid;
  grid-template-rows: repeat(100, 1fr);
  /* etc. */
}</code></pre>



<p>The chart metric is based on percentage, as in “some number <em>out of 100</em>.” Let’s say we&#8217;re working with a grid containing 100 rows. That ought to stress test it, right?</p>



<p>Next, we add the bars to the grid with the <code>grid-column</code> and <code>grid-row</code> properties:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.chart-bar {
  grid-column:  sibling-index();
  grid-row: span attr(data-value number);
  /* etc. */
}</code></pre>



<p>Right off the bat, I want to note a couple of things. First is that <a href="https://css-tricks.com/almanac/functions/s/sibling-index/"><code>sibling-index()</code></a> function. It’s brand new and has incomplete <a href="https://caniuse.com/wf-sibling-count" rel="noopener">browser support</a> as of this writing (come on, Firefox!), though it’s currently supported in the latest Chrome and Safari (but not on iOS apparently). Second is that <a href="https://css-tricks.com/almanac/functions/a/attr/"><code>attr()</code></a> function. We’ve had it for a while, but it was recently upgraded and <a href="https://amitmerchant.com/attr-function-types-css/" rel="noopener">now accepts data-attributes</a>. So when we have one of those in our markup — like <code>data-value="32"</code> — that’s something the function can read.</p>



<p>With those in place, that’s really all we need to create a pretty darn nice bar chart in vanilla CSS! The following demo has fallbacks in place so that you can still see the final result in case your browser hasn’t adopted those new features:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_ZYOOvmb" src="//codepen.io/anon/embed/ZYOOvmb?height=450&amp;theme-id=1&amp;slug-hash=ZYOOvmb&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed ZYOOvmb" title="CodePen Embed ZYOOvmb" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>Yes, that was easy to do, but it’s best to know exactly <em>why</em> it works. So, let’s break that down.</p>


<h3 class="wp-block-heading" id="automatically-establishing-grid-columns">Automatically Establishing Grid Columns</h3>


<p>Declaring the <code>sibling-index()</code> function on the <code>grid-column</code> property <em>explicitly</em> places the list items in consecutive columns. I say “explicit” because we’re telling the grid exactly where to place each item by its <code>data-value</code> attribute in the markup. It goes first <code>&lt;li&gt;</code> in first column, second <code>&lt;li&gt;</code> in second column, and so forth.</p>



<p>That’s the power of <code>sibling-index()</code> — the grid intelligently generates the order for us <a href="https://css-tricks.com/how-to-wait-for-the-sibling-count-and-sibling-index-functions/">without having to do it manually</a> through CSS variables.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* First bar: sibling-index() = 1 */
grid-column: sibling-index();

/* ...results in: */
grid-column: 1;
grid-column-start: 1; grid-column-end: auto;

/* Second bar: sibling-index() = 2 */
grid-column: sibling-index();

/* ...results in: */
grid-column: 2;
grid-column-start: 2; grid-column-end: auto;

/* etc. */</code></pre>


<h3 class="wp-block-heading" id="automatically-establishing-grid-rows">Automatically Establishing Grid Rows</h3>


<p>It’s pretty much the same thing! But in this case, each bar occupies a certain number of rows based on the percentage it represents. The grid gets those values from the <code>data-value</code> attribute in the markup, effectively telling the grid how tall each bar in the chart should be.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* First bar: data-value="32" */
grid-row: span attr(data-value number);

/* ...results in: */
grid-row: span 32

/* Second bar: data-value="46" */
grid-row: span attr(data-value number);

/* ...results in: */
grid-row: span 46</code></pre>



<p>The <code>attr()</code> function, when provided with a <em>data type</em> parameter (the parameter value <code>number</code> in our case), <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/attr#return_value" rel="noopener">casts the value retrieved by</a> <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/attr#return_value" rel="noopener"><code>attr()</code></a> <a href="https://css-tricks.com/almanac/functions/a/attr/#aa-css-attr-data-types">into that specific type</a>. In our example, the <code>attr()</code> function returns the value of <code>data-value</code> as a <code>&lt;number&gt;</code> type, which is then used to determine the number of rows to span for each bar.</p>


<h3 class="wp-block-heading" id="let-s-make-different-charts-">Let’s Make Different Charts!</h3>


<p>Since we have the nuts and bolts down on this approach, I figured I’d push things a bit and demonstrate how we can apply the same techniques for all kinds of CSS-only charts.</p>



<p>For example, we can use <code>grid-row</code> values to adjust the vertical direction of the bars:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_azZBNQL" src="//codepen.io/anon/embed/azZBNQL?height=450&amp;theme-id=1&amp;slug-hash=azZBNQL&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed azZBNQL" title="CodePen Embed azZBNQL" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>Or we can skip bars altogether and use markers instead:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_WbxowYb" src="//codepen.io/anon/embed/WbxowYb?height=450&amp;theme-id=1&amp;slug-hash=WbxowYb&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed WbxowYb" title="CodePen Embed WbxowYb" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_YPWpqRO" src="//codepen.io/anon/embed/YPWpqRO?height=450&amp;theme-id=1&amp;slug-hash=YPWpqRO&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed YPWpqRO" title="CodePen Embed YPWpqRO" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>We can also swap the columns and rows for horizontal bar charts:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_pvbNyqy" src="//codepen.io/anon/embed/pvbNyqy?height=450&amp;theme-id=1&amp;slug-hash=pvbNyqy&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed pvbNyqy" title="CodePen Embed pvbNyqy" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="wrapping-up">Wrapping up</h3>


<p>Pretty exciting, right? Just look at all the ways we used to pull this stuff off before the days of <code>sibling-index()</code> and an upgraded <code>attr()</code>:</p>



<ul class="wp-block-list">
<li><a href="https://css-tricks.com/making-charts-with-css/">Making Charts with CSS</a> (Robin Rendle, 2015)</li>



<li><a href="https://css-tricks.com/making-a-bar-chart-with-css-grid/">Making A Bar Chart with CSS Grid</a> (Robin Rendle, 2017)</li>



<li><a href="https://css-tricks.com/css-charts-grid-custom-properties/">More CSS Charts, with Grid &amp; Custom Properties</a> (Miriam Suzanne, 2017)</li>



<li><a href="https://css-tricks.com/overlapping-bar-charts/">Overlapping Bar Charts</a> (Saleh Mubasher, 2022)</li>
</ul>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/css-bar-charts-using-modern-functions/">CSS Bar Charts Using Modern Functions</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


New CSS features can sometimes make it easier and more efficient to code designs we already knew how to create. This efficiency could stem from reduced code or hacks, or improved readability due to the new features.
In that spirit, let’s revamp what’s under the hood of a bar chart.




<ul class="chart" tabindex="0" role="list" aria-labelledby="chart-title">
  <li class="chart-bar" data-value="32" tabindex="0" role="img" aria-label="32 percentage">32%</li>
  
</ul>
We begin by laying out a grid.
.chart {
  display: grid;
  grid-template-rows: repeat(100, 1fr);
  /* etc. */
}
The chart metric is based on percentage, as in “some number out of 100.” Let’s say we’re working with a grid containing 100 rows. That ought to stress test it, right?
Next, we add the bars to the grid with the grid-column and grid-row properties:
.chart-bar {
  grid-column:  sibling-index();
  grid-row: span attr(data-value number);
  /* etc. */
}
Right off the bat, I want to note a couple of things. First is that sibling-index() function. It’s brand new and has incomplete browser support as of this writing (come on, Firefox!), though it’s currently supported in the latest Chrome and Safari (but not on iOS apparently). Second is that attr() function. We’ve had it for a while, but it was recently upgraded and now accepts data-attributes. So when we have one of those in our markup — like data-value="32" — that’s something the function can read.
With those in place, that’s really all we need to create a pretty darn nice bar chart in vanilla CSS! The following demo has fallbacks in place so that you can still see the final result in case your browser hasn’t adopted those new features:
CodePen Embed Fallback
Yes, that was easy to do, but it’s best to know exactly why it works. So, let’s break that down.
Automatically Establishing Grid Columns
Declaring the sibling-index() function on the grid-column property explicitly places the list items in consecutive columns. I say “explicit” because we’re telling the grid exactly where to place each item by its data-value attribute in the markup. It goes first <li> in first column, second <li> in second column, and so forth.
That’s the power of sibling-index() — the grid intelligently generates the order for us without having to do it manually through CSS variables.
/* First bar: sibling-index() = 1 */
grid-column: sibling-index();

/* ...results in: */
grid-column: 1;
grid-column-start: 1; grid-column-end: auto;

/* Second bar: sibling-index() = 2 */
grid-column: sibling-index();

/* ...results in: */
grid-column: 2;
grid-column-start: 2; grid-column-end: auto;

/* etc. */
Automatically Establishing Grid Rows
It’s pretty much the same thing! But in this case, each bar occupies a certain number of rows based on the percentage it represents. The grid gets those values from the data-value attribute in the markup, effectively telling the grid how tall each bar in the chart should be.
/* First bar: data-value="32" */
grid-row: span attr(data-value number);

/* ...results in: */
grid-row: span 32

/* Second bar: data-value="46" */
grid-row: span attr(data-value number);

/* ...results in: */
grid-row: span 46
The attr() function, when provided with a data type parameter (the parameter value number in our case), casts the value retrieved by attr() into that specific type. In our example, the attr() function returns the value of data-value as a <number> type, which is then used to determine the number of rows to span for each bar.
Let’s Make Different Charts!
Since we have the nuts and bolts down on this approach, I figured I’d push things a bit and demonstrate how we can apply the same techniques for all kinds of CSS-only charts.
For example, we can use grid-row values to adjust the vertical direction of the bars:
CodePen Embed Fallback
Or we can skip bars altogether and use markers instead:
CodePen Embed Fallback
CodePen Embed Fallback
We can also swap the columns and rows for horizontal bar charts:
CodePen Embed Fallback
Wrapping up
Pretty exciting, right? Just look at all the ways we used to pull this stuff off before the days of sibling-index() and an upgraded attr():
Making Charts with CSS (Robin Rendle, 2015)
Making A Bar Chart with CSS Grid (Robin Rendle, 2017)
More CSS Charts, with Grid & Custom Properties (Miriam Suzanne, 2017)
Overlapping Bar Charts (Saleh Mubasher, 2022)
CSS Bar Charts Using Modern Functions originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

CSS-only bar charts are one of those things we've tackled a bunch of times in different ways. But how can modern CSS features finally make it not only trivial, but fun?
CSS Bar Charts Using Modern Functions originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

CSS Bar Charts Using Modern Functions

<p>You’d think that publishing a VS Code extension is an easy process, but it’s not. You have to publish your theme in at least two places.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/no-hassle-visual-code-theming-publishing-an-extension/">No Hassle Visual Code Theming: Publishing an Extension</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p><a href="https://css-tricks.com/no-hassle-visual-studio-code-theming-building-an-extension/">Creating your theme is the fun part.</a> After you’re done, the next step is to publish your theme so you — and others — can enjoy your creation!</p>



<p>You’d think that publishing a VS Code extension is an easy process, but it’s not. (Maybe I’m used to the ease of publishing npm packages and take registries for granted.)</p>



<p>Anyway, you have to publish your theme in two places:</p>



<ol class="wp-block-list">
<li><a href="https://marketplace.visualstudio.com" rel="noopener">Visual Studio Marketplace</a> for VS Code users</li>



<li><a href="https://open-vsx.org" rel="noopener">Open VSX</a> for other text editors</li>
</ol>



<p>You might also want to publish to <a href="https://www.npmjs.com" rel="noopener">npm</a> for others to use your theme easily for other contexts — like syntax highlighting via <a href="https://shiki.style/guide/" rel="noopener">Shiki</a>.</p>



<span id="more-390379"></span>


<h3 class="wp-block-heading" id="preparing-your-theme">Preparing your theme</h3>


<p>When you name your theme, you cannot put it under a scope like <code>@scope/theme-name</code>. Doing so will prevent you from publishing to Open VSX.</p>



<p>So, make sure your theme name is unscoped. (The <code>theme</code> word is optional):</p>



<pre rel="JSON" class="wp-block-csstricks-code-block language-javascript" data-line=""><code markup="tt">{
  "name": "twilight-cosmos-theme",
}</code></pre>



<p>To include an icon for your theme, you need a <code>128px</code> square image file that can be accessible within your project. Put this under the <code>icon</code> property to point to the file:</p>



<pre rel="JSON" class="wp-block-csstricks-code-block language-javascript" data-line=""><code markup="tt">{
  "icon": "path/to/icon.png",
}</code></pre>



<p>Next, you want to ensure that you have a <a href="https://code.visualstudio.com/api/references/contribution-points" rel="noopener"><code>contributes</code></a> key in your <code>package.json</code> file. VS Code and other text editors search for this to find themes.</p>



<pre rel="JSON" class="wp-block-csstricks-code-block language-javascript" data-line=""><code markup="tt">{
  "contributes": {
    "themes": [
      {
        "label": "&lt;Theme Name>",
        "uiTheme": "vs-dark",
        "path": "./&lt;path-to-theme>.json"
      }
    ]
  },
}</code></pre>



<p>Finally, you want to include several keywords to make your theme searchable on both VS Marketplace and Open VSX.</p>



<p>If you&#8217;re having problems with this, give AI your theme file and ask it to generate keywords for you &#x1f609;</p>



<pre rel="JSON" class="wp-block-csstricks-code-block language-javascript" data-line=""><code markup="tt">{
  "keywords": [
    "theme",
    "dark theme",
    "twilight",
    "cosmos",
    "color-theme",
    "dark",
    "purple",
    "blue",
    "vscode-theme"
  ],
}</code></pre>


<h3 class="wp-block-heading" id="publishing-to-visual-studio-marketplace">Publishing to Visual Studio Marketplace</h3>


<p>Microsoft lets you publish to Visual Studio Marketplace via <a href="https://www.npmjs.com/package/@vscode/vsce" rel="noopener"><code>vsce</code></a> if you have a personal access token from an <a href="https://azure.microsoft.com/en-us/products/devops/?nav=min" rel="noopener">Azure DevOps account</a>.</p>



<p>Unfortunately, while creating this article, I encountered several problems setting up my Azure Devops account so I had to publish my extension via the manual route.</p>



<p>I&#8217;ll talk about both routes here.</p>



<p>Before publishing, you need to have a Visual Studio Marketplace account. So, <a href="https://marketplace.visualstudio.com" rel="noopener">sign up</a> for one if you don&#8217;t have it yet.</p>



<p>Then do the following:</p>



<ul class="wp-block-list">
<li>Click on <strong>Publish Extension</strong>.</li>



<li>Create a publisher account.</li>
</ul>



<p>This step is needed for publishing both via <code>vsce</code> and the manual route.</p>


<h4 class="wp-block-heading" id="publishing-via-vsce">Publishing via VSCE</h4>


<p>For this to work, you need a Azure DevOps account. When you have that, you can create a Personal Access Token with <a href="https://code.visualstudio.com/api/working-with-extensions/publishing-extension#get-a-personal-access-token" rel="noopener">these steps</a>.</p>



<p>Note: It&#8217;s kinda irritating that you can&#8217;t have an lifetime access token with Azure DevOps. The maximum expiry is about one year later.</p>



<p>Also note: I had immense trouble creating my Azure DevOps account when I tried this — the back end kept hanging and I couldn&#8217;t find the right page, even when I copy-pasted the URL! Anyway, don&#8217;t be alarmed if this happens to you. You might just need to wait 1-2 days before you try again. It will work, eventually.</p>



<p>Once you have the personal access token, the rest of the steps is pretty straightforward.</p>



<p>First, you login to VSCE with your publisher ID that you created in Visual Studio Marketplace. (Insert the publisher ID, not the user ID!).</p>



<pre rel="Terminal" class="wp-block-csstricks-code-block language-none" data-line=""><code markup="tt">npx vsce login &lt;publisher_id></code></pre>



<p>You&#8217;ll have to insert the access token when it asks you to. Then, run the next command to publish to the marketplace:</p>



<pre rel="Terminal" class="wp-block-csstricks-code-block language-none" data-line=""><code markup="tt">npx vsce publish</code></pre>



<p>And you&#8217;re done!</p>


<h4 class="wp-block-heading" id="publishing-manually">Publishing manually</h4>


<p>You&#8217;ll have to follow this route if you had problems with the personal access token like I did. Thankfully, it&#8217;s pretty straightforward as well. You can go to Visual Studio Marketplace and do the following:</p>



<ul class="wp-block-list">
<li>Click on <strong>Publish Extensions</strong>.</li>



<li>Click <strong>New Extension</strong>.</li>



<li>Use the <code>vsce package</code> command to package your extension as a <a href="https://learn.microsoft.com/en-us/visualstudio/extensibility/anatomy-of-a-vsix-package?view=vs-2022" rel="noopener"><code>visx</code> file</a>.</li>



<li>Drag and drop the packaged <code>visx</code> file to upload your extension.</li>
</ul>



<figure class="wp-block-image size-full ticss-04b39e63"><img data-recalc-dims="1" loading="lazy" decoding="async" width="544" height="289" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-11-at-16.00.56.png?resize=544%2C289" alt="Sowing a dialog window with instructions to upload a Visual Code extension with drag and drop." class="wp-image-390382" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-11-at-16.00.56.png?w=544&amp;ssl=1 544w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-11-at-16.00.56.png?resize=300%2C159&amp;ssl=1 300w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>



<p>That&#8217;s it!</p>


<h4 class="wp-block-heading" id="getting-verified-on-visual-studio-code">Getting verified on Visual Studio Code</h4>


<p>If this is your first extension, you can only get &#8220;verified&#8221; on the Visual Studio Marketplace if your extension is at least six months old. So, if you want to get verified, set a reminder in six months and <a href="https://code.visualstudio.com/api/working-with-extensions/publishing-extension#verify-a-publisher" rel="noopener">visit this page</a> for more information.</p>


<h3 class="wp-block-heading" id="publishing-to-open-vsx">Publishing to Open VSX</h3>


<p>Thanks to Claude, I understood VS Code uses the Visual Studio Marketplace, but other text editors, like Cursor, use <a href="https://open-vsx.org" rel="noopener">Open VSX</a>.</p>



<p>Publishing to Open VSX is a bit more complex. You have to:</p>



<ul class="wp-block-list">
<li>Login to Open VSX via GitHub.</li>



<li>Create an <a href="https://auth.eclipse.org/auth/realms/community/protocol/openid-connect/auth?response_type=code&amp;client_id=open-vsx-org&amp;scope=openid%20profile%20email%20openvsx_publisher_agreement&amp;state=Rx2_vmdvfW1oPPlcyMn6sm1PSPFhE-60hRWEovGfymM%3D&amp;redirect_uri=https://open-vsx.org/login/oauth2/code/eclipse&amp;nonce=0QgnG2_pujB-H0jmkLITcNSC8GO3HKsfWGp-QOeNqls" rel="noopener">Eclipse Foundation</a> account</li>



<li>Link your GitHub repository to the Eclipse Foundation account.</li>



<li>Sign their agreement.</li>



<li>Create a <a href="https://open-vsx.org/user-settings/namespaces" rel="noopener">publisher namespace</a> and add this as the <code>publisher</code> in your <code>package.json</code> file.</li>



<li>Create an <a href="https://open-vsx.org/user-settings/tokens" rel="noopener">access token</a>.</li>



<li>Then, finally, run <code>npx ovsx publish</code> to publish your package.</li>
</ul>



<p>Likewise, <code>ovsx</code> will ask you for a personal access token when you try to publish for the first time. Thankfully, <code>ovsx</code> seems to have a lifetime access token seems so we don&#8217;t have to worry about it expiring.</p>


<h4 class="wp-block-heading" id="claiming-the-publisher-namespace">Claiming the publisher namespace</h4>


<p>This is essentially getting &#8220;verified&#8221; with Open VSX, but Open VSX calls it &#8220;claiming&#8221; the publisher namespace to get verified. Without harping on the language too much — this process takes a bit of to-and-fro but can be done now (instead of six months later).</p>



<p>Once you have created a publisher namespace, you&#8217;ll see a glaring warning sign:</p>



<figure class="wp-block-image size-full"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1096" height="194" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-12-at-11.38.47%402x.png?resize=1096%2C194" alt="Bright orange warning banner that says, This namespace is not verified. See the documentation to learn about claiming namespaces." class="wp-image-390380" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-12-at-11.38.47%402x.png?w=1096&amp;ssl=1 1096w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-12-at-11.38.47%402x.png?resize=300%2C53&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-12-at-11.38.47%402x.png?resize=1024%2C181&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/CleanShot-2025-11-12-at-11.38.47%402x.png?resize=768%2C136&amp;ssl=1 768w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>



<p>To claim the publisher namespace, you need to <a href="https://github.com/EclipseFdn/open-vsx.org/issues/new/choose" rel="noopener">create a GitHub issue with Eclipse Foundation</a> and state that you want to claim the namespace.</p>



<p>In that issue:</p>



<ul class="wp-block-list">
<li>Include your GitHub repository (if you make it publicly available).</li>



<li>Offer to give access temporarily to your GitHub repository (if it&#8217;s private).</li>
</ul>



<p>And someone will handle the rest.</p>



<p>The team at Eclipse Foundation seems to be pretty responsive, so I wouldn&#8217;t worry about communication breakdown here.</p>


<h3 class="wp-block-heading" id="including-images-for-your-theme">Including images for your theme</h3>


<p>It makes sense to include images to showcase your theme in the <code>Readme.md</code> file. Doing so allows users to get a sense of your theme colors before deciding whether they want to download it.</p>



<p>Unfortunately, both VS Marketplace and Open VSX do not allow you to use relative URLs — images will be broken if you use relative links from your repository — so you have to link to an absolute URL instead.</p>



<p>The best place to link to is the GitHub repository, as long as it is set to public access.</p>



<p>The URL will be something like this:</p>



<pre rel="Markdown" class="wp-block-csstricks-code-block language-svg" data-line=""><code markup="tt">![Alt Text](https://raw.githubusercontent.com/&lt;github_username>/&lt;repo-name>/master/&lt;path-to-image>)</code></pre>


<h3 class="wp-block-heading" id="wrapping-up">Wrapping up</h3>


<p>It can be tedious to publish your first VS Code editor theme. But don&#8217;t let that process stop you from letting you — and others &#8211; enjoy your theme!</p>



<p>If you&#8217;re wondering, my first theme is called Twilight Cosmos. You can find out more about the creation process <a href="https://css-tricks.com/no-hassle-visual-studio-code-theming-building-an-extension/">in my previous article</a>.</p>



<p>Enjoy the (somewhat frustrating) process! You&#8217;ll finish it before you know it.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/no-hassle-visual-code-theming-publishing-an-extension/">No Hassle Visual Code Theming: Publishing an Extension</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Creating your theme is the fun part. After you’re done, the next step is to publish your theme so you — and others — can enjoy your creation!
You’d think that publishing a VS Code extension is an easy process, but it’s not. (Maybe I’m used to the ease of publishing npm packages and take registries for granted.)
Anyway, you have to publish your theme in two places:
Visual Studio Marketplace for VS Code users
Open VSX for other text editors
You might also want to publish to npm for others to use your theme easily for other contexts — like syntax highlighting via Shiki.



Preparing your theme
When you name your theme, you cannot put it under a scope like @scope/theme-name. Doing so will prevent you from publishing to Open VSX.
So, make sure your theme name is unscoped. (The theme word is optional):
{
  "name": "twilight-cosmos-theme",
}
To include an icon for your theme, you need a 128px square image file that can be accessible within your project. Put this under the icon property to point to the file:
{
  "icon": "path/to/icon.png",
}
Next, you want to ensure that you have a contributes key in your package.json file. VS Code and other text editors search for this to find themes.
{
  "contributes": {
    "themes": [
      {
        "label": "<Theme Name>",
        "uiTheme": "vs-dark",
        "path": "./<path-to-theme>.json"
      }
    ]
  },
}
Finally, you want to include several keywords to make your theme searchable on both VS Marketplace and Open VSX.
If you’re having problems with this, give AI your theme file and ask it to generate keywords for you 😉
{
  "keywords": [
    "theme",
    "dark theme",
    "twilight",
    "cosmos",
    "color-theme",
    "dark",
    "purple",
    "blue",
    "vscode-theme"
  ],
}
Publishing to Visual Studio Marketplace
Microsoft lets you publish to Visual Studio Marketplace via vsce if you have a personal access token from an Azure DevOps account.
Unfortunately, while creating this article, I encountered several problems setting up my Azure Devops account so I had to publish my extension via the manual route.
I’ll talk about both routes here.
Before publishing, you need to have a Visual Studio Marketplace account. So, sign up for one if you don’t have it yet.
Then do the following:
Click on Publish Extension.
Create a publisher account.
This step is needed for publishing both via vsce and the manual route.
Publishing via VSCE
For this to work, you need a Azure DevOps account. When you have that, you can create a Personal Access Token with these steps.
Note: It’s kinda irritating that you can’t have an lifetime access token with Azure DevOps. The maximum expiry is about one year later.
Also note: I had immense trouble creating my Azure DevOps account when I tried this — the back end kept hanging and I couldn’t find the right page, even when I copy-pasted the URL! Anyway, don’t be alarmed if this happens to you. You might just need to wait 1-2 days before you try again. It will work, eventually.
Once you have the personal access token, the rest of the steps is pretty straightforward.
First, you login to VSCE with your publisher ID that you created in Visual Studio Marketplace. (Insert the publisher ID, not the user ID!).
npx vsce login <publisher_id>
You’ll have to insert the access token when it asks you to. Then, run the next command to publish to the marketplace:
npx vsce publish
And you’re done!
Publishing manually
You’ll have to follow this route if you had problems with the personal access token like I did. Thankfully, it’s pretty straightforward as well. You can go to Visual Studio Marketplace and do the following:
Click on Publish Extensions.
Click New Extension.
Use the vsce package command to package your extension as a visx file.
Drag and drop the packaged visx file to upload your extension.




That’s it!
Getting verified on Visual Studio Code
If this is your first extension, you can only get “verified” on the Visual Studio Marketplace if your extension is at least six months old. So, if you want to get verified, set a reminder in six months and visit this page for more information.
Publishing to Open VSX
Thanks to Claude, I understood VS Code uses the Visual Studio Marketplace, but other text editors, like Cursor, use Open VSX.
Publishing to Open VSX is a bit more complex. You have to:
Login to Open VSX via GitHub.
Create an Eclipse Foundation account
Link your GitHub repository to the Eclipse Foundation account.
Sign their agreement.
Create a publisher namespace and add this as the publisher in your package.json file.
Create an access token.
Then, finally, run npx ovsx publish to publish your package.
Likewise, ovsx will ask you for a personal access token when you try to publish for the first time. Thankfully, ovsx seems to have a lifetime access token seems so we don’t have to worry about it expiring.
Claiming the publisher namespace
This is essentially getting “verified” with Open VSX, but Open VSX calls it “claiming” the publisher namespace to get verified. Without harping on the language too much — this process takes a bit of to-and-fro but can be done now (instead of six months later).
Once you have created a publisher namespace, you’ll see a glaring warning sign:




To claim the publisher namespace, you need to create a GitHub issue with Eclipse Foundation and state that you want to claim the namespace.
In that issue:
Include your GitHub repository (if you make it publicly available).
Offer to give access temporarily to your GitHub repository (if it’s private).
And someone will handle the rest.
The team at Eclipse Foundation seems to be pretty responsive, so I wouldn’t worry about communication breakdown here.
Including images for your theme
It makes sense to include images to showcase your theme in the Readme.md file. Doing so allows users to get a sense of your theme colors before deciding whether they want to download it.
Unfortunately, both VS Marketplace and Open VSX do not allow you to use relative URLs — images will be broken if you use relative links from your repository — so you have to link to an absolute URL instead.
The best place to link to is the GitHub repository, as long as it is set to public access.
The URL will be something like this:
![Alt Text](https://raw.githubusercontent.com/<github_username>/<repo-name>/master/<path-to-image>)
Wrapping up
It can be tedious to publish your first VS Code editor theme. But don’t let that process stop you from letting you — and others – enjoy your theme!
If you’re wondering, my first theme is called Twilight Cosmos. You can find out more about the creation process in my previous article.
Enjoy the (somewhat frustrating) process! You’ll finish it before you know it.
No Hassle Visual Code Theming: Publishing an Extension originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

You’d think that publishing a VS Code extension is an easy process, but it’s not. You have to publish your theme in at least two places.
No Hassle Visual Code Theming: Publishing an Extension originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

No Hassle Visual Code Theming: Publishing an Extension

<p>I've always thought that creating a VS Code theme was a lot of work. But lo and behold, it took less than six hours to get it working, then a day or two to polish up my final tweaks.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/no-hassle-visual-studio-code-theming-building-an-extension/">No-Hassle Visual Studio Code Theming: Building an Extension</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Years ago, when I read Sarah Drasner’s article on creating a VS Code theme, I silently thought to myself, That’s a lot of work… I’m never going to make a theme…
But lo and behold, I went ahead and made one — and it took less than six hours to get most of the theme working, then a day or two to polish up my final tweaks.








In this article, I want to you walk you through my process of creating this theme — along with the actual steps I took to create it.
I think talking about the process is powerful because I went from Nah, too much work to Oh, I can do it to It’s done..? all within a matter of hours. (The rest is simply time spent polishing).
I never wanted to make a VS Code theme…
I was in the middle of redesigning my website. I’ve been rocking a super duper old design that I’ve wanted to change for years — and I finally started moving.




I used Dracula Theme for code snippets in my old design and it worked since Dracula was the only thing that provided a splash of color in my otherwise stark design.
But it didn’t work well with my new site design.




All I wanted to do was to improve syntax highlighting for the code blocks so they’re more aligned with the rest of the site.
That was the beginning of everything.
Shiki CSS variable theming made it simple
I use Astro for my website. Shiki is a syntax highlighter that is built into Astro by default.
With some quick research, I realized Shiki allows you to create themes with CSS variables — and there are only a handful of colors we need to choose.




That doesn’t sound too complicated, so I got AI to help flesh out a Shiki theme based on the CSS variables. Here’s the CSS and JavaScript you need if you’re using Astro as well:
:root {
  --shiki-foreground: #eeeeee;
  --shiki-background: #333333;
  --shiki-token-constant: #660000;
  --shiki-token-string: #770000;
  --shiki-token-comment: #880000;
  --shiki-token-keyword: #990000;
  --shiki-token-parameter: #aa0000;
  --shiki-token-function: #bb0000;
  --shiki-token-string-expression: #cc0000;
  --shiki-token-punctuation: #dd0000;
  --shiki-token-link: #ee0000;
}

pre.shiki,
pre.astro-code {
  padding: 1rem;
  border-radius: 0.5rem;
  color: var(--shiki-foreground);
  background-color: var(--shiki-background);
  overflow-x: auto;
}

pre.shiki code,
pre.astro-code code {
  padding: 0;
  font-size: inherit;
  line-height: inherit;
  color: inherit;
  background: none;
}
import { createCssVariablesTheme } from 'shiki/core'

const shikiVariableTheme = createCssVariablesTheme({
  name: 'css-variables',
  variablePrefix: '--shiki-',
  fontStyle: true,
})

export default defineConfig ({
  // ...
  markdown: {
    shikiConfig: {
      theme: shikiVariableTheme
    }
  }
})
I did a quick experiment with the colors I had already used for my website and compared it to various popular themes, like Dracula, Sarah’s Night Owl, and Moonlight 2.




This gave me the confidence to push my own theme a little further — because the syntax highlighting was shaping up in the right direction.
But, to push this further, I had to ditch CSS variable theming and dive into TextMate tokens. It was essential because certain code blocks looked absolutely horrendous and TextMate tokens provide more granular control of how and what gets color.
This is where the “hard” part begins.
Getting AI to help with TextMate scopes
Thankfully, AI is here to help. If AI wasn’t here, I might have just given up at this point.
Here’s what I got my AI to do:
I said I wanted to make a custom theme.
I told it to create a scaffold for me.
I asked it to look for Moonlight 2’s theme files as a reference and create the TextMate scope tokens based on that.
I got it to consolidate the colors used into semantic keywords like foreground, background, keyword — like the Shiki CSS variable theme.
And I asked it to pull all of the colors into a color object so I can have a palette object that includes only the semantic names.
Here’s roughly what it created:
const colors = {
  purple: '...',
  blue: '...',
  // ...
}

const palette = {
  foreground: '...',
  background: '...',
  // ...
}

export default {
  colors: {
    // Used for theming the text editor
  },
  displayName: 'Display Name of your Theme',
  name: 'your-theme-name',
  tokenColors: [
    {
      name: 'Scope name (optional)',
      scope: [/*scopes used*/],
      settings: {
        foreground: /* change color */,
        background: /* background of the text */,
        fontStyle: /* normal, bold or italic */,
      }
    }
  ]
}
You need to provide JSON for VS Code to configure things, so I also got AI to create a build script that converts the above format into a .json file.
You can find the build script and everything I used in the GitHub Repo.
Debugging locally
It was impossible to debug syntax highlighting on my website because I had to manually restart the server whenever I changed a variable.
So, I asked AI for a suggestion.
It said that I can use VS Code’s Extension Host for local development, then proceeded to created a .vscode/launch.json file with the following contents:
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Extension",
      "type": "extensionHost",
      "request": "launch",
      "args": [
        "--extensionDevelopmentPath=${workspaceFolder}"
      ]
    }
  ]
}
To run this, you can use F5 (Windows) or Fn + F5 (Mac) and a new editor window will pop up — in this new window, you can change the theme to your custom theme.
Spotting a window that uses the extension host is quite simple because:
If you change your theme, that window will be a different theme compared to your other opened text editors.
The Extension Host keyword is prominent in the title.




Now, everything has been a blur at this point, so I can’t remember if you need to include the following into your package.json file for theme switching to work in the extension host. If so, include it:
{
  "contributes": {
    "themes": [
      {
        "label": "Your Theme Name",
        "uiTheme": "vs-dark",
        "path": "<path-to-your-theme>.json"
      }
    ]
  }
}
Understanding TextMate scopes
At first, I copy-pasted images and tried to get AI to adjust various tokens to the colors I chose. But it got frustrating quite quickly.
Either:
the AI got the textmate scope wrong, or
it was overwritten by something else.
I couldn’t tell. But thankfully you can debug the TextMate scopes easily with a “Developer: Inspector Editor Tokens and Scopes” command.




When you’re in this mode, you can click on any text and a window will pop up. This contains all the information you need to adjust TextMate scopes.




Here’s how to read what’s going on:
Foreground: Tells you the current active scope. In this case, the active scope is variable.
TextMate scopes: Tells you what are the available TextMate scopes you can use for this specific token.
TextMate scopes work in an interesting way. I figured out the following by experimenting, so it might not be 100% accurate:
You can use any part of the available scopes. variable, variable.prop, and variable.prop.css all work.
You can increase specificity by stating more properties. variable.prop.css > variable.prop > variable in terms of specificity.
The higher scope is more specific than the lower one. variable > meta.function.misc.css.
You can other scopes with them like CSS selectors if you need to overwrite a higher scope. meta.function variable > variable
How I chose colors for the theme
This is the most important topic when creating a theme. There’s no point having the theme if syntax highlighting doesn’t support the developer in reading code.
Two articles come into my mind here:
Creating a VS Code Theme by Sarah Drasner
Everyone is getting syntax highlighting wrong by Tonsky
Essentially, the principles that I took away from both articles are:
We want highlights to stand out.
Colors will look very similar to each other if you make use the same lightness and chroma, and it’ll be hard to tell them apart.
If everything is highlighted, nothing is highlighted.
If everything is important, nothing is.
Basically, we’re talking about the principle of contrast when designing. Since I’m already designing for someone to read, the very next thoughts that came were:
How do I guide my eyes?
What are important elements that I have to see/know?
What elements are less important?
With that, I began working:
Functions and methods were important so they had to be strong, so I used cyan which is the strongest color in my palette.
The export keyword is also important since it signifies an export!
Keywords like import and function can be rather muted, so purple it is.
Strings can be green — cos they seem rather pleasing in a list of text within a JSON file.
If text wasn’t green…this might be hard to look at.



I played around with the rest of the colors a little, but I eventually settled with the following:
Constants are orange because it’s kinda easy to spot them
Variables are white-ish because that’s the bulk of the text — adding colors to them creates the “Christmas Lights Diarrhea” effect Tonsky mentioned.
Properties are blue because they’re like workhorses that needs color differentiation, but not enough to draw too much attention.




Then I moved onto HTML/Astro/Svelte:
Tags are red because they’re kinda important — and red is easier to read that cyan.
Attributes are purple for the same reason as keywords.
Components are orange because they need to be different from Tags.
Bonus points: Tags and Components are related — so red and orange feels just right here.




And, finally, CSS syntax highlighting. Almost everything seemed right at this point, except that:
CSS Functions should be cyan like that in JS.
Punctuation should be muted so we can easily differentiate the -- from the rest of the text.
Property can be green because blue is too dull in this context — and green is nice on the eyes when contrasted with other powerful colors.




It’s a pity that syntax highlighting for nested classes goes a little bit haywire (they’re green, but they should be orange), but there’s nothing much I can do about it.



Debugging colors
VS Code is built on Electron, so it’s easy to debug and test colors. What I had to do was fire up devtools, inspect the color I wanted to change, and change them directly to get a live update!



Wrapping up
The most important I thing I learned during this process is to go with the flow. One opening can lead to another, then another, and something what seems “impossible” can become “Oh, it’s done?” in a matter of hours.
I call my theme Twilight Cosmos (AI helped with the naming). You can find it on:
Visual Studio Marketplace if you use VS Code
Open VSX if you use Cursor or other editors
npm if you wanna use the for Shiki
How did I publish my extension? That’s the subject of a brief follow-up article that I’m working on.
In the meantime, here’s the GitHub repo if you want to build upon whatever I have done. Feel free to suggest edits to improve this theme too!
Finally, sign up for my email newsletter if you’re interested in hearing my creation adventures. :)
That’s it. Thanks for reading and I hope you had a blast!
No-Hassle Visual Studio Code Theming: Building an Extension originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I've always thought that creating a VS Code theme was a lot of work. But lo and behold, it took less than six hours to get it working, then a day or two to polish up my final tweaks.
No-Hassle Visual Studio Code Theming: Building an Extension originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

No-Hassle Visual Studio Code Theming: Building an Extension

<p>Neither Chrome, Safari, nor Firefox have shipped new features in the last couple of weeks, but fear not because leading this issue of What’s !important is some of the web development industry’s best educators with, frankly, some killer content.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/whats-important-4/">What’s !important #4: Videos &amp; View Transitions, Named Media Queries, How Browsers Work, and More</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>Neither Chrome, Safari, nor Firefox have shipped new features in the last couple of weeks, but fear not because leading this issue of What’s !important is some of the web development industry’s best educators with, frankly, some <em>killer</em> content.</p>



<span id="more-391967"></span>


<h3 class="wp-block-heading" id="maintaining-video-state-across-different-pages-using-view-transitions">Maintaining video state across different pages using view transitions</h3>


<p>Chris Coyier demonstrates <a href="https://frontendmasters.com/blog/view-transitions-playing-video/" rel="noopener">how to maintain a video’s state across different pages using CSS view transitions</a>. He notes that this is fairly easy to do with same-page view transitions, but with multi-page view transitions you’ll need to leverage JavaScript’s <code>pageswap</code> event to save information about the video’s state in <code>sessionStorage</code> as a JSON string (works with audio and iframes too), and then use that information to restore the state on <code>pagereveal</code>. Yes, there’s a <em>tiiiiny</em> bit of audio stutter because we’re technically faking it, but it’s still super neat.</p>



<p>Also, CodePen, which I’m sure you already know was founded by Chris, announced a <a href="https://codepen.io/beta" rel="noopener">private beta of CodePen 2.0</a>, which you can request to be a part of. One of the benefits of CodePen 2.0 is that you can create actual projects with multiple files, which means that you can create view transitions in CodePen. Pretty cool!</p>


<h3 class="wp-block-heading" id="how-to-name-media-queries">How to ‘name’ media queries</h3>


<p>Kevin Powell shows us <a href="https://www.youtube.com/watch?v=dag6qCNH0Nw" rel="noopener">how to leverage CSS cascade layers to ‘name’ media queries</a>. This technique isn’t as effective as <a href="https://css-tricks.com/can-we-have-custom-media-queries-please/"><code>@custom-media</code></a> (<a href="https://www.youtube.com/watch?v=dag6qCNH0Nw&amp;lc=UgxtIYf38HlXJKM7TKB4AaABAg" rel="noopener">or even container style queries, as one commenter suggested</a>), but until those are supported in all web browsers, Kevin’s trick is pretty creative.</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="Named media query hack" width="500" height="281" src="https://www.youtube.com/embed/dag6qCNH0Nw?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p>Adam Argyle reminded us last week that <a href="https://nerdy.dev/custom-media" rel="noopener"><code>@custom-media</code> is being trialed in Firefox Nightly</a> (no word on <a href="https://css-tricks.com/almanac/rules/c/container/#aa-style-queries">container style queries</a> yet), but if you get up to speed on <a href="https://css-tricks.com/css-cascade-layers/">CSS cascade layers</a>, you can utilize Kevin’s trick in the meantime.</p>


<h3 class="wp-block-heading" id="vales-css-reset">Vale’s CSS reset</h3>


<p>I do love a good CSS reset. It doesn’t matter how many of them I read, I always discover something awesome and add it to my own reset. From <a href="https://vale.rocks/posts/css-reset" rel="noopener">Vale’s CSS reset</a> I stole <code>svg:not([fill]) { fill: currentColor; }</code>, but there’s much more to take away from it than that!</p>


<h3 class="wp-block-heading" id="how-browsers-work">How browsers work</h3>


<p>If you’ve ever wondered how web browsers actually work — how they get IP addresses, make HTTP requests, parse HTML, build DOM trees, render layouts, and paint, the recently-shipped <a href="https://howbrowserswork.com/" rel="noopener">How Browsers Work</a> by Dmytro Krasun is an incredibly interesting, interactive read. It really makes you wonder about the bottlenecks of web development languages and why certain HTML, CSS, and JavaScript features are the way they are.</p>



<figure class="wp-block-image size-large"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="658" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-browsers-work-1024x658.png?resize=1024%2C658&#038;ssl=1" alt="A diagram showing the HTML parsing process with a code example on the left and the resulting DOM tree structure on the right." class="wp-image-391969" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-browsers-work-scaled.png?resize=1024%2C658&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-browsers-work-scaled.png?resize=300%2C193&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-browsers-work-scaled.png?resize=768%2C493&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-browsers-work-scaled.png?resize=1536%2C987&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-browsers-work-scaled.png?resize=2048%2C1316&amp;ssl=1 2048w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>


<h3 class="wp-block-heading" id="how-css-layout-works">How CSS layout works</h3>


<p>In addition, Polypane explains <a href="https://polypane.app/blog/understanding-the-fundamentals-of-css-layout/" rel="noopener">the fundamentals of CSS layout</a>, including the box model, lines and baselines, positioning schemes, the stacking context, grid layout, and flexbox. If you’re new to CSS, I think these explanations will really help you click with it. If you’re an old-timer (like me), I still think it’s important to learn how these foundational concepts apply to newer CSS features, especially since CSS is evolving exponentially these days.</p>



<figure class="wp-block-image size-large"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="658" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-css-layout-works-1024x658.png?resize=1024%2C658&#038;ssl=1" alt="A diagram showing CSS z-index stacking order with code examples on the left and visual representations of layered elements on the right." class="wp-image-391970" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-css-layout-works-scaled.png?resize=1024%2C658&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-css-layout-works-scaled.png?resize=300%2C193&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-css-layout-works-scaled.png?resize=768%2C493&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-css-layout-works-scaled.png?resize=1536%2C987&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/how-css-layout-works-scaled.png?resize=2048%2C1316&amp;ssl=1 2048w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>


<h3 class="wp-block-heading" id="css-masonry-is-probably-just-around-the-corner">CSS masonry is (probably) just around the corner</h3>


<p>Speaking of layouts, Jen Simmons clarifies <a href="https://webkit.org/blog/17758/when-will-css-grid-lanes-arrive-how-long-until-we-can-use-it/" rel="noopener">when we’ll be able to use <code>display: grid-lanes</code></a>, otherwise known as CSS masonry. While it’s not supported in any web browser yet, Firefox, Safari, and Chrome/Edge are <em>all</em> trialing it, so that could change pretty quickly. Jen provides some polyfills, anyway!</p>



<p>If you want to get ahead of the curve, you can <a href="https://css-tricks.com/masonry-layout-is-now-grid-lanes/">let Sunkanmi Fafowora walk you through <code>display: grid-lanes</code></a>.</p>



<figure class="wp-block-image size-large"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="574" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/css-display-grid-lanes-1024x574.jpg?resize=1024%2C574&#038;ssl=1" alt="A comparison showing two masonry-style card layouts labeled 'Grid Lanes' and 'CSS Grid 1' with different arrangements of image cards." class="wp-image-391971" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/css-display-grid-lanes.jpg?resize=1024%2C574&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/css-display-grid-lanes.jpg?resize=300%2C168&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/css-display-grid-lanes.jpg?resize=768%2C431&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/css-display-grid-lanes.jpg?resize=1536%2C862&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/css-display-grid-lanes.jpg?resize=2048%2C1149&amp;ssl=1 2048w" sizes="auto, (min-width: 735px) 864px, 96vw" /><figcaption class="wp-element-caption">Source: Webkit.</figcaption></figure>


<h3 class="wp-block-heading" id="theming-animations-using-relative-color-syntax">Theming animations using relative color syntax</h3>


<p>If you’re obsessed with design systems and organization, and you tend to think of illustration and animation as impressive but messy art forms, Andy Clarke’s article on <a href="https://www.smashingmagazine.com/2026/01/smashing-animations-part-8-css-relative-colour/" rel="noopener">theming animations using CSS relative color syntax</a> will truly help you to bridge the gap between art and logic. If CSS variables are your jam, then this article is definitely for you.</p>



<figure class="wp-block-image size-large"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="658" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/animations-and-relative-color-syntax-1024x658.png?resize=1024%2C658&#038;ssl=1" alt="A diagram showing CSS color calculations with code examples above and visual comparisons of lightness, chroma, and hue adjustments below." class="wp-image-391972" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/animations-and-relative-color-syntax-scaled.png?resize=1024%2C658&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/animations-and-relative-color-syntax-scaled.png?resize=300%2C193&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/animations-and-relative-color-syntax-scaled.png?resize=768%2C493&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/animations-and-relative-color-syntax-scaled.png?resize=1536%2C987&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/animations-and-relative-color-syntax-scaled.png?resize=2048%2C1316&amp;ssl=1 2048w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>


<h3 class="wp-block-heading" id="modals-vs-pages-and-everything-inbetween">Modals vs. pages (and everything in-between)</h3>


<p>Modals? Pages? Lightboxes? Dialogs? Tooltips? Understanding the different types of overlays and knowing when to use each one is still pretty confusing, especially since newer CSS features like popovers and interest invokers, while incredibly useful, are making the landscape more cloudy. In short, Ryan Neufeld clears up the whole <a href="https://uxplanet.org/modal-vs-page-a-decision-making-framework-34453e911129" rel="noopener">modal vs. page</a> thing and even provides a framework for deciding which type of overlay to use.</p>



<figure class="wp-block-image size-large"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="493" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/the-different-types-of-overlays-1024x493.jpg?resize=1024%2C493&#038;ssl=1" alt="" class="wp-image-391973" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/the-different-types-of-overlays.jpg?resize=1024%2C493&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/the-different-types-of-overlays.jpg?resize=300%2C145&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/the-different-types-of-overlays.jpg?resize=768%2C370&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/the-different-types-of-overlays.jpg?resize=1536%2C740&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/the-different-types-of-overlays.jpg?w=1793&amp;ssl=1 1793w" sizes="auto, (min-width: 735px) 864px, 96vw" /><figcaption class="wp-element-caption">Source: UX Planet</figcaption></figure>


<h3 class="wp-block-heading" id="text-scaling-support-is-being-trialed-in-chrome-canary">Text scaling support is being trialed in Chrome Canary</h3>


<p>You know when you’re dealing with text that’s been increased or decreased at the OS-level? <em>Well…</em>if you’re a web developer, maybe you don’t. After all, this feature doesn’t work on the web! However, Josh Tumath tells us that <a href="https://www.joshtumath.uk/posts/2026-01-27-try-text-scaling-support-in-chrome-canary/" rel="noopener">Chrome Canary is trialing a meta tag that makes web browsers respect this OS setting</a>. If you’re curious, it’s <code>&lt;meta name="text-scale" content="scale"&gt;</code>, but Josh goes into more detail and it’s worth a read.</p>



<p>See you next time!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/whats-important-4/">What’s !important #4: Videos &amp; View Transitions, Named Media Queries, How Browsers Work, and More</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Neither Chrome, Safari, nor Firefox have shipped new features in the last couple of weeks, but fear not because leading this issue of What’s !important is some of the web development industry’s best educators with, frankly, some killer content.



Maintaining video state across different pages using view transitions
Chris Coyier demonstrates how to maintain a video’s state across different pages using CSS view transitions. He notes that this is fairly easy to do with same-page view transitions, but with multi-page view transitions you’ll need to leverage JavaScript’s pageswap event to save information about the video’s state in sessionStorage as a JSON string (works with audio and iframes too), and then use that information to restore the state on pagereveal. Yes, there’s a tiiiiny bit of audio stutter because we’re technically faking it, but it’s still super neat.
Also, CodePen, which I’m sure you already know was founded by Chris, announced a private beta of CodePen 2.0, which you can request to be a part of. One of the benefits of CodePen 2.0 is that you can create actual projects with multiple files, which means that you can create view transitions in CodePen. Pretty cool!
How to ‘name’ media queries
Kevin Powell shows us how to leverage CSS cascade layers to ‘name’ media queries. This technique isn’t as effective as @custom-media (or even container style queries, as one commenter suggested), but until those are supported in all web browsers, Kevin’s trick is pretty creative.






Adam Argyle reminded us last week that @custom-media is being trialed in Firefox Nightly (no word on container style queries yet), but if you get up to speed on CSS cascade layers, you can utilize Kevin’s trick in the meantime.
Vale’s CSS reset
I do love a good CSS reset. It doesn’t matter how many of them I read, I always discover something awesome and add it to my own reset. From Vale’s CSS reset I stole svg:not([fill]) { fill: currentColor; }, but there’s much more to take away from it than that!
How browsers work
If you’ve ever wondered how web browsers actually work — how they get IP addresses, make HTTP requests, parse HTML, build DOM trees, render layouts, and paint, the recently-shipped How Browsers Work by Dmytro Krasun is an incredibly interesting, interactive read. It really makes you wonder about the bottlenecks of web development languages and why certain HTML, CSS, and JavaScript features are the way they are.



How CSS layout works
In addition, Polypane explains the fundamentals of CSS layout, including the box model, lines and baselines, positioning schemes, the stacking context, grid layout, and flexbox. If you’re new to CSS, I think these explanations will really help you click with it. If you’re an old-timer (like me), I still think it’s important to learn how these foundational concepts apply to newer CSS features, especially since CSS is evolving exponentially these days.



CSS masonry is (probably) just around the corner
Speaking of layouts, Jen Simmons clarifies when we’ll be able to use display: grid-lanes, otherwise known as CSS masonry. While it’s not supported in any web browser yet, Firefox, Safari, and Chrome/Edge are all trialing it, so that could change pretty quickly. Jen provides some polyfills, anyway!
If you want to get ahead of the curve, you can let Sunkanmi Fafowora walk you through display: grid-lanes.
Source: Webkit.


Theming animations using relative color syntax
If you’re obsessed with design systems and organization, and you tend to think of illustration and animation as impressive but messy art forms, Andy Clarke’s article on theming animations using CSS relative color syntax will truly help you to bridge the gap between art and logic. If CSS variables are your jam, then this article is definitely for you.



Modals vs. pages (and everything in-between)
Modals? Pages? Lightboxes? Dialogs? Tooltips? Understanding the different types of overlays and knowing when to use each one is still pretty confusing, especially since newer CSS features like popovers and interest invokers, while incredibly useful, are making the landscape more cloudy. In short, Ryan Neufeld clears up the whole modal vs. page thing and even provides a framework for deciding which type of overlay to use.
Source: UX Planet


Text scaling support is being trialed in Chrome Canary
You know when you’re dealing with text that’s been increased or decreased at the OS-level? Well…if you’re a web developer, maybe you don’t. After all, this feature doesn’t work on the web! However, Josh Tumath tells us that Chrome Canary is trialing a meta tag that makes web browsers respect this OS setting. If you’re curious, it’s <meta name="text-scale" content="scale">, but Josh goes into more detail and it’s worth a read.
See you next time!
What’s !important #4: Videos & View Transitions, Named Media Queries, How Browsers Work, and More originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Neither Chrome, Safari, nor Firefox have shipped new features in the last couple of weeks, but fear not because leading this issue of What’s !important is some of the web development industry’s best educators with, frankly, some killer content.
What’s !important #4: Videos & View Transitions, Named Media Queries, How Browsers Work, and More originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What’s !important #4: Videos & View Transitions, Named Media Queries, How Browsers Work, and More

<p>The new <code>::search-text</code> pseudo (Chrome 144) matches are yellow while the current target (<code>::search-text:current</code>) is orange, but <code>::search-text</code> enables us to change that.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/how-to-style-the-new-search-text-and-other-highlight-pseudo-elements/">Styling ::search-text and Other Highlight-y Pseudo-Elements</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p><a href="https://developer.chrome.com/blog/new-in-chrome-144" rel="noopener">Chrome 144</a> recently shipped <code>::search-text</code>, which is now one of several highlight-related pseudo-elements. This one selects find-in-page text, which is the text that gets highlighted when you do a <kbd>Ctrl</kbd>/<kbd>Command</kbd> + <kbd>F</kbd>-type search for something on a page and matches are found.</p>



<span id="more-391705"></span>



<p>By default, <code>::search-text</code> matches are yellow while the current target (<code>::search-text:current</code>) is orange, but <code>::search-text</code> enables us to change that.</p>



<p>I’ll admit, I hadn’t really been following these highlight pseudo-elements. Up until now, I didn’t even know that there was a name for them, but I’m glad there is because that makes it easier to round them all up and compare them, which is exactly what I’m going to do here today, as it’s not super obvious what they do based on the name of the pseudo-element. I’ll also explain why we’re able to customize them, and suggest how.</p>


<h3 class="wp-block-heading" id="the-different-types-of-highlight-pseudo-elements">The different types of highlight pseudo-elements</h3>


<figure class="wp-block-table ticss-b19c8ec9"><table class="has-fixed-layout"><thead><tr><th>Pseudo-selector</th><th>Selects…</th><th>Notes</th></tr></thead><tbody><tr><td><code>::search-text</code></td><td>Find-in-page matches</td><td><code>::search-text:current</code> selects the current target</td></tr><tr><td><a href="https://css-tricks.com/almanac/pseudo-selectors/t/target-text/"><code>::target-text</code></a></td><td>Text fragments</td><td>Text fragments allow for programmatic highlighting using URL parameters. If you’re referred to a website by a search engine, it might use text fragments, which is why <code>::target-text</code> is easily confused with <code>::search-text</code>.</td></tr><tr><td><a href="https://css-tricks.com/almanac/pseudo-selectors/s/selection/"><code>::selection</code></a></td><td>Text highlighted using the pointer</td><td></td></tr><tr><td><a href="https://css-tricks.com/css-custom-highlight-api-early-look/"><code>::highlight()</code></a></td><td>Custom highlights as defined by JavaScript’s <a href="https://css-tricks.com/css-custom-highlight-api-early-look/">Custom Highlight API</a></td><td></td></tr><tr><td><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::spelling-error" rel="noopener"><code>::spelling-error</code></a></td><td>Incorrectly spelled words</td><td>Pretty much applies to editable content only</td></tr><tr><td><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::grammar-error" rel="noopener"><code>::grammar-error</code></a></td><td>Incorrect grammar</td><td>Pretty much applies to editable content only</td></tr></tbody></table></figure>



<p>And let’s not forget about the <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/mark" rel="noopener"><code>&lt;mark&gt;</code></a> HTML element either, which is what I’m using in the demos below.</p>


<h3 class="wp-block-heading" id="what-should-highlight-pseudo-elements-look-like-">What should highlight pseudo-elements look like?</h3>


<p>The question is, if they all (besides <code>::highlight()</code>) have default styling, why would we need to select them with pseudo-elements? The reason is accessibility (color contrast, specifically) and usability (emphasis). For example, if the default yellow background of <code>::search-text</code> doesn’t contrast well enough with the text color, or if it doesn’t stand out against the background of the container, then you’ll want to change that.</p>



<p>I’m sure there are many ways to solve this (I want to hear <em>“challenge accepted”</em> in the comments), but the best solution that I’ve come up with uses <a href="https://css-tricks.com/css-color-functions/#aa-the-relative-color-syntax">relative color syntax</a>. I took wrong turns with both <code>background-clip: text</code> and <code>backdrop-filter: invert(1)</code> before realizing that many CSS properties are off-limits when it comes to highlight pseudo-elements:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">body {
  --background: #38003c;
  background: var(--background);

  mark,
  ::selection,
  ::target-text,
  ::search-text {
    /* Match color to background */
    color: var(--background);

    /* Convert to RGB then subtract channel value from channel maximum (255) */
    background: rgb(from var(--background) calc(255 - r) calc(255 - g) calc(255 - b));
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_ogLZeQN" src="//codepen.io/anon/embed/ogLZeQN?height=450&amp;theme-id=1&amp;slug-hash=ogLZeQN&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed ogLZeQN" title="CodePen Embed ogLZeQN" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>Your browser might not support that yet, so here’s a video that shows how the highlighted text adapts to background color changes.</p>



<figure class="wp-block-video"><video height="964" style="aspect-ratio: 1676 / 964;" width="1676" controls src="https://css-tricks.com/wp-content/uploads/2026/01/Screen-Recording-2026-01-21-at-10.28.07-AM.mov" playsinline></video></figure>



<p>What’s happening here is that I’m converting the container’s background color to RGB format and then subtracting the value of each channel (<code>r</code>, <code>g</code>, and <code>b</code>) from the maximum channel value of <code>255</code>, inverting each channel and the overall color. This color is then set as the background color of the highlighting, ensuring that it stands out no matter what, and thanks to the new <a href="https://css-tricks.com/playing-with-codepen-slidevars/">CodePen slideVars</a>, you can mess around with the demo to see this in action. You might be able to do this with color formats besides RGB, but RGB is the easiest.</p>



<p>So that covers the usability, but what about the accessibility?</p>



<p>Well, the highlighting’s text color is the same as the container’s background color because we know that it’s the inverse of the <em>highlighting’s</em> background color. While this doesn’t mean that the two colors will have accessible contrast, it seems as though they will most of the time (you should always check color contrast using <a href="https://css-tricks.com/color-contrast-accessibility-tools/">color contrast tools</a>, regardless).</p>



<p>If you don’t like the randomness of inverting colors, that’s understandable. You can totally pick colors and write conditional CSS for them manually instead, but finding accessible colors that stand out against the different backdrops of your design for all of the different types of highlight pseudo-elements, while accounting for alternative viewing modes such as dark mode, is a headache. Besides, I think certain UI elements (e.g., highlights, errors, focus indicators) <em>should</em> be ugly. They <em>should</em> stand out in a brutalist sort of way and feel disconnected from the design’s color palette. They should demand maximum attention by intentionally not fitting in.</p>



<p>Keep in mind that the different types of highlight pseudo-elements should be visually distinctive too, for obvious reasons, but also in case two different types overlap each other (e.g., the user selects text currently matched by find-in-page). Therefore, in the amended code snippet below, <code>mark</code>, <code>::selection</code>, <code>::target-text</code>, and <code>::search-text</code> all have slightly different backgrounds.</p>



<p>I’ve left <code>mark</code> unchanged, the <code>r</code> value of <code>::selection</code> as it was, the <code>g</code> value of <code>::target-text</code> as it was, and the <code>b</code> value of <code>::search-text</code> as it was, so those last three only have two channels inverted instead of all three. They’re varied in color now (but still look inverted), and with the addition of an alpha value at <code>70%</code> (<code>100%</code> for <code>::search-text:current</code>), they also blend into each other so that we can see where each highlight begins and ends:</p>



<figure class="wp-block-video"><video height="502" style="aspect-ratio: 800 / 502;" width="800" controls src="https://css-tricks.com/wp-content/uploads/2026/01/highlights.mov" playsinline></video></figure>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">body {
  --background: #38003c;
  background: var(--background);

  mark,
  ::selection,
  ::target-text,
  ::search-text {
    color: var(--background);
  }

  mark {
    /* Invert all channels */
    background: rgb(from var(--background) calc(255 - r) calc(255 - g) calc(255 - b) / 70%);
  }

  ::selection {
    /* Invert all channels but R */
    background: rgb(from var(--background) r calc(255 - g) calc(255 - b) / 70%);
  }

  ::target-text {
    /* Invert all channels but G */
    background: rgb(from var(--background) calc(255 - r) g calc(255 - b) / 70%);
  }

  ::search-text {
    /* Invert all channels but B */
    background: rgb(from var(--background) calc(255 - r) calc(255 - g) b / 70%);
    
    &amp;:current {
      /* Invert all channels but B, but without transparency */
      background: rgb(from var(--background) calc(255 - r) calc(255 - g) b / 100%);
    }
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_GgqWzax" src="//codepen.io/anon/embed/GgqWzax?height=450&amp;theme-id=1&amp;slug-hash=GgqWzax&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed GgqWzax" title="CodePen Embed GgqWzax" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p><code>::spelling-error</code> and <code>::grammar-error</code> are excluded from all this because they have their own visual affordances (red underlines and green underlines respectively, typically contrasted against the neutral background of an editable element such as <code>&lt;textarea&gt;</code>).</p>



<p>But <code>mark</code>, <code>::selection</code>, <code>::target-text</code>, and new-to-Chrome <code>::search-text</code>? Well, they can appear anywhere (even on top of each other), so I think it’s important that they’re visually distinctive from each other while being accessible at all times. Again though, even fully-inverted colors can be inaccessible. In fact, the inverse of <code>#808080</code> is <code>#808080</code>, so test, test, test! Although, maybe <a href="https://css-tricks.com/exploring-the-css-contrast-color-function-a-second-time/"><code>contrast-color()</code></a> could come to the rescue once the <a href="https://www.w3.org/TR/css-color-5/#funcdef-contrast-color" rel="noopener">CSS Color Module Level 5</a> version of it ships.</p>



<p>In the meantime, <em>please</em>, no more highlight-y elements!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/how-to-style-the-new-search-text-and-other-highlight-pseudo-elements/">Styling ::search-text and Other Highlight-y Pseudo-Elements</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Chrome 144 recently shipped ::search-text, which is now one of several highlight-related pseudo-elements. This one selects find-in-page text, which is the text that gets highlighted when you do a Ctrl/Command + F-type search for something on a page and matches are found.




By default, ::search-text matches are yellow while the current target (::search-text:current) is orange, but ::search-text enables us to change that.
I’ll admit, I hadn’t really been following these highlight pseudo-elements. Up until now, I didn’t even know that there was a name for them, but I’m glad there is because that makes it easier to round them all up and compare them, which is exactly what I’m going to do here today, as it’s not super obvious what they do based on the name of the pseudo-element. I’ll also explain why we’re able to customize them, and suggest how.
The different types of highlight pseudo-elements

Pseudo-selectorSelects…Notes

::search-textFind-in-page matches::search-text:current selects the current target
::target-textText fragmentsText fragments allow for programmatic highlighting using URL parameters. If you’re referred to a website by a search engine, it might use text fragments, which is why ::target-text is easily confused with ::search-text.
::selectionText highlighted using the pointer
::highlight()Custom highlights as defined by JavaScript’s Custom Highlight API
::spelling-errorIncorrectly spelled wordsPretty much applies to editable content only
::grammar-errorIncorrect grammarPretty much applies to editable content only





And let’s not forget about the <mark> HTML element either, which is what I’m using in the demos below.
What should highlight pseudo-elements look like?
The question is, if they all (besides ::highlight()) have default styling, why would we need to select them with pseudo-elements? The reason is accessibility (color contrast, specifically) and usability (emphasis). For example, if the default yellow background of ::search-text doesn’t contrast well enough with the text color, or if it doesn’t stand out against the background of the container, then you’ll want to change that.
I’m sure there are many ways to solve this (I want to hear “challenge accepted” in the comments), but the best solution that I’ve come up with uses relative color syntax. I took wrong turns with both background-clip: text and backdrop-filter: invert(1) before realizing that many CSS properties are off-limits when it comes to highlight pseudo-elements:
body {
  --background: #38003c;
  background: var(--background);

  mark,
  ::selection,
  ::target-text,
  ::search-text {
    /* Match color to background */
    color: var(--background);

    /* Convert to RGB then subtract channel value from channel maximum (255) */
    background: rgb(from var(--background) calc(255 - r) calc(255 - g) calc(255 - b));
  }
}
CodePen Embed Fallback
Your browser might not support that yet, so here’s a video that shows how the highlighted text adapts to background color changes.




What’s happening here is that I’m converting the container’s background color to RGB format and then subtracting the value of each channel (r, g, and b) from the maximum channel value of 255, inverting each channel and the overall color. This color is then set as the background color of the highlighting, ensuring that it stands out no matter what, and thanks to the new CodePen slideVars, you can mess around with the demo to see this in action. You might be able to do this with color formats besides RGB, but RGB is the easiest.
So that covers the usability, but what about the accessibility?
Well, the highlighting’s text color is the same as the container’s background color because we know that it’s the inverse of the highlighting’s background color. While this doesn’t mean that the two colors will have accessible contrast, it seems as though they will most of the time (you should always check color contrast using color contrast tools, regardless).
If you don’t like the randomness of inverting colors, that’s understandable. You can totally pick colors and write conditional CSS for them manually instead, but finding accessible colors that stand out against the different backdrops of your design for all of the different types of highlight pseudo-elements, while accounting for alternative viewing modes such as dark mode, is a headache. Besides, I think certain UI elements (e.g., highlights, errors, focus indicators) should be ugly. They should stand out in a brutalist sort of way and feel disconnected from the design’s color palette. They should demand maximum attention by intentionally not fitting in.
Keep in mind that the different types of highlight pseudo-elements should be visually distinctive too, for obvious reasons, but also in case two different types overlap each other (e.g., the user selects text currently matched by find-in-page). Therefore, in the amended code snippet below, mark, ::selection, ::target-text, and ::search-text all have slightly different backgrounds.
I’ve left mark unchanged, the r value of ::selection as it was, the g value of ::target-text as it was, and the b value of ::search-text as it was, so those last three only have two channels inverted instead of all three. They’re varied in color now (but still look inverted), and with the addition of an alpha value at 70% (100% for ::search-text:current), they also blend into each other so that we can see where each highlight begins and ends:




body {
  --background: #38003c;
  background: var(--background);

  mark,
  ::selection,
  ::target-text,
  ::search-text {
    color: var(--background);
  }

  mark {
    /* Invert all channels */
    background: rgb(from var(--background) calc(255 - r) calc(255 - g) calc(255 - b) / 70%);
  }

  ::selection {
    /* Invert all channels but R */
    background: rgb(from var(--background) r calc(255 - g) calc(255 - b) / 70%);
  }

  ::target-text {
    /* Invert all channels but G */
    background: rgb(from var(--background) calc(255 - r) g calc(255 - b) / 70%);
  }

  ::search-text {
    /* Invert all channels but B */
    background: rgb(from var(--background) calc(255 - r) calc(255 - g) b / 70%);
    
    &:current {
      /* Invert all channels but B, but without transparency */
      background: rgb(from var(--background) calc(255 - r) calc(255 - g) b / 100%);
    }
  }
}
CodePen Embed Fallback
::spelling-error and ::grammar-error are excluded from all this because they have their own visual affordances (red underlines and green underlines respectively, typically contrasted against the neutral background of an editable element such as <textarea>).
But mark, ::selection, ::target-text, and new-to-Chrome ::search-text? Well, they can appear anywhere (even on top of each other), so I think it’s important that they’re visually distinctive from each other while being accessible at all times. Again though, even fully-inverted colors can be inaccessible. In fact, the inverse of #808080 is #808080, so test, test, test! Although, maybe contrast-color() could come to the rescue once the CSS Color Module Level 5 version of it ships.
In the meantime, please, no more highlight-y elements!
Styling ::search-text and Other Highlight-y Pseudo-Elements originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The new ::search-text pseudo (Chrome 144) matches are yellow while the current target (::search-text:current) is orange, but ::search-text enables us to change that.
Styling ::search-text and Other Highlight-y Pseudo-Elements originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Styling ::search-text and Other Highlight-y Pseudo-Elements

<p>Stu Robson's ReliCSS (clever name!) tool can excavate outdated CSS in your codebase that have modern CSS solutions.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/relicss/">ReliCSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>We all have a few skeletons in our CSS closets. There&#8217;s probably that one-off <code>!important</code> where you can now manage that more effectively with cascade layers. Or maybe a dated Checkbox Hack that <code>:has()</code> has solved. Perhaps it&#8217;s been a long while since your last site redesign and it&#8217;s chock-full of vendor-prefixed properties from 2012. <em>Thar be demons!</em></p>



<p>Stu Robson&#8217;s <a href="https://www.alwaystwisted.com/relicss/" rel="noopener">ReliCSS</a> (clever name!) tool can excavate outdated CSS in your codebase that have modern CSS solutions.</p>



<span id="more-391920"></span>



<p>Each relic is assigned a level of severity. As Stu explains it:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<ul class="wp-block-list">
<li><strong>High Severity:</strong>&nbsp;True “fossils”. Hacks for (now) unsupported browsers (IE6/7) or “dangerous” techniques. High-risk, obsolete, should be first targets for removal.</li>



<li><strong>Medium Severity:</strong>&nbsp;The middle ground. Hacks for older unsupported browsers (IE8-10). They work but they&#8217;re fragile. Hacks to review to see if they&#8217;re still relevant for your actual users.</li>



<li><strong>Low Severity:</strong>&nbsp;Modern artifacts. Usually vendor prefixes (-webkit-, -moz-). Safe mostly, but better handled by automated tools like Autoprefixer. They&#8217;re an opportunity to improve your build process.</li>
</ul>
</blockquote>



<p>It&#8217;s been a little while since my personal site got an overhaul. Not to toot my own horn, but heyyyyyy!</p>



<figure class="wp-block-image size-full"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1724" height="868" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-9.54.42-AM.png?resize=1724%2C868" alt="Screenshot of a CSS audit using Stu Robson's ReliCSS tool. No issues are found." class="wp-image-391922" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-9.54.42-AM.png?w=1724&amp;ssl=1 1724w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-9.54.42-AM.png?resize=300%2C151&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-9.54.42-AM.png?resize=1024%2C516&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-9.54.42-AM.png?resize=768%2C387&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-9.54.42-AM.png?resize=1536%2C773&amp;ssl=1 1536w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>



<p>Seriously, though. I know there are things in there I&#8217;m embarrassed to admit.</p>



<p>But what if we do archeological dig on CSS-Tricks? I mean, it&#8217;s been <a href="https://css-tricks.com/design-v18/">at <em>least</em> five years</a> since this place has gotten the love it deserves. I&#8217;m almost afraid to look. Here goes&#8230;</p>



<figure class="wp-block-image size-large"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="663" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-10.11.46-AM-1024x663.png?resize=1024%2C663&#038;ssl=1" alt="Screenshot auditing CSS-Tricks CSS stylesheet in Stu Robson's ReliCSS tool. Out shows 19 total relics." class="wp-image-391923" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-10.11.46-AM.png?resize=1024%2C663&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-10.11.46-AM.png?resize=300%2C194&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-10.11.46-AM.png?resize=768%2C498&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-10.11.46-AM.png?resize=1536%2C995&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/Screenshot-2026-01-28-at-10.11.46-AM.png?resize=2048%2C1327&amp;ssl=1 2048w" sizes="auto, (min-width: 735px) 864px, 96vw" /><figcaption class="wp-element-caption">&#x1fae3;</figcaption></figure>



<p>OK, not as bad as I imagined. It&#8217;s largely vendor prefixing, which I&#8217;m sure comes courtesy of an older Autoprefixer configuration.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/relicss/">ReliCSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


We all have a few skeletons in our CSS closets. There’s probably that one-off !important where you can now manage that more effectively with cascade layers. Or maybe a dated Checkbox Hack that :has() has solved. Perhaps it’s been a long while since your last site redesign and it’s chock-full of vendor-prefixed properties from 2012. Thar be demons!
Stu Robson’s ReliCSS (clever name!) tool can excavate outdated CSS in your codebase that have modern CSS solutions.




Each relic is assigned a level of severity. As Stu explains it:
High Severity: True “fossils”. Hacks for (now) unsupported browsers (IE6/7) or “dangerous” techniques. High-risk, obsolete, should be first targets for removal.
Medium Severity: The middle ground. Hacks for older unsupported browsers (IE8-10). They work but they’re fragile. Hacks to review to see if they’re still relevant for your actual users.
Low Severity: Modern artifacts. Usually vendor prefixes (-webkit-, -moz-). Safe mostly, but better handled by automated tools like Autoprefixer. They’re an opportunity to improve your build process.
It’s been a little while since my personal site got an overhaul. Not to toot my own horn, but heyyyyyy!




Seriously, though. I know there are things in there I’m embarrassed to admit.
But what if we do archeological dig on CSS-Tricks? I mean, it’s been at least five years since this place has gotten the love it deserves. I’m almost afraid to look. Here goes…
🫣



OK, not as bad as I imagined. It’s largely vendor prefixing, which I’m sure comes courtesy of an older Autoprefixer configuration.
ReliCSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Stu Robson's ReliCSS (clever name!) tool can excavate outdated CSS in your codebase that have modern CSS solutions.
ReliCSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

ReliCSS

<p>Accessibility advice around modals have commonly taught us to trap focus within the modal. Upon further research, it seems like we no longer need to trap focus within the <code>&#60;dialog&#62;</code> (even in modal mode).</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/there-is-no-need-to-trap-focus-on-a-dialog-element/">There is No Need to Trap Focus on a Dialog Element</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>I was building a <code>Modal</code> component that uses the <code>&lt;dialog&gt;</code> element&#8217;s <code>showModal</code> method. While testing the component, I discovered I could tab out of the <code>&lt;dialog&gt;</code> (in modal mode) and onto the address bar.</p>



<p>And I was surprised — accessibility advice around modals have commonly taught us to trap focus within the modal. So this seems wrong to me.</p>



<p>Upon further <a href="https://github.com/whatwg/html/issues/8339" rel="noopener">research</a>, it seems like we no longer need to trap focus within the <code>&lt;dialog&gt;</code> (even in modal mode). So, the focus-trapping is deprecated advice if you use <code>&lt;dialog&gt;</code>.</p>



<span id="more-388430"></span>


<h3 class="wp-block-heading" id="some-notes-for-you">Some notes for you</h3>


<p>Instead of asking you to read through the entire <a href="https://github.com/whatwg/html/issues/8339" rel="noopener">GitHub Issue</a> detailing the discussion, I summarized a couple of key points from notable people below.</p>



<p>Here are some <a href="https://github.com/whatwg/html/issues/8339#issuecomment-1263470105" rel="noopener">comments</a> from Scott O&#8217;Hara that tells us about the history and context of the focus-trapping advice:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>WCAG is <em>not</em> normatively stating focus must be trapped within a dialog. Rather, the normative WCAG spec makes zero mention of requirements for focus behavior in a dialog.</p>



<p>The informative <a href="https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html" rel="noopener">2.4.3 focus order understanding doc</a> <em>does</em> talk about limiting focus behavior within a dialog &#8211; but again, this is in the context of a scripted custom dialog and was written long before <code>inert</code> or <code>&lt;dialog&gt;</code> were widely available.</p>



<p>The purpose of the APG is to demonstrate how to use ARIA. And, without using native HTML features like <code>&lt;dialog&gt;</code> or <code>inert</code>, it is far easier to trap focus within the custom dialog than it is to achieve the behavior that the <code>&lt;dialog&gt;</code> element has.</p>



<p>Both the APG modal dialog and the WCAG understanding doc were written long before the <code>inert</code> attribute or the <code>&lt;dialog&gt;</code> element were widely supported. And, the alternative to instructing developers to trap focus in the dialog would have been to tell them that they needed to ensure that all focusable elements in the web page, outside of the modal dialog, received a <code>tabindex=-1</code>.</p>
</blockquote>



<p>Léonie Watson <a href="https://github.com/whatwg/html/issues/8339#issuecomment-1758129923" rel="noopener">weighs in</a> and explains why it&#8217;s okay for a screen-reader user to move focus to the address bar:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>In the page context you can choose to <kbd>Tab</kbd> out of the bottom and around the browser chrome, you can use a keyboard command to move straight to the address bar or open a particular menu, you can close the tab, and so on. This gives people a choice about how, why, and what they do to escape out of the context.</p>



<p>It seems logical (to me at least) for the same options to be available to people when in a dialog context instead of a page context.</p>
</blockquote>



<p>Finally, <a href="https://github.com/whatwg/html/issues/8339#issuecomment-1822591131" rel="noopener">Matatk</a> shared the conclusion from the W3C&#8217;s Accessible Platform Architectures (APA) Working Group that okay-ed the notion that <code>&lt;dialog&gt;</code>&#8216;s <code>showModal</code> method doesn&#8217;t need to trap focus.</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>We addressed this question in the course of several APA meetings and came to the conclusion that the current behavior of the native dialog element should be kept as it is. So, that you can tab from the dialog to the browser functionalities.</p>



<p>We see especially the benefit that keyboard users can, for example, open a new tab to look something important up or to change a browser setting this way. At the same time, the dialog element thus provides an additional natural escape mechanism (i.e. moving to the address bar) in, for example, kiosk situations where the user cannot use other standard keyboard shortcuts.</p>
</blockquote>



<p>From what I&#8217;m reading, it sounds like we don&#8217;t have to worry about focus trapping if we&#8217;re properly using the Dialog API&#8217;s <code>showModal</code> method!</p>



<p>Hope this news make it easier for you to build components. &#x1f609;</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/there-is-no-need-to-trap-focus-on-a-dialog-element/">There is No Need to Trap Focus on a Dialog Element</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


I was building a Modal component that uses the <dialog> element’s showModal method. While testing the component, I discovered I could tab out of the <dialog> (in modal mode) and onto the address bar.
And I was surprised — accessibility advice around modals have commonly taught us to trap focus within the modal. So this seems wrong to me.
Upon further research, it seems like we no longer need to trap focus within the <dialog> (even in modal mode). So, the focus-trapping is deprecated advice if you use <dialog>.



Some notes for you
Instead of asking you to read through the entire GitHub Issue detailing the discussion, I summarized a couple of key points from notable people below.
Here are some comments from Scott O’Hara that tells us about the history and context of the focus-trapping advice:
WCAG is not normatively stating focus must be trapped within a dialog. Rather, the normative WCAG spec makes zero mention of requirements for focus behavior in a dialog.
The informative 2.4.3 focus order understanding doc does talk about limiting focus behavior within a dialog – but again, this is in the context of a scripted custom dialog and was written long before inert or <dialog> were widely available.
The purpose of the APG is to demonstrate how to use ARIA. And, without using native HTML features like <dialog> or inert, it is far easier to trap focus within the custom dialog than it is to achieve the behavior that the <dialog> element has.
Both the APG modal dialog and the WCAG understanding doc were written long before the inert attribute or the <dialog> element were widely supported. And, the alternative to instructing developers to trap focus in the dialog would have been to tell them that they needed to ensure that all focusable elements in the web page, outside of the modal dialog, received a tabindex=-1.
Léonie Watson weighs in and explains why it’s okay for a screen-reader user to move focus to the address bar:
In the page context you can choose to Tab out of the bottom and around the browser chrome, you can use a keyboard command to move straight to the address bar or open a particular menu, you can close the tab, and so on. This gives people a choice about how, why, and what they do to escape out of the context.
It seems logical (to me at least) for the same options to be available to people when in a dialog context instead of a page context.
Finally, Matatk shared the conclusion from the W3C’s Accessible Platform Architectures (APA) Working Group that okay-ed the notion that <dialog>‘s showModal method doesn’t need to trap focus.
We addressed this question in the course of several APA meetings and came to the conclusion that the current behavior of the native dialog element should be kept as it is. So, that you can tab from the dialog to the browser functionalities.
We see especially the benefit that keyboard users can, for example, open a new tab to look something important up or to change a browser setting this way. At the same time, the dialog element thus provides an additional natural escape mechanism (i.e. moving to the address bar) in, for example, kiosk situations where the user cannot use other standard keyboard shortcuts.
From what I’m reading, it sounds like we don’t have to worry about focus trapping if we’re properly using the Dialog API’s showModal method!
Hope this news make it easier for you to build components. 😉
There is No Need to Trap Focus on a Dialog Element originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Accessibility advice around modals have commonly taught us to trap focus within the modal. Upon further research, it seems like we no longer need to trap focus within the <dialog> (even in modal mode).
There is No Need to Trap Focus on a Dialog Element originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

There is No Need to Trap Focus on a Dialog Element

<p>A while back, Temani tacked a repeating grid of hexagon shapes. Well, he's updated it with modern CSS features that result in fewer magic numbers. And it's impressive!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/responsive-hexagon-grid-using-modern-css/">Responsive Hexagon Grid Using Modern CSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Five years ago I published an article on how to create a responsive grid of hexagon shapes. It was the only technique that didn’t require media queries or JavaScript. It works with any number of items, allowing you to easily control the size and gap using CSS variables.




CodePen Embed Fallback
I am using float, inline-block, setting font-size equal to 0, etc. In 2026, this may sound a bit hacky and outdated. Not really since this method works fine and is well supported, but can we do better using modern features? In five years, many things have changed and we can improve the above implementation and make it less hacky!
Support is limited to Chrome only because this technique uses recently released features, including corner-shape, sibling-index(), and unit division.
CodePen Embed Fallback
The CSS code is shorter and contains fewer magic numbers than the last time I approached this. You will also find some complex calculations that we will dissect together.
Before diving into this new demo, I highly recommend reading my previous article first. It’s not mandatory, but it allows you to compare both methods and realize how much (and rapidly) CSS has evolved in the last five years by introducing new features that make one-difficult things like this easier.
The Hexagon Shape
Let’s start with the hexagon shape, which is the main element of our grid. Previously, I had to rely on clip-path: polygon() to create it:
.hexagon {
  --s: 100px;
  width: var(--s);
  height: calc(var(--s) * 1.1547);
  clip-path: polygon(0% 25%, 0% 75%, 50% 100%, 100% 75%, 100% 25%, 50% 0%);
}
But now, we can rely on the new corner-shape property which works alongside the border-radius property:
.hexagon {
  width: 100px;
  aspect-ratio: cos(30deg);
  border-radius: 50% / 25%;
  corner-shape: bevel;
}
Simpler than how we used to bevel elements, and as a bonus, we can add a border to the shape without workarounds!
CodePen Embed Fallback
The corner-shape property is the first modern feature we are relying on. It makes drawing CSS shapes a lot easier than traditional methods, like using clip-path. You can still keep using the clip-path method, of course, for better support (and if you don’t need a border on the element), but here is a more modern implementation:
.hexagon {
  width: 100px;
  aspect-ratio: cos(30deg);
  clip-path: polygon(-50% 50%,50% 100%,150% 50%,50% 0);
}
CodePen Embed Fallback
There are fewer points inside the polygon, and we replaced the magic number 1.1547 with an aspect-ratio declaration. I won’t spend more time on the code of the shapes, but here are two articles I wrote if you want a detailed explanation with more examples:
The Modern Guide For Making CSS Shapes
Drawing CSS Shapes using corner-shape
The Responsive Grid
Now that we have our shape, let’s create the grid. It’s called a “grid,” but I am going to use a flexbox configuration:
<div class="container">
  <div></div>
  <div></div>
  <div></div>
  <div></div>
  
</div>
.container {
  --s: 120px; /* size  */
  --g: 10px; /* gap */
  
  display: flex;
  gap: var(--g);
  flex-wrap: wrap;
}
.container > * {
  width: var(--s);
  aspect-ratio: cos(30deg);
  border-radius: 50% / 25%;
  corner-shape: bevel;
}
CodePen Embed Fallback
Nothing fancy so far. From there, we add a bottom margin to all items to create an overlap between the rows:
.container > * {
  margin-bottom: calc(var(--s)/(-4*cos(30deg)));
}
CodePen Embed Fallback
The last step is to add a left margin to the first item of the even rows (i.e., 2nd, 4th, 6th, and so). This margin will create the shift between rows to achieve a perfect grid.
Said like that, it sounds easy, but it’s the trickiest part where we need complex calculations. The grid is responsive, so the “first” item we are looking for can be any item depending, on the container size, item size, gap, etc.
Let’s start with a figure:




Our grid can have two aspects depending on the responsiveness. We can either have the same number of items in all the rows (Grid 1 in the figure above) or a difference of one item between two consecutive rows (Grid 2). The N and M variables represent the number of items in the rows. In Grid 1 we have N = M, and in Grid 2 we have M = N - 1.
In Grid 1, the items with a left margin are 6, 16, 26, etc., and in Grid 2, they are 7, 18, 29, etc. Let’s try to identify the logic behind those numbers.
The first item in both grids (6 or 7) is the first one in the second row, so it’s the item N + 1. The second item (16 or 18) is the first one in the third row, so it’s the item N + M + N + 1. The third item (26 or 29) is the item N + M + N + M + N + 1. If you look closely, you can see a pattern that we can express using the following formula:
N*i + M*(i - 1) + 1
…where i is a positive integer (zero excluded). The items we are looking for can be found using the following pseudo-code:
for(i = 0; i< ?? ;i++) {
  index = N*i + M*(i - 1) + 1
  Add margin to items[index]  
}
We don’t have loops in CSS, though, so we will have to do something different. We can obtain the index of each item using the new sibling-index() function. The logic is to test if that index respect the previous formula.
Instead of writing this:
index = N*i + M*(i - 1) + 1
…let’s express i using the index:
i = (index - 1 + M)/(N + M)
We know that i is a positive integer (zero excluded), so for each item, we get its index and test if (index - 1 + M)/(N + M) is a positive integer. Before that, let’s calculate the number of items, N and M.
Calculating the number of items per row is the same as calculating how many items can fit in that row.
N = round(down,container_size / item_size);
Dividing the container size by the item size gives us a number. If we round()` it down to the nearest integer, we get the number of items per row. But we have a gap between items, so we need to account for this in the formula:
N = round(down, (container_size + gap)/ (item_size + gap));
We do the same for M, but this time we need to also account for the left margin applied to the first item of the row:
M = round(down, (container_size + gap - margin_left)/ (item_size + gap));
Let’s take a closer look and identify the value of that margin in the next figure:




It’s equal to half the size of an item, plus half the gap:
M = round(down, (container_size + gap - (item_size + gap)/2)/(item_size + gap));

M = round(down, (container_size - (item_size - gap)/2)/(item_size + gap));
The item size and the gap are defined using the --s and --g variables, but what about the container size? We can rely on container query units and use 100cqw.
Let’s write what we have until now using CSS:
.container {
  --s: 120px;  /* size  */
  --g: 10px;   /* gap */
  
  container-type: inline-size; /* we make it a container to use 100cqw */
}
.container > * {
  --_n: round(down,(100cqw + var(--g))/(var(--s) + var(--g)));
  --_m: round(down,(100cqw - (var(--s) - var(--g))/2)/(var(--s) + var(--g))); 
  --_i: calc((sibling-index() - 1 + var(--_m))/(var(--_n) + var(--_m)));
  
  margin-left: ???; /* We're getting there! */
}
We can use mod(var(--_i),1) to test if --_i is an integer. If it’s an integer, the result is equal to 0. Otherwise, it’s equal to a value between 0 and 1.
We can introduce another variable and use the new if() function!
.container {
  --s: 120px;  /* size  */
  --g: 10px;   /* gap */
  
  container-type: inline-size; /* we make it a container to use 100cqw */
}
.container > * {
  --_n: round(down,(100cqw + var(--g))/(var(--s) + var(--g)));
  --_m: round(down,(100cqw - (var(--s) - var(--g))/2)/(var(--s) + var(--g))); 
  --_i: calc((sibling-index() - 1 + var(--_m))/(var(--_n) + var(--_m)));
  --_c: mod(var(--_i),1);
  margin-left: if(style(--_c: 0) calc((var(--s) + var(--g))/2) else 0;);
}
Tada!
CodePen Embed Fallback
It’s important to note that you need to register the variable --_c variable using @property to be able to do the comparison (I write more about this in “How to correctly use if()in CSS”).
This is a good use case for if(), but we can do it differently:
--_c: round(down, 1 - mod(var(--_i), 1));
The mod() function gives us a value between 0 and 1, where 0 is the value we want. -1*mod() gives us a value between -1 and 0. 1 - mod() gives us a value between 0 and 1, but this time it’s the 1 we need. We apply round() to the calculation, and the result will be either 0 or 1. The --_c variable is now a Boolean variable that we can use directly within a calculation.
margin-left: calc(var(--_c) * (var(--s) + var(--g))/2);
If --_c is equal to 1, we get a margin. Otherwise, the margin is equal to 0. This time you don’t need to register the variable using @property. I personally prefer this method as it requires less code, but the if() method is also interesting.
CodePen Embed Fallback
Should I remember all those formulas by heart?! It’s too much!
No, you don’t. I tried to provide a detailed explanation behind the math, but it’s not mandatory to understand it to work with the grid. All you have to do is update the variables that control the size and gap. No need to touch the part that set the left margin. We will even explore how the same code structure can work with more shapes!
More Examples
The common use case is a hexagon shape but what about other shapes? We can, for example, consider a rhombus and, for this, we simply adjust the code that controls the shape.
From this:
.container > * {
  aspect-ratio: cos(30deg);
  border-radius: 50% / 25%;
  corner-shape: bevel;
  margin-bottom: calc(var(--s)/(-4*cos(30deg)));
}
…to this:
.container > * {
  aspect-ratio: 1;
  border-radius: 50%;
  corner-shape: bevel;
  margin-bottom: calc(var(--s)/-2);
}
CodePen Embed Fallback
A responsive grid of rhombus shapes — with no effort! Let’s try an octagon:
.container > * {
  aspect-ratio: 1;
  border-radius: calc(100%/(2 + sqrt(2)));
  corner-shape: bevel;
  margin-bottom: calc(var(--s)/(-1*(2 + sqrt(2))));
}
CodePen Embed Fallback
Almost! For an octagon, we need to adjust the gap because we need more horizontal space between the items:
.container {
  --g: calc(10px + var(--s)/(sqrt(2) + 1));
  gap: 10px var(--g);
}
The variable --g includes a portion of the size var(--s)/(sqrt(2) + 1) and is applied as a row gap, while the column gap is kept the same (10px).
CodePen Embed Fallback
From there, we can also get another type of hexagon grid:
CodePen Embed Fallback
And why not a grid of circles as well? Here we go:
CodePen Embed Fallback
As you can see, we didn’t touch the complex calculation that sets the left margin in any of those examples. All we had to do was to play with the border-radius and aspect-ratio properties to control the shape and adjust the bottom margin to rectify the overlap. In some cases, we need to adjust the horizontal gap.
Conclusion
I will end this article with another demo that will serve as a small homework for you:
CodePen Embed Fallback
This time, the shift is applied to the odd rows rather than the even ones. I let you dissect the code as a small exercise. Try to identify the change I have made and what’s the logic behind it (Hint: try to redo the calculation steps using this new configuration.)
Responsive Hexagon Grid Using Modern CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A while back, Temani tacked a repeating grid of hexagon shapes. Well, he's updated it with modern CSS features that result in fewer magic numbers. And it's impressive!
Responsive Hexagon Grid Using Modern CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Responsive Hexagon Grid Using Modern CSS

<p>The <code>@custom-media</code> at-rule has landed in Firefox Nightly! I couldn&#8217;t find it in the <a href="https://www.firefox.com/en-US/firefox/149.0a1/releasenotes/" rel="noopener">release notes</a> but <a href="https://nerdy.dev/custom-media" rel="noopener">Adam Argyle&#8217;s on the beat</a> noting that it&#8217;s behind a flag for now.</p>
<p>Look for <code>layout.css.custom-media.enabled</code></p>
<p>I often forget the exact name of &#8230;</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/open-props-custom-media-recipes/">Open Props @custom-media Recipes</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>The <code>@custom-media</code> at-rule has landed in Firefox Nightly! I couldn&#8217;t find it in the <a href="https://www.firefox.com/en-US/firefox/149.0a1/releasenotes/" rel="noopener">release notes</a> but <a href="https://nerdy.dev/custom-media" rel="noopener">Adam Argyle&#8217;s on the beat</a> noting that it&#8217;s behind a flag for now.</p>



<span id="more-391757"></span>



<figure class="wp-block-image size-full"><img data-recalc-dims="1" loading="lazy" decoding="async" width="1808" height="1334" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/custom-media-queries-firefox-nightly-flag.png?resize=1808%2C1334" alt="The Firefox Nightly configuration screen searching for custom-media and with layout.css.custom-media.enabled." class="wp-image-391759" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/custom-media-queries-firefox-nightly-flag.png?w=1808&amp;ssl=1 1808w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/custom-media-queries-firefox-nightly-flag.png?resize=300%2C221&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/custom-media-queries-firefox-nightly-flag.png?resize=1024%2C756&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/custom-media-queries-firefox-nightly-flag.png?resize=768%2C567&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/custom-media-queries-firefox-nightly-flag.png?resize=1536%2C1133&amp;ssl=1 1536w" sizes="auto, (min-width: 735px) 864px, 96vw" /><figcaption class="wp-element-caption">Look for <code>layout.css.custom-media.enabled</code></figcaption></figure>



<p>I often forget the exact name of an <code>@media</code> query or simply get tired writing something like <code>@media screen and (prefers-reduced-motion: no-preference)</code> over and over again. <code>@custom-media</code> will be a nice bit of relief to the ol&#8217; muscle memory because it allows us to create aliases for queries.</p>



<p>In fact, Adam&#8217;s Open Props project has <a href="https://github.com/argyleink/open-props/blob/main/src/props.media.css" rel="noopener">more than 45 of them</a> that make for excellent recipes:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">@custom-media --motionOK (prefers-reduced-motion: no-preference);

@media (--motionOK) {
  /* animations and transitions */
}</code></pre>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/open-props-custom-media-recipes/">Open Props @custom-media Recipes</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


The @custom-media at-rule has landed in Firefox Nightly! I couldn’t find it in the release notes but Adam Argyle’s on the beat noting that it’s behind a flag for now.




Look for layout.css.custom-media.enabled



I often forget the exact name of an @media query or simply get tired writing something like @media screen and (prefers-reduced-motion: no-preference) over and over again. @custom-media will be a nice bit of relief to the ol’ muscle memory because it allows us to create aliases for queries.
In fact, Adam’s Open Props project has more than 45 of them that make for excellent recipes:
@custom-media --motionOK (prefers-reduced-motion: no-preference);

@media (--motionOK) {
  /* animations and transitions */
}
Open Props @custom-media Recipes originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The @custom-media at-rule has landed in Firefox Nightly! I couldn’t find it in the release notes but Adam Argyle’s on the beat noting that it’s behind a flag for now.
Look for layout.css.custom-media.enabled
I often forget the exact name of …
Open Props @custom-media Recipes originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Open Props @custom-media Recipes

<p>Semantic HTML does a lot more accessibility work than we usually give it credit for already — and ARIA is simple to abuse when we use it both as a shortcut and as a supplement.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/i-learned-the-first-rule-of-aria-the-hard-way/">I Learned The First Rule of ARIA the Hard Way</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>Some time ago, I shipped a component that felt accessible by every measure I could test. Keyboard navigation worked. ARIA roles were correctly applied. Automated audits passed without a single complaint. And yet, a screen reader user couldn’t figure out how to trigger it. When I tested it myself with keyboard-only navigation and NVDA, I saw the same thing: the interaction simply didn’t behave the way I expected.</p>



<p>Nothing on the checklist flagged an error. Technically, everything was “right.” But in practice, the component wasn’t predictable. Here’s a simplified version of the component that caused the issue:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_qENBxzP" src="//codepen.io/anon/embed/qENBxzP?height=250&amp;theme-id=1&amp;slug-hash=qENBxzP&amp;default-tab=html,result" height="250" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed qENBxzP" title="CodePen Embed qENBxzP" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>As you can see in the demo, the markup is not at all complicated:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;button class="cta" role="link">Save changes&lt;/button></code></pre>



<p>And the fix was much easier than expected. I had to delete the ARIA <code>role</code> attribute that I had added with the best intentions.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_LEZYdwq" src="//codepen.io/anon/embed/LEZYdwq?height=250&amp;theme-id=1&amp;slug-hash=LEZYdwq&amp;default-tab=html,result" height="250" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed LEZYdwq" title="CodePen Embed LEZYdwq" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>The markup is even less complicated than before:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;button class="cta">Save changes&lt;/button></code></pre>



<p>That experience changed how I think about accessibility. The biggest lesson was this: <strong>Semantic HTML does a lot more accessibility work than we usually give it credit for already — and ARIA is simple to abuse when we use it both as a shortcut and as a supplement.</strong></p>



<p>Many of us already know <a href="https://www.w3.org/TR/using-aria/#secondrule" rel="noopener">the first rule of ARIA</a>: don’t use it. Well, use it. But not if the accessible benefits and functionality you need are already baked in, which it was in my case before adding the <code>role</code> attribute.</p>



<p>Let me outline exactly what happened, step-by-step, because I think the my error is actually a pretty common practice. There are many articles out there that say exactly what I’m saying here, but I think it often helps to internalize it by hearing it through a real-life experience.</p>



<p class="is-style-explanation"><strong>Note:</strong> This article was tested using keyboard navigation and a screen reader (NVDA) to observe real interaction behavior across native and ARIA-modified elements.</p>


<h3 class="wp-block-heading" id="1-start-with-the-simplest-possible-markup">1: Start with the simplest possible markup</h3>


<p>Again, this is merely a minimal page with a single native <code>&lt;button&gt;</code> and no ARIA. And by default, it allows keyboard focus and demonstrates the functionality of using <kbd>Tab</kbd>, <kbd>Enter</kbd>, and <kbd>Space</kbd> out of the box. Geoff recently made this case when <a href="https://css-tricks.com/explaining-the-accessible-benefits-of-using-semantic-html-elements/">explaining the accessibility benefits of semantic HTML elements</a>.</p>



<p>If the interaction triggers an action, then <a href="https://css-tricks.com/buttons-vs-links/">that element is a button</a>. And in this case, the <code>&lt;button&gt;</code> is designed to run a script that saves changes to a user profile:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;button>Save changes&lt;/button></code></pre>



<p>That single line gives us a surprising amount for free:</p>



<ul class="wp-block-list">
<li>Keyboard activation with the <code>Enter</code> and <code>Space</code> keys</li>



<li>Correct focus behavior</li>



<li>A role that assistive technology already understands</li>



<li>Consistent announcements across screen readers</li>
</ul>



<p>At this point, there is <em>no</em> ARIA — and that’s intentional. But I did have an existing class for styling buttons in my CSS, so I added that:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;button class="cta">Save changes&lt;/button></code></pre>


<h3 class="wp-block-heading" id="2-observe-the-native-behavior-before-adding-anything">2: Observe the native behavior before adding anything</h3>


<p>With just the native element in place, I tested three things:</p>



<ol class="wp-block-list">
<li><strong>Keyboard only</strong> (<kbd>Tab</kbd>, <kbd>Enter</kbd>, <kbd>Space</kbd>)</li>



<li><strong>A screen reader</strong> (listening to how the control is announced)</li>



<li><strong>Focus order</strong> within the page</li>
</ol>



<p>Everything behaved predictably. The browser was doing exactly what users expect. This step matters because it establishes a baseline. If something breaks later, you know it wasn’t HTML that caused it. In fact, we can see that everything is in perfect working order by inspecting the element in DevTool’s Accessibility panel.</p>



<figure class="wp-block-image size-full is-resized"><img data-recalc-dims="1" loading="lazy" decoding="async" width="674" height="314" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/s_9A57C4F0BA1949DC827C2F37A890F42010D59C3D51B76EB65DFC2B18EC963371_1766158725334_Screenshot2025-12-19at8.35.47AM.png?resize=674%2C314&#038;ssl=1" alt="DevTools Accessibility panel showing the accessible role of button with a label of Semantic Button." class="wp-image-391392" style="width:400px" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/s_9A57C4F0BA1949DC827C2F37A890F42010D59C3D51B76EB65DFC2B18EC963371_1766158725334_Screenshot2025-12-19at8.35.47AM.png?w=674&amp;ssl=1 674w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/s_9A57C4F0BA1949DC827C2F37A890F42010D59C3D51B76EB65DFC2B18EC963371_1766158725334_Screenshot2025-12-19at8.35.47AM.png?resize=300%2C140&amp;ssl=1 300w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>


<h3 class="wp-block-heading" id="3-add-well-intentioned-aria">3: Add well‑intentioned ARIA</h3>


<p>The problem crept in when I tried to make the button behave like a link:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;button class="cta" role="link">Save changes&lt;/button></code></pre>



<p>I did this for styling and routing reasons. This button needed to be styled a little differently than the default <code>.cta</code> class and I figured I could use the ARIA attribute rather than using a modifier class. You can start to see how I let the styling dictate and influence the functionality. A <code>&lt;button></code> is still the correct element for this purpose, but I wanted it to look like a link because of the design requirements. Might as well give that element a <code>link</code> role then, right?</p>



<p>On the surface, nothing seemed broken. Automated tools stayed quiet. But in real use, the cracks showed quickly:</p>



<ul class="wp-block-list">
<li><kbd>Space</kbd> no longer activated the control reliably.</li>



<li>Screen readers announced conflicting roles.</li>



<li>Keyboard users encountered behavior that didn’t fully match either a button or a link.</li>
</ul>



<p>ARIA didn’t add clarity here; it introduced ambiguity. But I had already “tested” my work and nothing was screaming at me that I’d conflated the element’s <code>role</code> with another type of element. Again, all it takes is a quick look at DevTools.</p>



<figure class="wp-block-image size-full is-resized"><img data-recalc-dims="1" loading="lazy" decoding="async" width="840" height="348" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/s_9A57C4F0BA1949DC827C2F37A890F42010D59C3D51B76EB65DFC2B18EC963371_1766158840330_Screenshot2025-12-19at8.39.53AM.png?resize=840%2C348&#038;ssl=1" alt="DevTools Accessibility panel showing the accessible role of link with a label of Semantic Button." class="wp-image-391391" style="aspect-ratio:2.4138307552320293;width:400px;height:auto" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/s_9A57C4F0BA1949DC827C2F37A890F42010D59C3D51B76EB65DFC2B18EC963371_1766158840330_Screenshot2025-12-19at8.39.53AM.png?w=840&amp;ssl=1 840w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/s_9A57C4F0BA1949DC827C2F37A890F42010D59C3D51B76EB65DFC2B18EC963371_1766158840330_Screenshot2025-12-19at8.39.53AM.png?resize=300%2C124&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2026/01/s_9A57C4F0BA1949DC827C2F37A890F42010D59C3D51B76EB65DFC2B18EC963371_1766158840330_Screenshot2025-12-19at8.39.53AM.png?resize=768%2C318&amp;ssl=1 768w" sizes="auto, (min-width: 735px) 864px, 96vw" /></figure>


<h3 class="wp-block-heading" id="4-back-to-semantics">4: Back to semantics</h3>


<p>The fix wasn’t clever. It was subtractive. I reverted my styles, used a class for styling, and went back to the semantic markup prior to changing the accessible role:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;button class="cta">Save changes&lt;/button></code></pre>



<p>I know it sounds easy: if it’s an action, use a <code>&lt;button&gt;</code>. If it takes you somewhere, use a link (<code>&lt;a&gt;</code>). But, in practice, we’re making decisions with every key we type and it’s just as easy to conflate actions with destinations. In this case, I totally used the correct element! My mistake was thinking that ARIA was an appropriate styling hook for my CSS.</p>



<p>Once the correct element was in place — absent of ARIA — the issues disappeared. Instead, I could define a new classname and, you guessed it, use keep styles with styles.</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;button class="cta cta-alt">Save changes&lt;/button></code></pre>



<p>Just like that, I was able to style the element how I needed and the user who report the issue was able to confirm that everything worked as expected. It was an inadvertent mistake born of a basic misunderstanding about ARIA’s place in the stack.</p>


<h3 class="wp-block-heading" id="why-this-keeps-happening">Why this keeps happening</h3>


<p>ARIA attributes are used to define the nature of something but they do not redefine the behavioral default of the native elements. When we override semantics, we quietly take responsibility for:</p>



<ul class="wp-block-list">
<li>keyboard interactions,</li>



<li>focus management,</li>



<li>expected announcements, and</li>



<li>platform‑specific quirks.</li>
</ul>



<p>That’s a large surface area to maintain, and it’s why small ARIA changes can have outsized and unpredictable effects.</p>


<h3 class="wp-block-heading" id="a-rule-i-now-follow">A rule I now follow</h3>


<p>Here’s the workflow that has saved me the most time and bugs:</p>



<ol class="wp-block-list">
<li>Use native HTML to express intent.</li>



<li>Test with keyboard and a screen reader.</li>



<li>Add ARIA only to communicate <em>missing state</em>, not to redefine roles.</li>
</ol>



<p>If ARIA feels like it’s doing heavy lifting, it’s usually a sign the markup is fighting the browser.</p>


<h3 class="wp-block-heading" id="where-aria-does-belong">Where ARIA <em>does</em> belong</h3>


<p>One example would be a simple disclosure widget using a native <code>&lt;button&gt;</code> plus <a href="https://www.w3.org/TR/wai-aria-1.2/#aria-expanded" rel="noopener"><code>aria-expanded</code></a> to communicate state — showing ARIA used to <em>add state</em>, not replace semantics.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_WbxNzob" src="//codepen.io/anon/embed/WbxNzob?height=250&amp;theme-id=1&amp;slug-hash=WbxNzob&amp;default-tab=html,result" height="250" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed WbxNzob" title="CodePen Embed WbxNzob" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>This demo uses a native <code>&lt;button&gt;</code> with <code>aria-expanded</code>, which is toggled with a sprinkle of JavaScript:</p>



<pre rel="JavaScript" class="wp-block-csstricks-code-block language-javascript" data-line=""><code markup="tt">const button = document.getElementById("toggle");
const panel = document.getElementById("panel");

button.addEventListener("click", () => {
  const expanded = button.getAttribute("aria-expanded") === "true";
  button.setAttribute("aria-expanded", !expanded);
  panel.hidden = expanded;
});</code></pre>



<p>The accessible state (<code>true</code>/<code>false</code>) is communicated correctly without replacing the button’s semantics.</p>



<p>Now, I know that ARIA is essential when:</p>



<ul class="wp-block-list">
<li>communicating expanded or collapsed state,</li>



<li>announcing dynamic updates,</li>



<li>building truly custom widgets, and</li>



<li>exposing relationships HTML can’t express.</li>
</ul>



<p>Used this way, ARIA complements semantic HTML instead of competing with it.</p>


<h3 class="wp-block-heading" id="let-the-platform-work-for-you">Let the platform work for you</h3>


<p>The biggest accessibility improvement I’ve made wasn’t learning about more attributes — it was trusting the ones browsers already understand. Semantic HTML is not the baseline you move past. It’s the foundation that everything else depends on.</p>



<p>And that’s what I really hope you take away from my experience. We all make mistakes. It’s part of the job, unfortunately. But what good are they if we can’t learn from them, even if it takes a hard lesson.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/i-learned-the-first-rule-of-aria-the-hard-way/">I Learned The First Rule of ARIA the Hard Way</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Some time ago, I shipped a component that felt accessible by every measure I could test. Keyboard navigation worked. ARIA roles were correctly applied. Automated audits passed without a single complaint. And yet, a screen reader user couldn’t figure out how to trigger it. When I tested it myself with keyboard-only navigation and NVDA, I saw the same thing: the interaction simply didn’t behave the way I expected.
Nothing on the checklist flagged an error. Technically, everything was “right.” But in practice, the component wasn’t predictable. Here’s a simplified version of the component that caused the issue:
CodePen Embed Fallback
As you can see in the demo, the markup is not at all complicated:
<button class="cta" role="link">Save changes</button>
And the fix was much easier than expected. I had to delete the ARIA role attribute that I had added with the best intentions.
CodePen Embed Fallback
The markup is even less complicated than before:
<button class="cta">Save changes</button>
That experience changed how I think about accessibility. The biggest lesson was this: Semantic HTML does a lot more accessibility work than we usually give it credit for already — and ARIA is simple to abuse when we use it both as a shortcut and as a supplement.
Many of us already know the first rule of ARIA: don’t use it. Well, use it. But not if the accessible benefits and functionality you need are already baked in, which it was in my case before adding the role attribute.
Let me outline exactly what happened, step-by-step, because I think the my error is actually a pretty common practice. There are many articles out there that say exactly what I’m saying here, but I think it often helps to internalize it by hearing it through a real-life experience.
Note: This article was tested using keyboard navigation and a screen reader (NVDA) to observe real interaction behavior across native and ARIA-modified elements.
1: Start with the simplest possible markup
Again, this is merely a minimal page with a single native <button> and no ARIA. And by default, it allows keyboard focus and demonstrates the functionality of using Tab, Enter, and Space out of the box. Geoff recently made this case when explaining the accessibility benefits of semantic HTML elements.
If the interaction triggers an action, then that element is a button. And in this case, the <button> is designed to run a script that saves changes to a user profile:
<button>Save changes</button>
That single line gives us a surprising amount for free:
Keyboard activation with the Enter and Space keys
Correct focus behavior
A role that assistive technology already understands
Consistent announcements across screen readers
At this point, there is no ARIA — and that’s intentional. But I did have an existing class for styling buttons in my CSS, so I added that:
<button class="cta">Save changes</button>
2: Observe the native behavior before adding anything
With just the native element in place, I tested three things:
Keyboard only (Tab, Enter, Space)
A screen reader (listening to how the control is announced)
Focus order within the page
Everything behaved predictably. The browser was doing exactly what users expect. This step matters because it establishes a baseline. If something breaks later, you know it wasn’t HTML that caused it. In fact, we can see that everything is in perfect working order by inspecting the element in DevTool’s Accessibility panel.



3: Add well‑intentioned ARIA
The problem crept in when I tried to make the button behave like a link:
<button class="cta" role="link">Save changes</button>
I did this for styling and routing reasons. This button needed to be styled a little differently than the default .cta class and I figured I could use the ARIA attribute rather than using a modifier class. You can start to see how I let the styling dictate and influence the functionality. A <button> is still the correct element for this purpose, but I wanted it to look like a link because of the design requirements. Might as well give that element a link role then, right?
On the surface, nothing seemed broken. Automated tools stayed quiet. But in real use, the cracks showed quickly:
Space no longer activated the control reliably.
Screen readers announced conflicting roles.
Keyboard users encountered behavior that didn’t fully match either a button or a link.
ARIA didn’t add clarity here; it introduced ambiguity. But I had already “tested” my work and nothing was screaming at me that I’d conflated the element’s role with another type of element. Again, all it takes is a quick look at DevTools.



4: Back to semantics
The fix wasn’t clever. It was subtractive. I reverted my styles, used a class for styling, and went back to the semantic markup prior to changing the accessible role:
<button class="cta">Save changes</button>
I know it sounds easy: if it’s an action, use a <button>. If it takes you somewhere, use a link (<a>). But, in practice, we’re making decisions with every key we type and it’s just as easy to conflate actions with destinations. In this case, I totally used the correct element! My mistake was thinking that ARIA was an appropriate styling hook for my CSS.
Once the correct element was in place — absent of ARIA — the issues disappeared. Instead, I could define a new classname and, you guessed it, use keep styles with styles.
<button class="cta cta-alt">Save changes</button>
Just like that, I was able to style the element how I needed and the user who report the issue was able to confirm that everything worked as expected. It was an inadvertent mistake born of a basic misunderstanding about ARIA’s place in the stack.
Why this keeps happening
ARIA attributes are used to define the nature of something but they do not redefine the behavioral default of the native elements. When we override semantics, we quietly take responsibility for:
keyboard interactions,
focus management,
expected announcements, and
platform‑specific quirks.
That’s a large surface area to maintain, and it’s why small ARIA changes can have outsized and unpredictable effects.
A rule I now follow
Here’s the workflow that has saved me the most time and bugs:
Use native HTML to express intent.
Test with keyboard and a screen reader.
Add ARIA only to communicate missing state, not to redefine roles.
If ARIA feels like it’s doing heavy lifting, it’s usually a sign the markup is fighting the browser.
Where ARIA does belong
One example would be a simple disclosure widget using a native <button> plus aria-expanded to communicate state — showing ARIA used to add state, not replace semantics.
CodePen Embed Fallback
This demo uses a native <button> with aria-expanded, which is toggled with a sprinkle of JavaScript:
const button = document.getElementById("toggle");
const panel = document.getElementById("panel");

button.addEventListener("click", () => {
  const expanded = button.getAttribute("aria-expanded") === "true";
  button.setAttribute("aria-expanded", !expanded);
  panel.hidden = expanded;
});
The accessible state (true/false) is communicated correctly without replacing the button’s semantics.
Now, I know that ARIA is essential when:
communicating expanded or collapsed state,
announcing dynamic updates,
building truly custom widgets, and
exposing relationships HTML can’t express.
Used this way, ARIA complements semantic HTML instead of competing with it.
Let the platform work for you
The biggest accessibility improvement I’ve made wasn’t learning about more attributes — it was trusting the ones browsers already understand. Semantic HTML is not the baseline you move past. It’s the foundation that everything else depends on.
And that’s what I really hope you take away from my experience. We all make mistakes. It’s part of the job, unfortunately. But what good are they if we can’t learn from them, even if it takes a hard lesson.
I Learned The First Rule of ARIA the Hard Way originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Semantic HTML does a lot more accessibility work than we usually give it credit for already — and ARIA is simple to abuse when we use it both as a shortcut and as a supplement.
I Learned The First Rule of ARIA the Hard Way originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I Learned The First Rule of ARIA the Hard Way

<p>I love me some good web research reports. <a href="https://css-tricks.com/tag/research/">I&#8217;m a sucker for them.</a> HTTP Archive&#8217;s Web Almanac is one report I look forward to every year, and I know I&#8217;m not alone there. It&#8217;s one of those highly-anticipated publications on &#8230;</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/http-archive-2025-web-almanac/">HTTP Archive 2025 Web Almanac</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>I love me some good web research reports. <a href="https://css-tricks.com/tag/research/">I&#8217;m a sucker for them.</a> HTTP Archive&#8217;s Web Almanac is one report I look forward to every year, and I know I&#8217;m not alone there. It&#8217;s one of those highly-anticipated publications on the state of the web, chock-full of well-documented findings about millions of live websites — 17.2 million in this edition! — from page content, to performance, to accessibility, to UX, to&#8230; well, let&#8217;s just get to it.</p>



<span id="more-391564"></span>



<p><a href="https://almanac.httparchive.org/en/2025/" rel="noopener">It just came out</a>, so there&#8217;s no way I&#8217;ve read through all 15 chapters, let alone digested and reflected on everything in it. Really, I just want you to be aware that it&#8217;s out. That said, it&#8217;s hard for me to resist sharing at least a few notable stats that hit me and that I&#8217;ll be sure to dig into.</p>



<p>Some highlights:</p>



<ul class="wp-block-list">
<li><strong>New <code><a href="https://css-tricks.com/almanac/properties/t/text-wrap-style/">text-wrap</a></code> values are showing up!</strong> It&#8217;s small, but not surprising for features that only shipped as far back as 2023. Specifically, I&#8217;m looking at the <code>balance</code> (2.67%) and <code>pretty</code> (1.71%) values.</li>



<li><strong>Variable fonts are no longer a novelty.</strong> &#8220;How popular are variable fonts? This year, 39.4% of desktop websites and 41.3% of mobile websites used at least one variable font on their pages. In other words, now about 4 in 10 sites are using variable fonts.&#8221;</li>



<li><strong>Why can&#8217;t we nail down color contrast?!</strong> Only 30% of sites meet WCAG guidelines, and though that&#8217;s a number that&#8217;s trending up (21% in 2020), that&#8217;s a sorry stat.</li>



<li><strong>Removing focus styles is an epidemic.</strong> A whopping 67% of sights remove focus outlines despite <a href="https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html" rel="noopener">WCAG&#8217;s requirement</a> that &#8220;Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.&#8221;</li>



<li><strong>Many images are apparently decorative.</strong> At least, that&#8217;s what 30% of sites are suggesting by leaving the <code>alt</code> attribute empty. But if we consider that 14% of sites leave off the attribute completely, we&#8217;re looking at roughly 44% of sites that aren&#8217;t describing their visual content. On that note, <a href="https://www.smashingmagazine.com/2021/06/img-alt-attribute-alternate-description-decorative/" rel="noopener">your images probably are not decorative</a>.</li>



<li><strong>ARIA labels are everywhere.</strong> We&#8217;re looking at 70% usage (29% on buttons). This doesn&#8217;t mean anything in and of itself. It could be a good thing, <a href="https://css-tricks.com/explaining-the-accessible-benefits-of-using-semantic-html-elements/">but could also be an issue without proper usage</a>.</li>



<li><strong>The CMS landscape is largely unchanged.</strong> I mean, WordPress is still the dominant force, and that&#8217;s no dang surprise. At this point, its expansion wavers between a couple percentage points every year. &#8220;These changes suggest that WordPress is shifting from a focus on expansion to one on stabilization.&#8221; That&#8217;s a good thing.</li>



<li><strong>Bloat, bloat, bloat.</strong> &#8220;In July 2015, the median mobile home page was a meager 845 KB. As of July 2025, the same median page is now 2,362 KB. The page decade brought a 202.8% increase.&#8221; In a perfect world where we&#8217;re all super conscious about page weight, I&#8217;d say we oughta aim for less than half that total.</li>



<li><strong>JavaScript be heavy.</strong> Images are heaviest, of course, but 697 KB of JavaScript is a lot to stomach. That massive growth in page weight since 2015 is more support that <a href="https://infrequently.org/2024/08/the-landscape/" rel="noopener">this was a lost decade we must reckon with</a>.</li>
</ul>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/http-archive-2025-web-almanac/">HTTP Archive 2025 Web Almanac</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


I love me some good web research reports. I’m a sucker for them. HTTP Archive’s Web Almanac is one report I look forward to every year, and I know I’m not alone there. It’s one of those highly-anticipated publications on the state of the web, chock-full of well-documented findings about millions of live websites — 17.2 million in this edition! — from page content, to performance, to accessibility, to UX, to… well, let’s just get to it.




It just came out, so there’s no way I’ve read through all 15 chapters, let alone digested and reflected on everything in it. Really, I just want you to be aware that it’s out. That said, it’s hard for me to resist sharing at least a few notable stats that hit me and that I’ll be sure to dig into.
Some highlights:
New text-wrap values are showing up! It’s small, but not surprising for features that only shipped as far back as 2023. Specifically, I’m looking at the balance (2.67%) and pretty (1.71%) values.
Variable fonts are no longer a novelty. “How popular are variable fonts? This year, 39.4% of desktop websites and 41.3% of mobile websites used at least one variable font on their pages. In other words, now about 4 in 10 sites are using variable fonts.”
Why can’t we nail down color contrast?! Only 30% of sites meet WCAG guidelines, and though that’s a number that’s trending up (21% in 2020), that’s a sorry stat.
Removing focus styles is an epidemic. A whopping 67% of sights remove focus outlines despite WCAG’s requirement that “Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.”
Many images are apparently decorative. At least, that’s what 30% of sites are suggesting by leaving the alt attribute empty. But if we consider that 14% of sites leave off the attribute completely, we’re looking at roughly 44% of sites that aren’t describing their visual content. On that note, your images probably are not decorative.
ARIA labels are everywhere. We’re looking at 70% usage (29% on buttons). This doesn’t mean anything in and of itself. It could be a good thing, but could also be an issue without proper usage.
The CMS landscape is largely unchanged. I mean, WordPress is still the dominant force, and that’s no dang surprise. At this point, its expansion wavers between a couple percentage points every year. “These changes suggest that WordPress is shifting from a focus on expansion to one on stabilization.” That’s a good thing.
Bloat, bloat, bloat. “In July 2015, the median mobile home page was a meager 845 KB. As of July 2025, the same median page is now 2,362 KB. The page decade brought a 202.8% increase.” In a perfect world where we’re all super conscious about page weight, I’d say we oughta aim for less than half that total.
JavaScript be heavy. Images are heaviest, of course, but 697 KB of JavaScript is a lot to stomach. That massive growth in page weight since 2015 is more support that this was a lost decade we must reckon with.
HTTP Archive 2025 Web Almanac originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I love me some good web research reports. I’m a sucker for them. HTTP Archive’s Web Almanac is one report I look forward to every year, and I know I’m not alone there. It’s one of those highly-anticipated publications on …
HTTP Archive 2025 Web Almanac originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.