Your design system is probably behind the browser.

Bootcamp - Medium，Bootcamp 是 Medium 上关于 UX、UI、产品设计与设计思维的出版物。关注

Chrome now ships a new major version every two weeks.

Design Systems

Recently I wrote about light-dark(), something that’s native to browsers now and really helps with dark mode, which required a lot more work before. These days I keep discovering new capabilities like this every week. It’s happening fast. And I’m not sure this is good for the design system I created and maintain at my company. I don’t update it fast enough, yet I want to keep it fresh and capable. It’s a problem. Or is it?

Chrome moved from a four-week to a two-week release cycle. It started with Chrome 153 on 8 September 2026. Chrome 154 followed on 22 September, and 155 is due on 6 October. Three versions in four weeks. In a year, that’s 26 releases instead of 13.

Google’s reasoning?

If a feature missed the release cutoff by a day, it used to wait another month. Now it doesn’t.

And the releases aren’t bigger or riskier. They’re smaller, so each one disrupts less. And it’s not only Chrome either. Google says Microsoft, Mozilla and Brave are moving the same way.

Most design systems I’ve seen move every quarter, at best. The browser now moves every fortnight.

So what shipped in a month?

Chrome 154, text-decoration-inset. Animated underline reveals with plain text decoration, instead of background gradients or extra elements.
Replaces: the underline hack every design system has.

Chrome 154, responsive iframes. An iframe sizes itself to the embedded document, so there’s no scrolling inside it.
Replaces: fixed iframe heights and resize scripts.

Chrome 155, margin-trim. Removes margins before or after the first or last child of a container.
Replaces: the :last-child { margin-bottom: 0 } fix in every stack component.

A visual refresh that turned into a rebuild

I’m currently in the middle of a major update to our design system. It started with a redesign in Figma. I redesigned one of our apps, and based on that work we decided to update our existing design library.

The redesign was a visual refresh, but it opened a chance to update our CSS and performance too. That wasn’t the original aim. It happened because we changed the way we work. Instead of a big team, there are two of us: our senior developer, who reviews the code, and me, a designer who ideates and pushes code at the same time.

I use AI to code. We have a markdown file of rules that grows with every learning. AI suggests approaches we hadn’t considered. We look at each one and decide whether we want it. Most of the time we do, and by using it we learn, and the quality and performance of our code improves. That was an unexpected side effect of what was meant to be a visual update.

It also reshaped our process. We don’t do sprints. We build and release when something is ready and when we have time. We treat design system updates as continuous rather than scheduled. It goes against how we were taught to work, but it freed us from processes that no longer suited us. Nobody told us this would be better. We found out through trial and error.

Along the way, we stripped out a lot of hand-coded behaviour and leaned on what the browser already does. We moved dark mode to light-dark(), so the browser handles the switching instead of our duplicated theme files. We moved our colours to OKLCH, so the browser does the perceptual maths we used to adjust by hand. Separately, we brought in a lot of shadcn thinking and components.

There’s no reason to build behaviour the browser already has. Instead, we spend our time on choices: type, colour, brand. The only worry is that when we release it, two weeks later it’s already slightly behind.

Should you even try to keep up?

The temptation is obvious. You want your design system to use everything the browser can now do natively, the moment it can do it. Especially if, like us, you don’t have a dedicated design system team, falling behind feels like it’s only a matter of time.

But not everything Chrome ships is ready for everyone. Some of it is Chromium-only for now. corner-shape, for example, reaches about 65% of users. The good news is that a lot of these features degrade gracefully. If the browser doesn’t support corner-shape, people simply get normal rounded corners. Nothing breaks. The features that replace behaviour are different. Those need a fallback until every browser catches up.

And most releases barely touch a design system at all. Chrome 154 had three changes that mattered to us. Some releases have none.

We already release whenever something is ready, so for us the question was never really how often to ship. It’s how to keep track, and what to adopt when.

So yes, changes are fast. But adoption takes time.

What I’m changing instead

Since we already release whenever something is ready, I don’t need a new release schedule. What I need is a better way of noticing.

So I’ve added a small habit. Every time a new Chrome version lands, which is now every two weeks, I go through the “New in Chrome” post and compare it against our component list. AI does the first pass. It reads the release notes, looks at our components and flags anything that could replace something we built by hand. Then I decide. That’s the same split I wrote about in my piece on staying relevant: AI does the grind, I make the call.

