DEV Community: richi.codes

CSS alpha(): one brand color, every transparency

richi.codes — Mon, 02 Nov 2026 08:30:43 +0000

This note has an interactive demo. Try it in the original

CSS finally has a function that does exactly one thing: take a color and change how transparent it is. alpha(from var(--brand) / 40%) is your brand color at 40% opacity, whatever format --brand was written in. It works in Chrome 152, Firefox 155 and Safari 27, and it has been Baseline since September 14, 2026. In the demo above, a single variable feeds a glass card, a progress bar, the borders and a six-step scale. Pick a color, drag the slider, and the whole thing follows.

Why this needed its own function

If you keep a design system with tokens, you know the problem. You define --brand once, and then you need the same color at 10% for a background, 30% for a border, 50% for a glow. For years the options were keeping a separate hand-written rgba() for each one (and forgetting to update them when the brand changes), or reaching for heavier tools:

Relative color syntax (rgb(from var(--brand) r g b / 40%)) works, but you have to choose a color function and spell out every channel. With rgb(), hsl() or hwb() the output is serialized as color(srgb …), according to MDN.
color-mix() with transparent (color-mix(in oklab, var(--brand) 40%, transparent)) also works, but now you're picking an interpolation space just to make something see-through.

alpha() skips both decisions. According to the spec, it refers to an origin color and "only change[s] the alpha channel". The color components stay as they are, and "the result of this function is in the color space of the origin color".

How it works

The grammar is short. This is the one line in CSS Color Module Level 5:

alpha() = alpha(from <color> / [<alpha-value> | none])

Two things to know:

After from goes any color: a hex value, oklch(), a named color, or var(--brand).
After the slash goes the new alpha. Inside it, the keyword alpha means the origin color's current alpha as a number (1.0 is 100%), so you can work relative to it.

This is the pattern the demo uses, minus the slider plumbing:

:root {
  --brand: oklch(62% 0.24 300);
}

.glass {
  /* same color, fixed opacity */
  background: alpha(from var(--brand) / 16%);
  border: 1px solid alpha(from var(--brand) / 57%);
  box-shadow: 0 18px 50px -18px alpha(from var(--brand) / 47%);
}

.ghost {
  /* half of whatever alpha the origin already had */
  background: alpha(from var(--brand) / calc(alpha * 0.5));
}

Unlike oklch(from …) or rgb(from …), alpha() doesn't expose the channel keywords (l, c, h, r, g, b). MDN is explicit that it's "solely concerned with the alpha channel". Use it when that's all you want to change, and keep relative color syntax for when you want a lighter or more saturated variant.

Seeing the color space difference

The bottom panel of the demo runs getComputedStyle() on the same color written three ways. In Chromium 153, with oklch(62% 0.24 300) as the origin and 42% opacity, I get:

alpha(from … / 42%)                     → oklch(0.62 0.24 300 / 0.42)
rgb(from … r g b / 42%)                 → color(srgb 0.626103 0.325981 0.99362 / 0.42)
color-mix(in oklab, … 42%, transparent) → oklab(0.62 0.12 -0.207846 / 0.42)

On screen, all three look the same. But only alpha() gives you back what you put in: an OKLCh color stays OKLCh. That matters if you inspect tokens in DevTools or feed computed values into other color math. With a hex origin, the same call in Chromium returns rgba(255, 82, 0, 0.4), which is still the sRGB the hex value came from.

Browser support and gotchas

Support: Chrome and Edge 152, Firefox 155, Safari 27 (desktop and iOS), according to MDN's browser-compat-data. That makes it Baseline "newly available" from September 14, 2026, so a lot of browsers in use today still won't understand it.
Fallback: the classic trick doesn't work here. Normally you write a fallback declaration first, and if the browser can't parse the second one, it ignores it. But alpha(from var(--brand) / 16%) contains var(), so the browser can't check it until computed-value time. When it fails then, MDN explains that "the declaration is not ignored": the property falls back to its initial or inherited value. I tested the same pattern in Chromium with a made-up function: background: red; background: notafunction(from var(--brand) / 16%) ends up transparent, not red. So use @supports. color-mix() has been Baseline since May 2023, which makes it a safe plan B. This is what the demo does:

.glass { background: alpha(from var(--brand) / 16%); }

@supports not (color: alpha(from red / 50%)) {
  .glass { background: color-mix(in oklab, var(--brand) 16%, transparent); }
}

The demo checks the same thing in JavaScript with CSS.supports('color', 'alpha(from red / 50%)') and shows a notice when it falls back.

Tokens resolve where they're declared. If you write --brand-soft: alpha(from var(--brand) / 20%) on :root and then override --brand inside .teal, var(--brand-soft) in that section still uses the root color. I checked this in Chromium: the token stayed orange, while the same alpha() written directly on the element turned teal. Either declare the derived tokens on the element where --brand changes, or use alpha() inline.
It's from, not a comma. alpha(red, 50%) is invalid. The from keyword and the slash are both required.

What to keep an eye on

"Widely available" status. Baseline "newly available" means every engine has shipped it, not that every user has updated. Keep the fallback for a while.
Design tools catching up. Token pipelines and design apps that export rgba() copies of every shade could export a single color plus alpha() calls.
CSS Color 5 as a whole. alpha() is new in Level 5, alongside relative color syntax and color-mix(). It's the smallest function of the set, and probably the one you'll write most often.

Sources

Originally published at richi.codes.

Intl.Segmenter: split text without breaking emoji

richi.codes — Sun, 01 Nov 2026 08:30:41 +0000

This note has an interactive demo. Try it in the original

If you have ever animated a headline letter by letter and watched an emoji turn into a row of broken boxes, the problem was never your CSS: it was split(""). Intl.Segmenter splits text into the pieces a reader actually perceives, and as of October 16, 2026 it is Baseline Widely available.

Type anything into the demo above. The top row is what text.split("") gives you; the bottom row is Intl.Segmenter. With a family emoji, a flag and a word with an accent, the difference is hard to miss.

Why `split("")` lies to you

JavaScript strings are sequences of UTF-16 code units. length, split("") and index access all work in those units, not in characters as a person sees them:

const text = "👨‍👩‍👧‍👦 café";

text.length;            // 16
text.split("").length;  // 16 → lone surrogate halves
[...text].length;       // 12 → code points: the family falls apart

Spreading the string ([...text]) is better, because it iterates by code points, but it is still not what you want. That family emoji is seven code points: four people glued together with three zero-width joiners. A flag is two regional indicator symbols. An accent can be a separate combining mark after the letter. None of that is a "character" to the reader.

What Intl.Segmenter does

Intl.Segmenter performs locale-sensitive text segmentation. You create one with a locale and a granularity, and its segment() method returns an iterable Segments object:

const segmenter = new Intl.Segmenter("en", { granularity: "grapheme" });

[...segmenter.segment(text)].map((s) => s.segment);
// ["👨‍👩‍👧‍👦", " ", "c", "a", "f", "é"]

granularity takes three values:

"grapheme" (the default): user-perceived characters, the grapheme clusters.
"word": word boundaries, as determined by the locale.
"sentence": sentence boundaries.

Each segment is an object with segment (the text), index (where it starts in the original string, in code units) and input (the whole string). With granularity: "word" you also get isWordLike, which is true for letters, numbers or ideographs and false for spaces and punctuation. That makes word counting a one-liner:

const words = new Intl.Segmenter("en", { granularity: "word" });
const countWords = (str) =>
  [...words.segment(str)].filter((s) => s.isWordLike).length;

countWords("Hello, world! It’s 2026."); // 4

Word mode is where the API really earns its keep. Splitting on spaces does nothing for languages that don't put spaces between words, such as Japanese, Chinese or Thai. The MDN example segments 吾輩は猫である。名前はたぬき。 into 吾輩 | は | 猫 | で | ある | 。 | 名前 | は | たぬき | 。 and counts 8 words. Hit the "Japanese" preset in the demo: split(" ") returns the whole sentence as one piece, and the segmenter returns the words.

The split-text animation, done right