Everything it flags goes into one of three lanes:

Enhance anytime. Cosmetic features that degrade gracefully, like corner-shape or text-decoration-inset. If a browser doesn’t support them, people just see the old version. These can go into any release.

Replace on Baseline. Features that remove behaviour we coded ourselves, like anchor positioning, field-sizing or light-dark(). These wait until every major browser supports them, because replacing working code with something some of your users can’t run is a step backwards.

Watch. Things that aren’t ready yet, like the customizable select. They stay on the list until they are.

That’s it. No extra meetings, no new process. A short check every two weeks and a decision about where each thing belongs.

It also means the design system is never perfectly current. But it’s never far behind either, and nothing goes in before it’s ready for the people actually using our product.

What the browser already handles

As of October 2026:

Baseline: works in all major browsers

  • light-dark(): switches a colour between light and dark themes, no media queries or duplicate variable blocks. Baseline 2024.
  • color-scheme: native controls and scrollbars follow the theme. Widely available.
  • Anchor positioning (anchor-name, position-anchor, position-area): tethers a tooltip or menu to its trigger. Baseline since Firefox 147 in January 2026.
  • Popover API: show, hide and light-dismiss overlays in the top layer. Pairs with anchor positioning.
  • Invoker commands: buttons open and close popovers and dialogs without script. Chrome 135, Safari 18.4, Firefox 144.
  • @starting-style: entry animations for elements as they appear.
  • details name and ::details-content: accordions where one panel opens at a time, with a styleable, animatable panel.
  • field-sizing: content: inputs and textareas grow to fit what’s typed. Baseline since Firefox 152 in June 2026.
  • contrast-color(): picks readable text against any background. Baseline April 2026. Black or white only.
  • shape(): responsive clip shapes in CSS units, replacing SVG paths. Baseline February 2026.
  • Same-document View Transitions and scrollbar-color: animated state changes and styled scrollbars. Both Baseline in late 2025.

Chrome-led: not Baseline yet

  • Customizable select (appearance: base-select): a fully styleable native dropdown. Chromium-only as of mid-2026.
  • corner-shape: squircles, bevels, scoops, notches. Chromium-only, about 65% of users.
  • CSS carousels: native scroll buttons and markers. Chrome 150, Safari 26.6 expected.
  • text-decoration-inset: animated underline reveals without gradients or extra elements. Chrome 154.
  • frame-sizing: an iframe sizes itself to its content. Chrome 154.
  • margin-trim: drops margins on the first or last child of a container. Chrome 155, due 6 October.
  • text-box-trim: removes the invisible space above and below text. Chrome 133, Safari 18.2, not Firefox.

So, are design systems dead?

I hear far too often that design systems are dead. They aren’t. It’s just another clickbait title. If anything, the work I described above made ours more useful, not less.

What’s disappearing is a slice of it. The part that existed because the browser couldn’t do something. The tooltip positioning, the theme switching, the textarea that grows as you type. The browser is taking those mechanics off our plate, and I’m happy to hand them over.

But that was never why we built design systems in the first place.

We built them so the same button looks and behaves the same everywhere, across every screen and every team. So designers and developers call things by the same names. So nobody rebuilds a modal from scratch. So brand, spacing, colour and type get decided once, in one place, instead of in every meeting. So focus, keyboard behaviour and contrast are built in, and each team doesn’t get them wrong in its own way. And so there’s a clear answer to what’s allowed and what isn’t.

None of that came from a CSS limitation. None of it goes away because Chrome ships faster.

AI makes it matter more, not less. Our markdown rules file is, in a way, a design system for the AI. It tells it what we’ve already decided so it doesn’t invent something new every time. Without it, AI would happily generate a different button on every screen. O’Reilly recently described the design system as the control plane for AI-generated UI, and that matches what I see every day. The components get thinner. The decisions get more important.

So the browser takes the mechanics. The hard part, the decisions, was always ours. But we can only hand over the mechanics if we know the browser can do them.

What goes stale every two weeks isn’t the design system. It’s our picture of what the browser can do.

References

Chrome’s release cycle

What shipped

Browser support

Documentation

Design systems and AI

Your design system is probably behind the browser. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论