This is the core of the demo above. Each grapheme goes into its own <span>, with its position in a custom property so CSS can stagger the animation:

const segmenter = new Intl.Segmenter(document.documentElement.lang || undefined, {
  granularity: "grapheme",
});

for (const el of document.querySelectorAll(".split")) {
  const pieces = [...segmenter.segment(el.textContent)].map(({ segment }, i) => {
    const span = document.createElement("span");
    span.textContent = segment;
    span.style.setProperty("--i", i);
    return span;
  });
  el.replaceChildren(...pieces);
}

.split span {
  display: inline-block;
  animation: pop 0.5s both;
  animation-delay: calc(var(--i) * 45ms);
}
@keyframes pop {
  from { opacity: 0; transform: translateY(0.5em) scale(0.6); }
}

The family emoji stays in one span, the flag stays a flag, and an accented letter keeps its accent. The demo wraps the same idea in a prefers-reduced-motion check so the animation goes away for people who asked for less motion.

Finding the segment at a position

Segments has one more method that is easy to miss: containing(index). You give it a code-unit index and it returns the segment that covers it, or undefined if the index is out of range:

const sentence = "Find the word under the cursor.";
words.segment(sentence).containing(11);
// { segment: "word", index: 9, input: "...", isWordLike: true }

That's exactly what you need to answer "which word is under the caret?" from an input's selectionStart. In the demo, tapping or focusing a piece in the bottom row calls containing() and shows the segment, its index, its .length in code units and the code points inside it. The family emoji reports a .length of 11.

Support and gotchas

According to MDN's browser compatibility data, Intl.Segmenter shipped in Chrome and Edge 87, Safari 14.1 (iOS 14.5) and Firefox 125, and in Node.js 16. web-features marks it Baseline Newly available on April 16, 2024, when Firefox 125 completed the set, and Widely available on October 16, 2026. Widely available is defined as 30 months after that keystone date.

Things to keep in mind:

index is in code units. That's convenient, because text.slice(s.index, s.index + s.segment.length) gives you the segment back. Just don't mix it with code-point positions from [...text].
isWordLike only exists in word mode. With "grapheme" or "sentence" it is undefined, not false.
It is locale-sensitive. Pass the language of the text, not the language of your UI, when they differ. If you pass nothing, the runtime's default locale is used.
new is mandatory. Calling Intl.Segmenter() without it throws a TypeError.
Fallback. If you still have to support older engines, check "Segmenter" in Intl. The demo falls back to Array.from(), which at least never splits surrogate pairs, and shows a warning. MDN links to a FormatJS polyfill if you need the real behavior.

What to keep an eye on

Your own split-text code. If a letter animation, a typewriter effect or a "reveal" component in your codebase uses split("") or [...text], try it with an emoji or a combining accent. Now that the API is Widely available, swapping in a grapheme segmenter is a small change.
Character counters. Any "280 characters left" counter built on .length is counting code units. Segmenting by grapheme gives you a number closer to what the user sees.
Word mode outside English. If your content is multilingual, word counts and "read time" estimates based on spaces are wrong for some languages. isWordLike fixes that without a dictionary of your own.

Sources

Originally published at richi.codes.

CSS gap decorations: lines between grid items

richi.codes — Sat, 31 Oct 2026 08:30:41 +0000

This note has an interactive demo. Try it in the original

Drawing a line between grid cells has always been a hack: borders on half the items, :nth-child() rules to remove the extra ones, or a coloured background peeking through the gaps. Since Chrome and Edge 149 there's a real property for it: row-rule and column-rule now work on grid and flex containers, not just on multi-column text.

I like this one because it fixes a very everyday problem. Bento layouts, dashboards, pricing tables, footers with columns: they all want separators, and separators belong to the gap, not to the items.

What gap decorations are

column-rule isn't new. It has drawn the line between columns of multi-column text for years. The CSS Gaps module takes that idea and extends it to grid and flexbox, adds the row direction with row-rule, and gives you control over where lines break, which gaps get a line, and how far the ends are pulled back.

Two rules from the spec are worth knowing before you start:

They take up no space. A decoration never moves anything. If it's wider than the gap, the adjacent items simply overlap it.
They're painted just above the container's border, and in a scroll container they scroll with the items.

The code the demo uses

The demo above is a four-column, four-row grid with nine tiles. The core is three declarations:

.bento {
  display: grid;
  gap: 18px;
  row-rule: 2px solid #FF5200;
  column-rule: 2px solid #00D4AA;
}

row-rule and column-rule are shorthands for -width, -style and -color, exactly like border. The defaults are also the same as a border's: medium, none and currentcolor. So if you forget the style, nothing gets painted. If you want the same line in both directions, rule sets both at once.

The part that has no equivalent with borders is that the value is a list. Choose the "Lists" pattern in the demo and you get this:

.bento {
  row-rule: 3px solid #FF5200, repeat(auto, 1px dashed #94A3B8), 3px solid #FF5200;
  column-rule: 2px dotted #00D4AA, 2px dashed #FF7E41;
}

Each value goes to one gap, in order. When there are more gaps than values, the list starts again, so the columns alternate dotted and dashed. repeat(auto, …) fills whatever the other values don't cover: here, first and last row gaps are thick and solid, and everything in between is a thin dashed line, however many rows there are. Only one repeat(auto, …) is allowed per value. There's also repeat(3, …) with a fixed count.

Breaks, empty cells and insets

The other three controls in the demo map to these properties:

rule-break: none, normal or intersection. With none, each line runs from one end of the gap to the other. With intersection, it's cut at every T and every cross. normal depends on the container: in grid it cuts at T junctions but runs through crosses; in flexbox it behaves like none.
rule-visibility-items: all, around or between. It decides whether a line is painted next to an empty cell. Tap the big tile to remove it and switch to between: the lines around the hole disappear, because there's no longer an item on both sides. The initial value, normal, behaves like all in grid. This one only applies to grid and multi-column containers.
rule-inset: moves the ends of each segment. A positive value pulls them back from the junction, and percentages are resolved against the width of the gap being crossed. There's also an overlap-join keyword, and longhands that separate the ends at the container's edges (cap) from the ones at junctions (junction).

When lines don't break, rule-overlap decides which direction is painted on top. The initial value is row-over-column.

Change patterns in the demo and the colour and width animate: the spec makes -color and -width animatable as lists, and I checked in Chromium that a transition on row-rule-color interpolates through intermediate colours. The style switches without interpolation.

Support and gotchas

Chrome and Edge 149 only for now. MDN's compatibility data marks row-rule, rule-break, rule-inset and the rest as experimental, with no support in Firefox or Safari. The spec is an Editor's Draft that's still changing: the last Working Draft is from 24 June 2026.
Don't feature-detect with column-rule. It has existed for multi-column since long before this, so the browser will say yes even if it doesn't paint anything in a grid. Ask about row-rule instead (MDN's examples do the same with @supports):

const supported = CSS.supports('row-rule', '1px solid red');

The fallback is free, but it's nothing. In a browser that doesn't know these properties, the declarations are ignored and the gaps remain empty. For decorative lines, that's usually acceptable. If the separator carries meaning, you need a plan B. The demo uses the classic one when detection fails: paint the container with the line colour clipped to content-box, with opaque, square-cornered items covering it. It works only for solid lines across every gap: no dashes, no breaks and no clean empty cells. I tested it in Chromium by forcing the fallback.
Lines don't make room. If you increase the width without increasing the gap, the items cover the line. Keep gap at least as wide as the rule.

What to keep an eye on

Firefox and Safari implementing it. Until then, use it as progressive enhancement and nothing more.
Changes to the spec: property names and behaviours are still being refined, including how it works with the new grid lanes containers.
Whether the design systems that today draw dividers with borders on each item start moving that to the container.

Sources

Originally published at richi.codes.

Scroll anchoring is Baseline: content stops jumping

richi.codes — Fri, 30 Oct 2026 08:30:41 +0000

This note has an interactive demo. Try it in the original

You're halfway down a page, an ad or a batch of new posts loads above you, and the paragraph you were reading slides off the screen. Since Safari 27, every major browser fights that jump for you. Scroll anchoring, and the overflow-anchor property that controls it, became Baseline on September 14, 2026.

What surprised me is how old this is: MDN's compatibility data lists Chrome 56 and Firefox 66. What was missing was Safari, and with it the iPhone.

What scroll anchoring does

The classic behaviour of a scroll container is to keep its scroll offset fixed. If something 300 px tall appears above what you're looking at, the offset stays the same, so everything you can see moves down by 300 px. The spec's introduction names the usual culprits: script inserting an ad iframe, or images without dimensions loading on a slow network.

Scroll anchoring flips that. The browser picks an anchor node inside the scroller, remembers where it is, and when a layout change moves it, adjusts the scroll offset by exactly the same amount. Your scroll position changes, but what you're looking at stays put.

That's what the demo above shows. Both panes are the same feed, the highlighted card is "where you are reading", and the dashed line marks where it was. Press "+ 3 posts above" or load the ad: on the left the card drops and the meter counts the pixels it moved; on the right the meter stays at 0 px and scrollTop grows instead. "Auto feed" keeps inserting posts every 1.4 seconds, which is the timeline-with-new-items situation where this matters most.

The code: it's on by default

There's nothing to turn on. The only CSS in the demo is the opt-out on the left pane:

.feed {
  overflow-y: auto; /* scroll anchoring applies here by default */
}

.bad .feed {
  overflow-anchor: none; /* the old behaviour: the content jumps */
}

overflow-anchor takes two values. auto, the initial value, makes an element eligible to be an anchor. none takes the element and its descendants out of anchor selection, and set on the scroller itself it disables anchoring for that scroller. The property doesn't inherit, but the spec notes you can't turn anchoring back on inside a none subtree, with one exception: a nested scroll container gets its own anchoring again unless it also says none.

How the anchor is chosen is worth knowing too. The spec's algorithm walks the scroller's children looking for a node that's fully visible, going deeper when a node is only partially visible, because deeper nodes are less likely to change internally. Elements with display: none, position: fixed, position: sticky or an absolute box positioned relative to something outside the scroller are skipped.

The fallback, if you need one

In browsers without native anchoring, the demo emulates it with the same idea in a few lines: note the reading card's position, insert the content, and compensate the difference.

if (!CSS.supports('overflow-anchor', 'auto')) {
  const before = reader.offsetTop;
  insertAbove();                                   // whatever adds content above
  feed.scrollTop += reader.offsetTop - before;    // put the reader back
}

offsetTop is relative to the feed because it has position: relative. I checked this snippet in Chromium with native anchoring switched off, and the card moved 0 px. Don't run it where anchoring is native: you'd compensate twice. In the demo, when the fallback is active, the right pane also gets overflow-anchor: none so only the script adjusts it.

Gotchas I hit or checked

Nothing happens at the very top. The spec says that if the scroller isn't scrolled away from its origin, no anchor is selected. I tested it: with scrollTop at 0, inserting a 50 px element above moved the content 52 px (the element plus its borders). That's deliberate: if you're at the top of a feed, you probably want to see the new items.
It only protects the anchor. While building the demo on a 375 px screen, the ad was first inserted between the visible top of the pane and the reading card. Following the spec's algorithm, the anchor is the first fully visible card from the top, which sat above the insertion point. That card stayed still, and my reading card got pushed down 150 px anyway. Correct per the spec, and a good reminder: anchoring compensates for changes above the anchor node, not for everything on screen.
Suppression triggers. If, within the same suppression window (roughly, the same turn of the event loop), something changes top/left/right/bottom, margin, padding, a width or height property, position or transform on the path between the anchor node and the scroller, the adjustment is cancelled.
It fires scroll events. The adjustment counts as a scroll, so scroll listeners will see it. MDN's guide says that if a page misbehaves with anchoring, the usual reason is a scroll listener that doesn't expect this extra scrolling, and that Firefox can highlight the chosen anchor with the layout.css.scroll-anchoring.highlight flag in about:config.
It doesn't replace reserving space. Setting width and height on images or a min-height on ad slots still prevents the shift in the first place, including at the top of the page where anchoring stays out of the way.

What to keep an eye on

Safari 27 in the wild. Baseline "newly available" means the latest versions support it, not that everyone has updated. Until older iPhones age out, Safari users on 26 and earlier still get the jump.
Feeds and chat UIs. Prepending older messages or new posts was a classic place for hand-written scrollTop fixes. Now that every engine anchors, those fixes can compensate twice, so it's a good moment to check if they're still needed.
The spec is still a draft. The suppression window, the slice of the event loop in which adjustments are batched, is only defined in this draft; the spec itself notes it should move into the HTML standard eventually.

Sources

Originally published at richi.codes.

CSS style queries: one variable, every style

richi.codes — Thu, 29 Oct 2026 08:30:43 +0000

This note has an interactive demo. Try it in the original

You can now write @container style(--status: warn) and have CSS react to the value of a custom property, in every major browser. Container style queries became Baseline on May 19, 2026, when Firefox 151 shipped them, joining Chrome and Edge 111 and Safari 18.

Size container queries got all the attention. Style queries are the quieter half of the same feature, and I think they're the more surprising one: instead of asking "how wide is my container?", a rule asks "what value does my container have for this variable?". That turns a custom property into a switch that CSS can read.

What problem it solves

Think of a status card with three states: operational, degraded, down. Each state changes the border, the glow, the icon, the badge text and the colour of a chart. The usual answer is a modifier class or a data-status attribute, plus one selector per state for every piece of the card.

With a style query, the state lives in one custom property, and every descendant can ask about it:

<div class="card" style="--status: warn">
  <span class="badge">Degraded</span>
</div>

.badge { background: rgb(0, 212, 170); }

@container style(--status: warn) {
  .badge { background: rgb(251, 191, 36); }
}

That's the whole trick in the demo above. Each card carries style="--status: ok" and the only thing the JavaScript does on click is card.style.setProperty('--status', next). The colour, the ▲/✕ icon, the badge text (via content: var(--badge)), the latency figure, the progress bar and the pulsing ring are all CSS reacting to that value. The board view uses a second variable, --view: list, on the board element, and even the highlighted line in the code panel is a style query reading --last.

What makes this different from an attribute selector is that custom properties inherit and cascade. The value can come from a parent, a theme class higher up, a media query or an inline style, and every element below it can query it without knowing where it was set.

How it works

A few rules that I checked against MDN and the spec, and then in the browser:

No container-type needed. Every element is a style container. You only need container-type for size queries.
An element queries its ancestors, not itself. The query is evaluated against an ancestor container, so in the example above .badge can react to --status, but a rule that tries to style .card itself from its own --status won't match. That's why every card in the demo has an inner .body that carries the visual styles.
Stick to custom properties. The spec also allows normal properties, as in style(color: red), but MDN's guide says custom properties are the only style feature currently supported, and that query didn't match in the Chromium I tested with.
A query without a value checks "is it set?". style(--flag) is true when the computed value differs from the initial value. For an unregistered custom property, that means any value at all.

The gotcha: plain matching compares tokens

style(--status: warn) compares the computed value of the property with the value you wrote. For an unregistered custom property, that computed value is basically the text you wrote, so --accent: #00f does not match style(--accent: blue), and --n: calc(6/2) does not match style(--n: 3). I tested both in Chromium and neither matches.

If you need equivalent values to match, register the property with a type:

@property --accent {
  syntax: "<color>";
  inherits: true;
  initial-value: black;
}

/* Now --accent: #00f matches too */
@container style(--accent: blue) {
  .icon { color: var(--accent); }
}

For keyword-like states such as ok, warn and down, plain matching is exactly what you want, and you don't need @property at all.

Browser support and other gotchas

Support: Chrome and Edge 111, Safari 18, Firefox 151. Baseline "newly available" since May 19, 2026, so check your audience before you drop a fallback.
Safari and :root: MDN's compatibility data notes that in Safari the document element can't be a container. If you set a variable on :root and query it, the children of <body> are fine, because <body> inherits the value and acts as the container. A rule that styles <body> itself from it won't match.
Feature detection: @supports can't test an at-rule like this. In the demo I use a tiny probe: a hidden element sets --sq: yes, a style query gives its child a 7 px width, and JavaScript checks the computed width. If it doesn't match, the page adds a class and falls back to data-status attribute selectors that set the same variables.
Range syntax isn't Baseline. MDN documents a newer form with comparison operators, such as style(--columns >= 3), which compares values numerically. MDN's compatibility data lists Chrome 142 and no Safari support yet, so I left it out of the demo.

What to keep an eye on

Range syntax across engines. Numeric comparisons like style(0 < --n < 10) are where style queries get really expressive. Once Safari ships them, a lot of "set a class from JavaScript when the number crosses a threshold" code can go.
Querying normal properties. style(display: flex) or style(font-weight: bold) are in the spec, but you can't count on them in every browser yet. When they arrive, components will be able to adapt to how their parent is styled, not only to variables you set on purpose.
Design systems. A single --variant or --tone variable on a component, with style queries inside it, is a clean alternative to stacks of modifier classes. I expect to see that pattern a lot more now that it works everywhere.

Sources

Originally published at richi.codes.

CSS light-dark() now swaps images, not just colors

richi.codes — Wed, 28 Oct 2026 08:30:39 +0000

This note has an interactive demo. Try it in the original

light-dark() has been swapping colors for a while. Now it swaps images too: give it two gradients, two url()s, or an image and none, and the browser picks one based on the element's color scheme. As of September 14, 2026 that works in Chrome, Edge, Firefox and Safari, which makes it Baseline newly available.

The landscape in the demo above has no image files and no theming JavaScript. The sky, the sun that turns into a moon, the stars, the clouds, the hills and the lit windows are all background-image: light-dark(day, night). The JavaScript in the demo only does two things: it changes the scene's color-scheme when you click Day or Night, and it writes the code panel.

Why this matters

Dark mode always had a gap. Colors were easy with light-dark() or custom properties, but any time an image had to change (a logo, a hero gradient, a list bullet, a decorative background) you went back to @media (prefers-color-scheme: dark) and duplicated the rule.

A media query only knows what the user picked in their system or browser. It doesn't know that one section of your page is forced to color-scheme: dark. light-dark() resolves against the color scheme of the element it's applied to, so the same rule does the right thing in a dark sidebar sitting inside a light page. The three logo tiles at the bottom of the demo share one CSS rule: one tile is color-scheme: light, one is dark, and one is light dark, which follows your system.

How it works

The spec now defines two forms. The color form you already know, and an image form where each argument is an <image> or none:

:root {
  color-scheme: light dark;
}

.hero {
  background-image: light-dark(
    linear-gradient(#38bdf8, #fde68a), /* light */
    linear-gradient(#050816, #4c1d95)  /* dark */
  );
}

The first argument is used when the element's color scheme is light. The second is used when it's dark. As MDN notes, you have to opt in with color-scheme: light dark (usually on :root). Without it, the page stays light and you always get the first image.

To force one area to a scheme, set color-scheme on that element. That's exactly what the demo's switch does:

.scene[data-scheme="light"] { color-scheme: light; }
.scene[data-scheme="dark"]  { color-scheme: dark; }

none is valid on either side. The spec defines it as a fully transparent image with no natural size, and in Chrome the computed value reads image(rgba(0, 0, 0, 0)). It's handy for layers that should only appear in one scheme, like the stars:

.stars {
  background-image: light-dark(none, radial-gradient(1px 1px at 20px 30px, #fff 50%, transparent 51%));
}

It works anywhere an image goes, not only on backgrounds. The spec's own example uses it for list bullets:

ul.fancy {
  list-style-image: light-dark(url("light.svg"), url("dark.svg"));
}

I checked all of these snippets in Chromium by reading getComputedStyle() under a light and a dark scheme. Each time the browser returned the image I expected.

The gotcha that cost me a layer

My first version of the demo had no stars. I had written this:

/* Does NOT work: three images on the dark side */
.stars {
  background-image: light-dark(none, radial-gradient(…), radial-gradient(…), radial-gradient(…));
}

Each side of light-dark() takes a single image. A comma-separated list makes the whole value invalid, and the property falls back to none. The fix is one light-dark() per layer:

.stars {
  background-image:
    light-dark(none, var(--star1)),
    light-dark(none, var(--star2)),
    light-dark(none, var(--star3));
}

With var() it's harder to spot. The browser can't reject the declaration while parsing because it doesn't know what the variables contain yet, but in my test the result was still none.

Browser support

According to MDN's browser compatibility data, the image form shipped in Chrome and Edge 150, Firefox 150 and Safari 27. The color form has been around much longer: Chrome 123, Firefox 120 and Safari 17.5. If you test only with colors in an older browser, you may wrongly assume images work as well.

The demo checks support with:

CSS.supports('background-image', 'light-dark(none, linear-gradient(red, blue))');

If that returns false, the demo shows a notice and switches to a plan B: the same gradients chosen with a data-resolved attribute. In plain CSS, the fallback can be an @supports block:

.hero { background-image: url(light.png); }

@supports (background-image: light-dark(none, none)) {
  .hero { background-image: light-dark(url(light.png), url(dark.png)); }
}

The fade you see when you switch between day and night isn't part of light-dark(). It comes from a View Transition (document.startViewTransition), and the demo skips it when prefers-reduced-motion is on.

What to keep an eye on

Older browsers in your traffic. This is newly available, not widely available. Keep a fallback for anything important, like a logo that disappears on a dark background.
Image loading. Before you swap two heavy raster images this way, check in your own DevTools Network panel what each browser downloads and when.
Where you use it. Logos, illustrations and decorative gradients are the obvious first targets. Anything that used to need a duplicated rule inside a prefers-color-scheme query is worth reviewing.

Sources

Originally published at richi.codes.

View Transitions: animate any DOM change with one call

richi.codes — Tue, 27 Oct 2026 08:30:37 +0000

This note has an interactive demo. Try it in the original

You change the DOM however you like, wrap that change in document.startViewTransition(), and the browser animates from the old state to the new one. No FLIP math, no animation library, no keeping two copies of the UI alive. Same-document view transitions have been Baseline since October 14, 2025, and the parts that make them scale (view-transition-class and transition types) joined them by January 2026.

The demo above is a bento grid where nothing is animated by hand. The grid simply gets reordered, filtered or switched to a list, and a card turns into a full panel. Turn on Slow motion to watch it, or untick View Transitions to see the same DOM changes without it.

What it is and why it matters

Animating a layout change used to mean measuring every element before and after, then faking the motion with transforms. The View Transition API flips that around. When you call startViewTransition(update), the browser takes a snapshot of the current page, runs your update callback, captures the new state, and animates between the two with a tree of pseudo-elements that sits on top of the page.

By default the whole page is one snapshot called root, and you get a cross-fade. The spec's user agent stylesheet sets it to a quarter of a second. Give an element its own view-transition-name and it gets its own group, which the browser animates from its old position and size to its new ones. That's where the "wow" comes from.

How the demo works

Everything goes through one function. This is a trimmed version of the one in the demo:

function transition(type, update) {
  if (!document.startViewTransition) {
    update(); // Plan B: same change, no animation
    return;
  }
  const vt = document.startViewTransition({ update, types: [type] });
  // If another transition replaces this one before it starts animating,
  // ready rejects with an AbortError. Handle it or the console will complain.
  vt.ready.catch(() => {});
  return vt;
}

// Shuffling is just reordering DOM nodes
const shuffled = (arr) => arr.map((el) => [Math.random(), el]).sort((a, b) => a[0] - b[0]).map(([, el]) => el);
transition('shuffle', () => grid.append(...shuffled([...grid.children])));

Each card gets a unique name and a shared class:

tile.style.viewTransitionName = `tile-${i}`;

.tile { view-transition-class: tile; }

/* Don't capture the rest of the page: the toolbar updates instantly */
:root { view-transition-name: none; }

/* One rule for all twelve cards, thanks to the class */
::view-transition-group(.tile) {
  animation-duration: .55s;
  animation-timing-function: cubic-bezier(.2, .9, .25, 1.15);
}

Without view-transition-class you'd write a rule for tile-0, another for tile-1, and so on. A class doesn't need to be unique and doesn't create a group; it's only a styling hook for elements that already have a name.

The types array is what lets one API do several choreographies. In CSS, :active-view-transition-type() matches the root element while a transition of that type is running:

:root:active-view-transition-type(filter) {
  &::view-transition-new(.tile):only-child { animation: pop-in .45s both; }
  &::view-transition-old(.tile):only-child { animation: pop-out .3s both; }
}
/* pop-in and pop-out are ordinary @keyframes (scale + opacity) */

The :only-child trick comes from the spec. When a card is filtered out it only exists in the old state, so its group has an old image and no new one. Cards that come back only have a new image. That's how the demo pops cards in and out while the rest slide into place.

The card-to-panel morph doesn't need anything new. The name moves from one element to another inside the update:

transition('open', () => {
  tile.style.viewTransitionName = 'none';
  panel.style.viewTransitionName = name; // same name, different element
  panel.hidden = false;
});

Same name in the old and new state means same group, so the browser animates the card's box into the panel's box and cross-fades the content. I also give that pair a hero class with ::view-transition-group(.hero) { z-index: 1; }. Without it, in my first version the growing panel was painted underneath the cards that come after it.

Gotchas I hit or checked

Names must be unique among rendered elements. If two rendered elements share a view-transition-name, ready rejects and the transition is skipped. In Chromium I got an InvalidStateError. Hidden elements (display: none) don't count, which is why filtering works.
Interrupting a transition. Calling startViewTransition() while another is active skips the old one with an AbortError. If that happens before it starts animating, its ready promise rejects, and with no handler Chromium logs an uncaught "Transition was skipped" error. If it happens mid-animation, ready has already resolved and finished simply resolves early. Press Shuffle twice quickly in the demo and the log shows both cases.
Clicks during the animation. The ::view-transition overlay covers the page. In Chromium, a click during the animation hit <html>, not the button underneath, until I added ::view-transition { pointer-events: none; }.
The old state is a picture. The old snapshot is a static image and the new one is live, so stretched text during a size change is normal. MDN's trick of setting height: 100% on ::view-transition-old() and ::view-transition-new() smooths over the different aspect ratios, and the demo uses it.
Reduced motion is on you. With reduced motion emulated in Chromium, the transitions still ran. The demo sets animation: none on the view transition pseudo-elements inside @media (prefers-reduced-motion: reduce), so changes apply instantly.

Browser support

According to MDN's compat data, document.startViewTransition() works in Chrome 111, Firefox 144 and Safari 18. The options object with types, and :active-view-transition-type(), arrived in Chrome 125, Firefox 147 and Safari 18.2. view-transition-class is in Chrome 125, Firefox 144 and Safari 18.2. I ran the demo in Chromium 153 and WebKitGTK 2.52 with no console errors; I couldn't run Firefox in my environment. When the method doesn't exist, the demo shows a notice and applies the same changes instantly, which is exactly how the API was designed to degrade.

What to keep an eye on

Element-scoped transitions. MDN already documents Element.startViewTransition() for running transitions inside a subtree, but ViewTransition.transitionRoot is still marked experimental and Chromium-only.
match-element. It gives every selected element an automatic unique name, so you can skip the tile-${i} step for same-document transitions. Its support is in Chrome 137, Firefox 144 and Safari 18.4.
Cross-document transitions. The @view-transition rule for multi-page sites isn't Baseline yet; web-features still lists it without Firefox support.

Sources

Originally published at richi.codes.

CSS field-sizing: inputs that grow as you type

richi.codes — Mon, 26 Oct 2026 08:30:39 +0000

This note has an interactive demo. Try it in the original

A textarea that grows as you type used to need a script that measured scrollHeight on every keystroke. Now it takes one line of CSS: field-sizing: content. With Firefox 152 shipping it on June 16, 2026, the property is Baseline, so it works in Chrome, Edge, Firefox and Safari.

Type in the demo above, or press "Type it for me": the blanks in the sentence widen with every letter, the dropdown shrinks to the option you picked, and the chat box gains a line at a time until it hits its limit. Flip the switch to fixed and you get the old behaviour back on the same markup.

What it is and why it matters

Form controls have always had a size that ignores what's inside them. An <input> is just as wide whether it holds "Al" or a full street address, a <textarea> is however many rows and cols it gets, and a <select> is as wide as its longest option. The spec calls these "elements with default preferred size".

field-sizing takes two values:

fixed: the default. The control keeps that default preferred size.
content: the browser works out the control's size from its content and ignores the default.

That's the whole API. What makes it worth knowing is how many small annoyances it removes: chat composers, comment boxes, inline "fill in the blank" forms, tag inputs, compact filters with a <select> that shouldn't reserve space for its longest option. All of that used to mean JavaScript that measured text, ran on every input event and fought with fonts that hadn't loaded yet.

How it works

This is the CSS behind the demo, trimmed to the parts that matter:

/* The technique: fields take the size of their content */
input, textarea, select {
  field-sizing: content;
}

/* Inline blanks: never narrower than 3 characters,
   never wider than their container */
.sentence input,
.sentence select {
  min-width: 3ch;
  max-width: 100%;
}

/* Chat: fixed width, the height grows up to a limit and then scrolls */
.composer textarea {
  width: 100%;
  min-height: 2.75em;
  max-height: 7.5em;
  resize: none;
}

Three behaviours are going on there:

Text inputs shrink-wrap their text. The text, email, search, tel, url, number and password types grow and shrink with the value. If there's a placeholder, the field is wide enough to show it.
A textarea grows sideways first, then down. With nothing stopping it, a textarea with field-sizing: content behaves like a single-line field. Once it can't get any wider, because it has a fixed width or hits a max-width, it starts adding lines. When it reaches max-height, a scrollbar shows up. That's why the chat in the demo has width: 100%: the width stays put and only the height changes. The spec uses exactly this case as its example.
A dropdown fits the selected option. A regular <select> changes width as you pick different options. A list box (multiple, or size above 1) shows every option instead of scrolling.

In the demo the only JavaScript that touches sizes is the ResizeObserver that prints the pixel readouts, plus the fallback I'll get to below. The growing itself is all CSS.

The gotchas

I checked each of these in Chromium with a small test page before writing them down. They match what MDN describes:

Always set a min-width. An empty input with field-sizing: content and no minimum is as wide as the text cursor. In my test it measured 9 pixels. That's why the demo uses min-width: 3ch.
size, rows and cols stop doing anything. They set the default preferred size, and content ignores that. An <input size="40"> with field-sizing: content was exactly as narrow as one without the attribute.
A fixed width and height cancel the effect. If you set both, the control has a fixed size again. Use min-* and max-* to keep it within bounds, or fix only the width, as in the chat.
maxlength also caps the size, because the field stops growing when no more characters fit.
Mind the container. In a CSS grid, an item's automatic minimum size can let a growing field push the whole card wider than the screen. That's exactly what my first version of this demo did at 375 px. grid-template-columns: minmax(0, 1fr) on the parent fixes it, and so does min-width: 0 on the item.

Browser support

According to MDN's compatibility data, Chrome and Edge 123 (March 2024) were first, followed by Safari 26.2 (December 2025) and Firefox 152 (June 2026). That makes it Baseline newly available from June 16, 2026. For the next few months, some people will still be on browsers without it.

The good news is that the fallback is free: a browser that doesn't understand field-sizing ignores the declaration and draws the form exactly as it always has. If the old size is acceptable, you don't need anything else. If it isn't, check for support and only load the old trick when the property is missing:

if (!CSS.supports('field-sizing', 'content')) {
  // Old trick: measure and set the size by hand
  textarea.addEventListener('input', () => {
    textarea.style.height = 'auto';
    textarea.style.height = textarea.scrollHeight + 'px';
  });
}

The demo does exactly that, and shows a notice when it's running on the fallback. In CSS you can use @supports (field-sizing: content) for the same check.

What to keep an eye on

The spec home has changed. field-sizing now lives in CSS Form Control Styling Level 1 (it moved there from CSS UI 4). That draft also covers appearance: base and fully styleable form controls, so expect more news in this area.
Long fields in real layouts. A field that grows changes the layout around it. In flex and grid that's fine, but a max-width is always worth having.
Removing old code. If you have a dependency or a hook whose only job is to auto-size textareas, it's a good candidate to delete once your audience is on browsers from the last few months.

Sources

Originally published at richi.codes.

CSS contrast-color(): text that picks its own color

richi.codes — Sun, 25 Oct 2026 08:30:39 +0000

This note has an interactive demo. Try it in the original

You give CSS a background color and it hands back white or black, whichever reads better on it. That's contrast-color(), and since April 2026 it works in Chrome, Firefox and Safari.

Play with the demo above for a minute. The big card has no text color set anywhere: drag the lightness slider, or hit Sweep, and watch the text flip from white to black at the point where black starts winning. The strip of twelve tiles below is the same idea at a glance: same lightness and chroma, twelve hues, and each tile flips at a different spot because yellow and blue don't have the same luminance at the "same" lightness.

What it is and why it matters

Any time a color comes from data (a tag color from a CMS, a user-picked theme, a chart series, a team's brand color) you need a text color that stays legible on top of it. Until now that meant a JavaScript helper, a Sass function at build time, or a lookup table of hand-checked pairs. contrast-color() moves that decision into the browser, at computed-value time, so it also follows custom properties, :hover states and theme switches.

There's a real example in this very repo. The active tag chip in the notes explorer on this site uses bg-richi-orange text-white, which is white on #FF5200. By the WCAG 2.1 formula that pair gives 3.25:1; black on the same orange gives 6.46:1. contrast-color(#FF5200) returns black. The demo starts on that exact orange so you can see it.

How it works

The minimal version is three lines, and it's what the demo card uses:

.badge {
  --bg: #FF5200;
  background: var(--bg);
  color: contrast-color(var(--bg));
}

The CSS Color Level 5 spec is short on purpose. The function takes one <color> and resolves to either white or black, whichever produces maximum contrast with the input used as a solid background. If both tie, it returns white. That's it: no target ratio, no list of candidates, no custom colors. The spec's changelog records that the function was simplified by a working group resolution, and a note says future versions are expected to add more control over the algorithm and the returned color.

Two details from the spec are worth knowing:

The algorithm is up to the browser. The spec says the exact contrast algorithm is UA-defined and advises browsers not to simply use the WCAG 2.1 contrast ratio, because of its known issues. It does require that the result still meets WCAG 2.1 AA for large text (3:1).
It decides; it doesn't guarantee. It picks the better of two options. It can't make a bad background good.

Out of curiosity I checked whether today's engines follow WCAG anyway. In Chromium 153 and in WebKitGTK 2.52, I compared contrast-color() against the WCAG 2.1 "pick the higher ratio" rule on 2,000 random sRGB colors, and the picks matched every time in both. That's a test, not a promise: the spec allows it to change.

The mid-tone trap

Here's the catch MDN warns about: on mid-tones, neither white nor black is great. MDN's own example is #2277d3, a royal blue that gets black text. By the WCAG formula that's 4.65:1 for black and 4.52:1 for white: both technically pass AA for normal text, both are uncomfortable for small type.

There's a hard floor here too. Doing the math with the WCAG luminance formula, the best of black or white can never drop below √21 ≈ 4.58:1. So contrast-color() will never fail AA outright, but on mid-tones it will hover right on that line. The demo shows both ratios live and tells you when you're above 7:1 (AAA) or only just in AA territory. The fix is still a design one: push the background lighter or darker.

Support, fallbacks and one gotcha

Support according to MDN's browser compat data: Chrome 147, Firefox 146 and Safari 26. web-features marks it Baseline newly available since April 10, 2026. I ran the demo in Chromium 153 and WebKitGTK 2.52; I couldn't run Firefox in my environment.

For older browsers, the classic "declare a fallback first" trick has a trap when you use a custom property. This doesn't work the way you'd expect:

.badge {
  color: black;
  color: contrast-color(var(--bg)); /* parses fine because of var() */
}

Because the value contains var(), the browser accepts the second declaration at parse time without checking the function. If it then can't resolve contrast-color(), the property becomes invalid at computed-value time and falls back to the inherited color, not to your black. I tested this in Chromium with a made-up function name and that's exactly what happens. Use @supports instead:

.badge { color: black; }

@supports (color: contrast-color(red)) {
  .badge { color: contrast-color(var(--bg)); }
}

And if you need the same decision in JavaScript (the demo does this as plan B when CSS.supports('color', 'contrast-color(red)') is false), the WCAG 2.1 version is short:

const lin = (v) => (v <= 0.04045 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4);

function luminance(hex) {
  const [r, g, b] = [1, 3, 5].map((i) => lin(parseInt(hex.slice(i, i + 2), 16) / 255));
  return 0.2126 * r + 0.7152 * g + 0.0722 * b;
}

function contrastRatio(a, b) {
  const [hi, lo] = [luminance(a), luminance(b)].sort((x, y) => y - x);
  return (hi + 0.05) / (lo + 0.05);
}

// Same rule as contrast-color(): the one with more contrast wins, ties go to white
function pickTextColor(bg) {
  return contrastRatio(bg, '#000000') > contrastRatio(bg, '#ffffff') ? 'black' : 'white';
}

pickTextColor('#FF5200'); // "black"

What to keep an eye on

The next level of the function. The spec already says more control over the algorithm and the returned colors is expected. If you need brand colors instead of pure black and white, that's where it would show up.
The algorithm itself. Since it's UA-defined and the spec discourages plain WCAG 2.1, a browser could switch to a perceptual model. Mid-tone backgrounds are where you'd notice.
Your own audits. Automated checkers compute WCAG 2.1 ratios. If a browser ever picks differently from WCAG on a mid-tone, the checker and the screen could disagree.

Sources

Originally published at richi.codes.

llms.txt v2: what an agent actually reads

richi.codes — Sat, 24 Oct 2026 07:30:39 +0000

This note has an interactive demo. Try it in the original

The llms.txt proposal got its first big revision in August 2026, and the changes answer the obvious question nobody could answer before: given a page, how does an agent find the llms.txt that describes it? I read the new text, ran this site's own /llms.txt through the small reference parser that lives in the proposal's repository, and it crashed. The demo above shows both things: what a parser really gets out of the file, and how an agent walks from a page to its llms.txt and its Markdown version.

What llms.txt is, in one paragraph

It's a Markdown file that gives agents a curated entry point into a site: a name, a short summary, some context and lists of links to LLM-friendly content. Jeremy Howard published the original in September 2024. It's still a proposal "open for community input", not a W3C or IETF standard. The text is clear about what it's for: robots.txt says what automated access is acceptable, while llms.txt "is instead used on demand, when an agent needs information about a topic while assisting a user". It's meant for inference, not training.

What changed in v2

The Changes page lists four things:

Any path, most specific wins. A file at /docs/llms.txt covers everything under /docs/, and "where more than one file applies, agents should use the most specific one". This is what lets a GitHub Pages project site, which can't touch the host root, take part.
Two Markdown URL forms. v1 only had .md appended (page.html.md). v2 also allows replacing the extension (page.md). URLs without a file name use index.html.md or index.md.
Discovery through link relations. rel="alternate" type="text/markdown" points to a page's Markdown version and rel="describedby" points to the llms.txt that covers it, either as <link> elements or as an HTTP header.
## Optional lost its special meaning. The context-expansion tool from v1 is no longer part of the proposal, so Optional is now just a convention for secondary links.

The header form is the interesting one, because you can add it in your server or CDN config without touching a single page, and it also works on non-HTML files. This is the proposal's own example:

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

And the equivalent in the page's <head>:

<link rel="alternate" type="text/markdown" href="/docs/page.html.md">
<link rel="describedby" href="/docs/llms.txt">

The "How it gets found" tab in the demo builds that header for each page of a small example site. These are the two functions behind it, which I ran in Node with the outputs shown:

// The llms.txt files that cover a path, most specific first.
function coveringLlms(path, files) {
  return files
    .filter(f => path.startsWith(f.slice(0, f.lastIndexOf('/') + 1)))
    .sort((a, b) => b.length - a.length);
}

// page.html -> page.html.md ('append') or page.md ('replace').
function markdownUrl(path, mode) {
  if (path.endsWith('/')) return path + (mode === 'append' ? 'index.html.md' : 'index.md');
  return mode === 'append' ? path + '.md' : path.replace(/\.[^./]+$/, '') + '.md';
}

const files = ['/llms.txt', '/docs/llms.txt'];
coveringLlms('/docs/api/fetch.html', files); // ['/docs/llms.txt', '/llms.txt']
markdownUrl('/docs/api/fetch.html', 'replace'); // '/docs/api/fetch.md'
markdownUrl('/docs/', 'append');                // '/docs/index.html.md'

Untick "/docs/llms.txt exists" and the docs pages fall back to the root file.

The format is stricter than it looks

The proposal says the file is "in a precise format allowing fixed processing methods (i.e. classical programming techniques such as parsers and regex)". In order: an H1 with the name (the only required part), a blockquote with a short summary, zero or more paragraphs or lists with no headings, then H2 sections whose lists hold [name](url) links, optionally followed by : and notes.

The repository still ships a parser of about twenty lines, llms_txt/miniparse.py, and the demo's first tab is a line-for-line JavaScript port of it. I ran both on the same seven files, this site's llms.txt and the proposal's own included, and they return the same result in every case. Here is what I found by feeding it real input:

from miniparse import parse_llms_txt

parse_llms_txt("# My site\n\n> What it is.\n\nOne line of details.\n\n## Docs\n\n- [Guide](https://example.com/guide.md): start here\n")
# {'title': 'My site', 'summary': 'What it is.', 'info': 'One line of details.',
#  'sections': {'Docs': [{'title': 'Guide', 'url': 'https://example.com/guide.md', 'desc': 'start here'}]}}

Every non-empty line in a section must contain a [name](url) link. A line like - GitHub: https://github.com/me raises AttributeError. So does a long list item wrapped onto a second, indented line, because the parser splits sections line by line. This site's /llms.txt does both, which is why the "richi.codes today" example opens in red.
Only the first line of the summary counts. A blockquote spread over several > lines keeps its first line as the summary and dumps the rest into the details.
The summary needs details after it. With nothing between the blockquote and the first ##, the summary comes back as None and the blockquote ends up in info. With only an H1 before the first ##, the parser raises AttributeError. Even the llms.txt in the proposal's own repository comes back with summary: None for this reason.
### also splits. The pattern is ^##, so ### Getting started becomes a section called # Getting started. The spec doesn't allow headings before the first H2 anyway.

An agent reading the file as plain Markdown won't care about any of this. But if a tool parses llms.txt the way the proposal invites it to, these details decide whether your links survive. The "richi.codes fixed" example shows the cheap fix: one line per link, real Markdown links, and a short paragraph after the summary.

What to keep an eye on

Who actually consumes it. The proposal lists documentation platforms that generate the file and says the AI labs publish llms.txt files for their own developer docs. Publishing a file isn't the same as reading one, so check what the agents you care about document before treating llms.txt as a ranking factor.
The Link header. It's the cheapest v2 change to adopt: one line of server config, and agents can go from any page to its Markdown version and its llms.txt.
This site's file. The demo makes it obvious that /llms.txt here has plain-URL list items and wrapped lines. That's worth fixing.

Sources

Originally published at richi.codes.

CSS shape(): responsive shapes without SVG

richi.codes — Fri, 23 Oct 2026 07:30:40 +0000

This note has an interactive demo. Try it in the original

You can now draw a star, a blob or a speech bubble in clip-path with percentages, px, calc() and custom properties, and morph between shapes with a single transition: the CSS shape() function has been Baseline since February 2026.

For years, any clip-path more interesting than circle() or polygon() meant path(), and path() takes an SVG path string where every number is a pixel. That's fine for a fixed-size icon, but it breaks the moment the element resizes: the shape doesn't scale, and you end up recalculating the string in JavaScript. shape() uses the same drawing model as SVG paths, but written in CSS syntax, so each coordinate can be whatever CSS value makes sense.

What shape() is

shape() is a <basic-shape> function, and MDN lists it for clip-path, offset-path and the newer border-shape. It takes a starting point and a comma-separated list of commands:

.triangle {
  clip-path: shape(from 0% 0%, line to 100% 0%, line to 50% 100%, close);
}

The commands mirror SVG path commands, with words instead of letters:

move, line, hline and vline for jumps and straight lines.
curve ... with ... for Bézier curves: one control point gives a quadratic curve, two (separated by /) a cubic one.
smooth for a curve that continues the previous one, arc for elliptical arcs, and close to go back to the start.
to means coordinates measured from the top-left corner of the reference box; by means relative to where the previous command ended.

Percentages are relative to the width and height of the reference box. And according to MDN, this is the real difference from path(): path() is a single string limited to px, while shape() accepts percentages, rem, em and math functions such as calc(), max() or abs().

Mixing units: the responsive bubble

The second tab in the demo above is a speech bubble. The trick is deciding what scales and what doesn't: the corners and the tail are fixed in px, while the box and the tail's position are percentages. Because shape() is just CSS, the values come straight from custom properties:

.bubble {
  --r: 18px; --arrow: 30%; --tail: 16px;
  clip-path: shape(from var(--r) 0,
    hline to calc(100% - var(--r)),
    curve to 100% var(--r) with 100% 0,
    vline to calc(100% - var(--tail) - var(--r)),
    curve to calc(100% - var(--r)) calc(100% - var(--tail)) with 100% calc(100% - var(--tail)),
    hline to calc(var(--arrow) + var(--tail)),
    line to var(--arrow) 100%,
    line to calc(var(--arrow) - var(--tail)) calc(100% - var(--tail)),
    hline to var(--r),
    curve to 0 calc(100% - var(--tail) - var(--r)) with 0 calc(100% - var(--tail)),
    vline to var(--r),
    curve to var(--r) 0 with 0 0,
    close);
}

Read it as a walk around the edge: top edge, a quadratic curve for the top-right corner (the control point is the corner itself), down the right side, the bottom-right corner, along the bottom to the tail, down to the tip at 100% and back up, and the same on the left. Drag the width slider in the demo and the corners stay round instead of turning into ellipses, because their radius is in px. The spec itself uses a speech bubble like this one to explain why mixing units matters.

The sliders don't rebuild the string: they only change --r, --arrow and --tail with style.setProperty(). The browser redraws the shape.

Morphing for free

The first tab is the part that catches the eye. The specification says that two shape() values (or a shape() and a path()) can be interpolated if their command lists are the same length and have the same commands in order. A command counts as "the same" if it uses the same keyword and the same by/to, and for curve and smooth the same number of control points.

So if you design every shape with the same skeleton, a transition does the morph:

.badge {
  clip-path: shape(from 0% 0%, line to 100% 0%, line to 100% 100%, line to 0% 100%, close);
  transition: clip-path .6s ease;
}
.badge:hover {
  clip-path: shape(from 50% 0%, line to 100% 50%, line to 50% 100%, line to 0% 50%, close);
}

In the demo, the circle, the star, the flower and the random blob are all twelve curve to X Y with CX CY commands generated from polar coordinates. The star simply puts each control point halfway along the segment, so the curve looks straight. Since the skeleton never changes, any shape morphs into any other.

I checked the flip side in Chromium too: if I replace one of the line commands in the hover state with a curve, the transition stops interpolating and the shape jumps straight to the final value.

Support and gotchas

According to MDN's compatibility data, shape() is supported in Chrome and Edge 135, Firefox 148 and Safari 18.4. It became Baseline newly available on 24 February 2026, so it's not yet "widely available". For older browsers, feature detection is straightforward:

@supports not (clip-path: shape(from 0 0, line to 100% 0, line to 0 100%, close)) {
  .badge { clip-path: polygon(0 0, 100% 0, 100% 100%, 0 100%); }
}

The demo uses the same check in JavaScript with CSS.supports(). If it fails, it falls back to path() with pixel values computed from the element's size and recalculated with a ResizeObserver. That's exactly the work shape() saves you. You can see the fallback by adding ?fallback to the demo's URL.

Things to keep in mind:

clip-path only clips. Shadows and borders are clipped too, so the glow in the demo is a filter: drop-shadow() on the parent, which follows the clipped shape.
Computed values keep the units you wrote: getComputedStyle() returns something like shape(from 0px 0px, hline to calc(100% - 20px), ...), which helps when you're debugging.

What to keep an eye on

border-shape: it accepts shape() too, but in MDN's compatibility data it only appears in Chrome 147. It's the piece that would let you shape the border as well, not just clip the element.
Relative control points: the spec defines from start, from end and from origin for control points. MDN's examples use them behind their own @supports check, so test them in every browser before relying on them.
Converting existing paths: if you already have an SVG d string, the translation to shape() is mechanical (M → from/move, L → line, Q/C → curve, Z → close), and that's when you can swap pixels for percentages.

Sources

Originally published at richi.codes.

CSS Custom Highlight API: style text without spans

richi.codes — Thu, 22 Oct 2026 07:30:40 +0000

This note has an interactive demo. Try it in the original

You can paint any piece of text on a page without wrapping it in a <span> or a <mark>: the CSS Custom Highlight API has been Baseline since March 2026, when Firefox 149 shipped the last missing piece, the ::highlight() pseudo-element.

Type something in the demo above. Every match turns orange, but keep an eye on the middle counter: the number of DOM nodes inside the text doesn't move. Start the read-along or flag the typos and it still doesn't move. In a browser without the API, the demo falls back to real <mark> elements and you can watch that counter grow and turn orange.

Why this matters

The classic way to highlight search results is to rewrite the HTML: split text nodes, wrap the matches in elements, and undo it all on the next keystroke. It means extra elements in the DOM on every keystroke, and it gets messy fast when two highlights need to overlap.

MDN describes the API as a way to style arbitrary text ranges by "using JavaScript to create the ranges, and CSS to style them". It extends the idea behind the highlight pseudo-elements the browser already had (::selection, ::spelling-error, ::grammar-error, ::target-text) to ranges you define yourself. Typical uses: search in page, spell and grammar checkers, code editors, collaborative editors with one colour per user.

How it works

Four steps: create Range objects, group them in a Highlight, register it by name in CSS.highlights, and style that name with ::highlight().

const p = document.querySelector('p');
const text = p.firstChild; // a text node

// 1. A Range for every match
const ranges = [];
let i = text.textContent.indexOf('ranges');
while (i !== -1) {
  const range = new Range();
  range.setStart(text, i);
  range.setEnd(text, i + 'ranges'.length);
  ranges.push(range);
  i = text.textContent.indexOf('ranges', i + 1);
}

// 2 and 3. One Highlight holds them all; the registry gives it a name
CSS.highlights.set('search', new Highlight(...ranges));

/* 4. Only the name is shared between JS and CSS */
::highlight(search) {
  background-color: #FF5200;
  color: white;
}

That's the whole trick in the demo's search box: on each input event it walks the text nodes with a TreeWalker, builds the ranges and calls CSS.highlights.set() again. CSS.highlights is a Map-like registry, so delete(name) and clear() remove highlights, and a Highlight is Set-like, with add(), delete() and size.

The read-along button uses the same idea with a single range that moves to the next word every 280 ms. The typos button registers a third highlight and sets its type:

const typos = new Highlight(...typoRanges);
typos.type = 'spelling-error'; // default is 'highlight'; 'grammar-error' also exists
CSS.highlights.set('typo', typos);

According to MDN, type lets assistive technologies include that meaning when they expose the highlight, although support "may vary across platforms".

When highlights overlap

In the demo the search can overlap the read-along word. Which colour wins is not decided by CSS order or !important: it's decided by Highlight.priority. With equal priorities, the most recently registered highlight wins for the conflicting properties. The demo gives the search priority = 1, so orange stays on top. Properties that don't conflict are all applied.

What you can style

::highlight() only accepts a short list of properties: color, background-color, text-decoration and its longhands, text-shadow, and -webkit-text-stroke-color, -webkit-text-fill-color and -webkit-text-stroke-width. background-image is ignored, so no gradients. The wavy red underline in the demo is plain text-decoration: underline wavy.

Browser support and gotchas

Support: Chrome and Edge 105, Safari 17.2, Firefox 149 for the full feature. Firefox had the JavaScript side (Highlight, CSS.highlights) from 140, but ::highlight() couldn't use text-decoration before 146 or text-shadow before 149.
Detect it: 'highlights' in CSS is the basic check. The demo checks that and typeof Highlight === 'function', shows a warning and falls back to <mark> elements.
Safari and user-select: none: browser-compat-data notes that in Safari the highlight style is ignored when combined with user-select: none (WebKit bug 278455). Don't put highlights on text you've made unselectable.
No semantics by default: MDN is clear that custom highlights don't add semantic meaning to the document; type only covers spelling and grammar errors, and support for it varies. If the highlight carries meaning a screen reader user needs, MDN suggests semantic HTML such as <mark> or another accessible cue.
Ranges point at text nodes. If your framework re-renders and replaces those nodes, recompute the ranges. The demo's fallback does exactly that after each reset.

What to keep an eye on

Older Firefox: until your audience is on 149+, test text-shadow and text-decoration there, or stick to color and background-color.
Accessibility: use type where it fits, and don't rely on colour alone for meaning.
Editors and search: in-page search, spell checking and collaborative cursors are the obvious places where this replaces a lot of DOM juggling.

Sources

Originally published at richi.codes.

DEV Community: richi.codes

CSS alpha(): one brand color, every transparency

Why this needed its own function

How it works

Seeing the color space difference

Browser support and gotchas

What to keep an eye on

Sources

Intl.Segmenter: split text without breaking emoji

Why split("") lies to you

What Intl.Segmenter does

The split-text animation, done right

Finding the segment at a position

Support and gotchas

What to keep an eye on

Sources

CSS gap decorations: lines between grid items

What gap decorations are

The code the demo uses

Breaks, empty cells and insets

Support and gotchas

What to keep an eye on

Sources

Scroll anchoring is Baseline: content stops jumping

What scroll anchoring does

The code: it's on by default

The fallback, if you need one

Gotchas I hit or checked

What to keep an eye on

Sources

CSS style queries: one variable, every style

What problem it solves

How it works

The gotcha: plain matching compares tokens

Browser support and other gotchas

What to keep an eye on

Sources

CSS light-dark() now swaps images, not just colors

Why this matters

How it works

The gotcha that cost me a layer

Browser support

What to keep an eye on

Sources

View Transitions: animate any DOM change with one call

What it is and why it matters

How the demo works

Gotchas I hit or checked

Browser support

What to keep an eye on

Sources

CSS field-sizing: inputs that grow as you type

What it is and why it matters

How it works

The gotchas

Browser support

What to keep an eye on

Sources

CSS contrast-color(): text that picks its own color

What it is and why it matters

How it works

The mid-tone trap

Support, fallbacks and one gotcha

What to keep an eye on

Sources

llms.txt v2: what an agent actually reads

What llms.txt is, in one paragraph

What changed in v2

The format is stricter than it looks

What to keep an eye on

Sources

CSS shape(): responsive shapes without SVG

What shape() is

Mixing units: the responsive bubble

Morphing for free

Support and gotchas

What to keep an eye on

Sources

CSS Custom Highlight API: style text without spans

Why this matters

Why `split("")` lies to you