Cleared

Delete your text-stroke hack

Mon, 05 Oct 2026 00:00:00 GMT

Safari 27 shipped on the 14th and made more features newly available in one day than the rest of the month did. Most of them are JavaScript features though. On the CSS front, it’s a mixed bag: light-dark() image support is ready, but scroll anchoring (which Chrome and Firefox have done for years) is not, and neither is the new alpha() function. Firefox completed progress() but Chrome holds it back. The deletion this month is paint-order, which retires the duplicate text hack to draw a stroke behind a headline.

01. `paint-order`

Verdict: Cleared · Safe everywhere as of September 22, 2026

Text fill is painted first, then the stroke, on top. A stroke is centered on the outline of the letter, so half of it covers the fill: a 6px stroke is 3px into the text and 3px outside. Using paint-order: stroke paints the stroke first and the fill over it. The fill covers the inner 3px, so the letter keeps its full shape and what you see is a 3px outline. The stroke itself comes from -webkit-text-stroke. (The prefix is part of the property’s name in every browser. No unprefixed form exists.) SVG has had the property for years, and Chrome 123 was the last browser to extend it to HTML text, in March 2024, 30 months before this September.

Delete: the second copy of the text that draws the stroke behind the real one, usually a pseudo-element.

CSS · before after

−/* the text twice, with the stroke on the copy behind */
−.title { position: relative; z-index: 0; }
−.title::before {
−  content: attr(data-text);
−  position: absolute; inset: 0; z-index: -1;
−  -webkit-text-stroke: 6px white;
−}

+.title { -webkit-text-stroke: 6px white; paint-order: stroke; }

Failure is graceful: a browser without the property paints the stroke on top, and the outline looks thinner. Firefox’s summary score on this feature is low, but none of what it fails is relevant to stroked HTML text. The stroke sits behind the fill in Firefox too.

02. Scroll anchoring

Verdict: Hold · Not yet

When something above the part of the page you are reading changes size, an image loading for instance, the content under your eyes jumps. Scroll anchoring is how browsers manage this issue: they pick an element in view as the anchor, and when content above it grows or shrinks, they move the scroll position by the same amount. Chrome has done this since 2017 and Firefox since 2019. Safari 27 is the last to join, and overflow-anchor: none switches it off.

Baseline’s score for Safari is 1 but it measures the wrong thing: the tests that check the property’s syntax and the opt-out pass, but the tests of the anchoring itself are where Safari 27 falls short. When text above rewraps, Safari does not adjust, and inside a scrolling element rather than the page, it misplaces the anchor when content above it shrinks. So keep the code that restores the scroll position after you insert content above the fold. And if you have a custom scroller in your code, put overflow-anchor: none on it so the browser leaves it alone. Chrome and Firefox already needed that. Safari 27 onward does too.

CSS

/* Works in Safari 27: a block above the viewport grows.
   Fails in Safari 27: the text above rewraps, or a scrolling
   div loses content above the anchor. */

/* Where you manage a scroller's position yourself */
.log { overflow-anchor: none; }

03. `progress()`

Verdict: Hold · Not yet

progress(value, start, end) returns how far a value sits between two others, as a plain number from 0 to 1. It replaces the ratio you compute by hand in calc(), with one difference: the result is clamped between 0 and 1 unless you add the no-clamp keyword.

Firefox 155 completed support on September 1. Chrome is the blocker. Version 154 accepts the plain form and little else: it rejects no-clamp, which Firefox 155 and Safari 27 both accept; it rejects a percentage mixed with lengths, progress(50%, 0px, 100px); and when start equals end and the value sits above them, it returns 1 where the spec says 0.

CSS

/* The ratio by hand. It can go below 0 or above 1 */
opacity: calc((var(--value) - var(--min)) / (var(--max) - var(--min)));

/* The same ratio, clamped to 0 to 1 unless you say otherwise */
opacity: progress(var(--value), var(--min), var(--max));

/* Chrome 154 ignores both of these */
opacity: progress(no-clamp 150, 0, 100);
margin-left: calc(progress(50%, 0px, 100px) * 10px);

04. `light-dark()` image values

Verdict: Cleared · New this month, September 14, 2026

light-dark() takes two values and uses the first in a light color scheme and the second in a dark one. Until now it took only colors. It now works with images too. Firefox has had this since April and Chrome since June. Safari 27 completed the set.

Delete: the per-theme override rule that swaps an image.

CSS · before after

−/* one rule per theme */
−.logo { background-image: url(light.svg); }
−.dark .logo { background-image: url(dark.svg); }

+/* one declaration. (The first line is the fallback) */
+.logo {
+  background-image: url(light.svg);
+  background-image: light-dark(url(light.svg), url(dark.svg));
+}

Every current browser passes the tests. Make sure you keep the fallback for earlier browsers.

05. `alpha()`

Verdict: Hold · Not yet

alpha(from <color> / <alpha>) takes a color and returns it with a different opacity and nothing else changed. It is the short form of relative color syntax: alpha(from var(--accent) / 50%) instead of rgb(from var(--accent) r g b / 50%). Chrome shipped it in August, Firefox on September 1, and Safari 27 completed the set on September 14.

All three implementations are a few weeks old, and past the plain case they differ. For alpha(from red / 50%) every browser produces the same color. Beyond that, Safari and Chrome fail a good share of the tests, mostly on how the result reads back from JavaScript, and Safari turns an alpha of none into zero. And the draft is still moving. In the current editor’s draft the alpha part is optional, so alpha(from red) is valid, which Chrome and Safari accept and Firefox and the tests reject. Wait a release or two. The long form does the same job today.

CSS

/* The long form you may already write */
color: rgb(from var(--accent) r g b / 50%);

/* The short form. The same color in every current run */
color: alpha(from var(--accent) / 50%);

/* Safari 27 makes this fully transparent */
color: alpha(from var(--accent) / none);

That was September: one deletion, one declaration to start using, and three features that the label calls ready and the tests do not.

Delete your declarative shadow DOM polyfill

Mon, 14 Sep 2026 00:00:00 GMT

Two features became newly available in August, both CSS, and both are Holds. One because Safari and Firefox are behind Chrome on it. The other because the label says every browser has shipped it, and Chrome has not. One feature finished its 30 months of support, Declarative shadow DOM, and it retires a script you may still be loading on every page.

01. Declarative shadow DOM

Verdict: Cleared · Safe everywhere as of August 20, 2026

A web component keeps its internal markup and styles in a shadow root, and until recently the only way to create one was from JavaScript, by calling attachShadow(). Declarative shadow DOM lets you write the shadow root in the HTML instead. Put a <template shadowrootmode="open"> inside an element, and the browser turns it into that element’s shadow root while it parses the page. A server can send a component fully rendered, and it looks right before any script has loaded.

Delete: the script that finds every <template shadowrootmode> and attaches its shadow root by hand. Keep it only for components that are HTML only, with no JavaScript to render them.

JS · before after

−/* the polyfill, on every page */
−document.querySelectorAll('template[shadowrootmode]').forEach((t) => {
−  const mode = t.getAttribute('shadowrootmode');
−  t.parentNode.attachShadow({ mode }).append(t.content);
−  t.remove();
−});

+/* the parser already did this */

One more thing to check before deleting. The browser only creates these shadow roots when it parses HTML as the page loads. If your JavaScript builds the same markup later and inserts it with innerHTML, nothing happens: the <template> stays a plain template and no shadow root is created. This is deliberate. The spec disables declarative shadow roots for innerHTML, and the test suite confirms it for every HTML element. So check your code for any innerHTML that inserts markup containing shadowrootmode. For those, either switch to setHTMLUnsafe(), a newer method that does create the shadow roots, or keep the polyfill for that one call.

Every test that matters for this deletion passes in all five current stable runs. The few misses are a newer attribute Safari has not shipped and two document.open() edge cases.

HTML-only components are the one case to keep the polyfill for because they break completely in browsers without this feature. The <template> is ignored and the component’s internal markup never appears.

02. `sibling-index()` and `sibling-count()`

Verdict: Hold · Not yet

Two new CSS functions. sibling-index() gives an element’s position among its siblings, starting at 1, and sibling-count() gives how many siblings there are. Both return plain numbers you can use in calc(). If all you want is a staggered animation on a list that does not change, this works today. Anything beyond that, wait.

CSS

/* Works in every current run */
li { animation-delay: calc(sibling-index() * 80ms); }

/* Fails in Safari 26.6: the index inside a gradient */
li { background: linear-gradient(blue calc(10px * sibling-index()), yellow); }

/* Fails in Firefox 155 and Safari 26.6: the index inside @keyframes
   stops updating when a sibling is removed */
@keyframes rise { from { z-index: sibling-index(); } }

Firefox 154 shipped the last piece on August 18, and the simple uses work everywhere: the index or the count inside calc(), on the element itself, on ::before, on the root. The trouble starts when the index is read somewhere other than a plain declaration. Safari 26.6 passes only three of the suite’s 22 tests whole. It fails when the index is used in a gradient, in a container query, or inside a shadow tree. Both Safari 26.6 and Firefox 155 fail when the index is used inside @keyframes and the list then changes: remove an element before the animated one, and the animation keeps the old position number instead of updating. Outside keyframes, the same removal updates correctly in every browser.

03. Media element pseudo-classes

Verdict: Hold · Not yet

Seven CSS pseudo-classes that match a <video> or <audio> element by what it is doing: :playing, :paused, :seeking, :buffering, :stalled, :muted and :volume-locked. If you have built a custom player, you probably listen for the play and pause events and toggle a class like is-playing so the CSS can swap the button. These pseudo-classes replace the need for that listener, but keep it for now. Chrome has not shipped this feature, whatever the label says.

CSS

/* The deletion waiting here */
.player.is-playing .play-button { display: none; }

/* Blocked by Chrome, for now */
.player:has(video:playing) .play-button { display: none; }

Baseline says Chrome 152 shipped these on August 25, which is what made the feature newly available on August 28. That date comes from a single entry in the browser compatibility data, and it is wrong. Chrome’s own status tracker lists the feature as proposed, with a shipping target of Chrome 155. Every stable Chrome run since 152 fails all six checks in the test suite: a video whose outline should turn green when it plays never changes, and :playing, :seeking and :muted never match through :has(). Edge fails the same way. Firefox 155 and Safari 26.6 pass everything, and so does Chrome’s pre-release channel, so the implementation exists. It is just not in the browser most of your visitors are running.

That was August: one polyfill to delete, one new feature to wait on, and one feature that Baseline says is ready but Chrome has not shipped.

AVIF cleared: one fallback can go

Mon, 03 Aug 2026 00:00:00 GMT

July was thin. One feature arrived in the whole month, a JavaScript locale API outside the CSS and HTML this publication covers, and three crossed 30 months, all that a quiet January 2024 had set in motion. Two of the three ask nothing of you. The third is AVIF, and it retires one of your image fallbacks.

01. AVIF

Verdict: Cleared · Safe everywhere as of July 25, 2026

The AV1 image format. Chrome has decoded it since 2020; Edge completed the core set on January 25, 2024, and the 30-month clock ran out on July 25. If your images ship as a three-format stack, AVIF on top, WebP in the middle, JPEG at the floor, the middle is now dead weight.

Delete: the WebP sources in your <picture> elements, and the encode step that produces them.

HTML · before after

−<source srcset="chart.avif" type="image/avif">
−<source srcset="chart.webp" type="image/webp">
−<img src="chart.jpg" alt="Monthly revenue">

+<source srcset="chart.avif" type="image/avif">
+<img src="chart.jpg" alt="Monthly revenue">

A browser takes the first source whose type it supports, and every browser in the core set now takes the AVIF. The browsers still outside the set never reached the WebP for its format; they needed a floor they could render, and that is the JPEG’s job. What the WebP bought them was bytes: without it they download the same picture, heavier. That is the whole cost of the deletion, and it falls on a shrinking audience.

The floor stays. AVIF sits at about 93% of global traffic on caniuse’s counters, so a bare .avif in src with no fallback is a broken image for about one visitor in fifteen: desktop Safari before 16.4, iOS before 16.1, and every browser too old to have met the format. A missing image does not degrade, it is simply absent. Delete the middle of the stack, never the bottom.

Most sites never built this stack. In the HTTP Archive’s 2024 almanac, about one image in eight was a WebP and about one in a hundred an AVIF, and a <picture> that switches on format appeared on a few pages in a hundred. Search your templates for type="image/webp": if nothing comes back, or the floor under your sources is itself a .webp, there is no middle to delete and nothing to do this month.

One number needed a look before this verdict could ship. webstatus.dev scores stable Firefox at 0 on AVIF’s tests. The suite behind that number is two rendering tests, and ordinary still-image decoding is in neither: one advances an animated AVIF to its second frame, the other renders a file carrying a progressive-rendering flag. Firefox currently fails both. For a static image stack, the deletion above, they say nothing. If you ship animated or progressively encoded AVIF, test those files in Firefox before leaning on them.

Nesting cleared: delete a build step

Mon, 06 Jul 2026 00:00:00 GMT

June was a deletion month. A single Firefox release produced exactly one new arrival, while sixteen features quietly finished their 30 months of support. The best of them is nesting: your CSS can nest itself now, and a build step can go.

01. Nesting

Verdict: Cleared · Safe everywhere as of June 11, 2026

CSS rules can nest inside other rules, natively.

Delete: the build step that exists only to expand nesting. The source stays as written.

One difference to know about. A nested rule resolves the way :is() does: & takes the specificity of the most specific selector in the parent list. A preprocessor expands the same source into a plain selector list, where each branch keeps its own.

CSS

#a, b {
  & c { color: blue; } /* & is [1,0,0] for both, so [1,0,1] */
}

/* Your build step expanded that to: */
#a c { } /* [1,0,1], same */
b c  { } /* [0,0,2], weaker than the native version */

The two agree until a parent selector list mixes specificity levels. Before switching, search your source for comma-separated parent selectors containing an ID.

02. Lazy-loading images and iframes

Verdict: Cleared · Safe everywhere as of June 19, 2026

loading="lazy" defers offscreen images and iframes until the user scrolls near them.

Delete: the lazy-loading script and its data-src markup.

HTML · before after

−<img data-src="chart.png" class="lazyload">
−<script>/* a script you no longer need */</script>

+<img src="chart.png" loading="lazy">

The core image and iframe cases pass their tests in every browser. What still fails anywhere is edge cases: an image whose URL is changed repeatedly from script, base-URL changes mid-load, lazy iframes during unusual navigations. Keep the image at the top of the page eager; deferring what is already on screen only delays it.

03. `:has()`

Verdict: Cleared · Safe everywhere as of June 19, 2026

The parent selector: style an element by what it contains. It appears on about one in two hundred page loads.

Delete: the JavaScript that watches children and toggles state classes on their parents.

CSS · before after

−/* a script adds .has-error to the form */
−form.has-error { border-color: firebrick; }

+form:has(input:invalid) { border-color: firebrick; }

One boundary, from Safari’s current test run. Parent, ancestor, adjacent and sibling positions all match Chrome exactly: 211 of 211, 337 of 337, 295 of 295, 295 of 295. The gap is re-matching while a script inserts and removes siblings: 14 of 28. If a :has() rule watches a sibling list under live mutation, keep the class for that one case.

04. `field-sizing`

Verdict: Cleared · New this month, June 16, 2026

field-sizing: content makes inputs and textareas grow and shrink with what is typed. June’s only new arrival, completed by Firefox 152.

Delete: the textarea autosize script, on new work.

CSS

textarea {
  field-sizing: content;
  min-height: 4rem;
  max-height: 16rem;
}

A textarea that grows as you type, which is what this deletion is about, works in every current browser run. The misses are all at the edges: Firefox fails to re-fit a number input after a script changes its value, Chromium gives a disabled empty textarea more than one line of height, and Safari draws a search input’s caret taller than its placeholder. A month of Baseline means some of your users are still catching up, and for them the failure is the one you already ship: a fixed-size box with a scrollbar.

Correction, August 27, 2026: was Hold, now Cleared. I read the -svg in mask-repeat-1-svg, -2-svg and -3-svg as naming the mask source. It names the masked content. Delete your fallback when masking an HTML element (most common) but keep it when masking SVG content, or where a mask stacks more than one layer, or when you use mask-clip, mask-origin, mask-composite or mask-mode, all of which Safari 26.6 still fails.

05. Masks

Verdict: Hold · Not yet

CSS masks crossed 30 months of support on June 7, and appear on about 0.4% of page loads. The label says delete your fallbacks. The tests say not yet.

In Safari 26.5.2’s current run, masks repeat correctly from a raster image and fail the same three tests when the mask source is an SVG: mask-repeat-1-svg, -2-svg and -3-svg. Chrome passes all six. An SVG source is the common case, and a mask that fails to apply does not degrade: it reveals or hides the wrong thing. Keep whatever fallback you have until Safari’s SVG path catches up.

Delete your form’s touched classes

Mon, 08 Jun 2026 00:00:00 GMT

Seven features became newly available in May, and five finished their 30 months of support. Four of the seven arrivals were old features that had been waiting on Chrome or Chrome Android; desktop Chrome has had shared workers since 2010, and Chrome Android shipped them this May. The thing worth deleting is in your forms.

01. `:user-valid` and `:user-invalid`

Verdict: Cleared · Safe everywhere as of May 2, 2026

Validity pseudo-classes that wait for the user. They match like :valid and :invalid, but only once the field has been altered, so a pristine required field stays quiet. A submit attempt counts as interaction too.

Delete: the script that listens for blur and input events just to add a “touched” class, so error styles don’t fire before the user has typed anything.

CSS · before after

−/* a script marks fields the user has visited */
−input.touched:invalid { border-color: firebrick; }

+/* the browser tracks interaction itself */
+input:user-invalid { border-color: firebrick; }

The core suite passes in every current stable run. One edge is unsettled: when these flip mid-edit inside multi-part fields like date inputs is covered only by a test still marked tentative, and Chrome is currently the only engine passing it. If your validation styling leans on the exact timing inside date or time inputs, keep the class for those. In a browser too old to have these, the rule never matches: no inline highlighting, not a broken form.

02. `lh` unit

Verdict: Hold · Not yet

One line-height, as a unit: 3lh is three lines tall. It crossed 30 months of support on May 21, and the deletion it promises is every magic number that hard-codes a line-height multiple.

CSS

/* The deletion waiting here: */
.toast { min-height: calc(3 * 1.4em); } /* hoping 1.4 still matches */

/* Blocked by Safari, for now: */
.toast { min-height: 3lh; }

The blocker is specific. Safari 26.5’s current run fails the suite’s inherited-line-height test: an element whose line-height arrives from its parent, which is how line-height usually arrives, resolves 1lh against the wrong value. The other eight tests pass there, and Chrome, Edge and Firefox pass everything. Until that fix ships, the magic number is more predictable than the unit that replaces it. Its root-relative sibling rlh cleared the same day and appears on about one page load in three million.

03. Container style queries

Verdict: Hold · Not yet

Style queries let a component ask what a custom property is set to on its container. Firefox 151 shipped the last piece on May 19, so the label now says Baseline. The label covers more than the browsers agree on.

CSS

@container style(--density: compact) { } /* passes everywhere */

@container style(--columns > 2) { } /* fails in every engine */

The equality form passes its tests in the current Chrome, Edge, Firefox and Safari runs. The range form is another story: every engine passes 1 of the 7 dynamic range tests, Firefox included, and Firefox is the browser that just shipped the last piece. If you treat the equality form as a progressive enhancement, nothing stops you today. The Hold is for the feature as labeled, because the label does not tell you which half is broken.

That was May: one deletion, and two labels running ahead of their implementations.

Delete your role="search" wrapper

Mon, 04 May 2026 00:00:00 GMT

A thin month, and a backwards one. Baseline’s rhythm is usually set by Safari, the browser that ships least often. April’s two arrivals were both waiting on the Chromium side: Firefox and Safari had shipped contrast-color() and Math.sumPrecise() months earlier, and Chrome 147 landed on April 7 with Edge two days behind. Four more features finished their 30 months of support. One of them is a deletion.

01. `<search>`

Verdict: Cleared · Safe everywhere as of April 13, 2026

An HTML element for the region that holds your search box. It maps to the same search landmark the role attribute gave you, so screen reader users can jump straight to it without you writing any ARIA.

Delete: the role="search" attribute, and usually the <div> it sits on.

HTML · before after

−<!-- a div doing an element's job -->
−<div role="search">
−  <form action="/search">…</form>
−</div>

+<search>
+  <form action="/search">…</form>
+</search>

One thing to style yourself. Browsers that know the tag give it display: block in the user agent stylesheet. A browser too old to know it gives it nothing, and the initial value of display is inline. If old browsers matter to you, declare search { display: block } yourself: one line, inert wherever the browser already does it. Beyond that, failure is graceful. The contents render everywhere, and an old browser loses the landmark, not the page.

A note on the numbers: the summary scoreboard currently shows Safari at zero on this feature. That zero comes down to one missing line in Safari’s stylesheet. Only two tests are scored here, both checking the element’s default styles, and Safari fails one check in each: it does not give <search> the unicode-bidi: isolate the spec asks for. The role-mapping suite passes whole. So the landmark works and the layout is fine. What you lose is bidi isolation, which matters if you put text of mixed direction inside the element.

02. `contrast-color()`

Verdict: Hold · Not yet

Hand it a background color and it returns white or black, whichever contrasts more. New this month, April 10, 2026. The deletion it promises is every hand-maintained pair of background and text custom properties.

CSS

.badge {
  background: var(--accent);
  color: contrast-color(var(--accent));
}

/* Which of white or black wins on a mid-tone
   background is the browser's call, not yours. */

The label is running ahead of the paperwork. The function’s spec is an editor’s draft that still carries the banner “This spec is not yet ready for implementation”, and in the only form browsers ship, with no target contrast stated, the spec leaves the choice of contrast algorithm to the browser. Two engines can legitimately disagree about which of white or black a mid-tone background gets. The tests show real disagreements: Firefox’s current stable run fails both cases where contrast-color() takes container units inside calc(), and Safari’s fails to repaint a gradient whose color stop uses contrast-color(currentColor). One more thing the name does not say: it maximizes contrast, it guarantees none. Against a mid-gray background the winner clears no bar, it just loses less. For now, picking the text color yourself is the only way to know what it will be.

That was April: one attribute to delete, and one new function whose own spec asks you to wait. The other four transitions gave you nothing to do, which is the honest truth about most features in most months.

Delete your equal-height card hack

Mon, 06 Apr 2026 00:00:00 GMT

Eight of March’s ten arrivals landed on a single day, March 24, when Firefox 149 and Safari 26.4 both shipped. One was baseline-shift, a property Chrome has carried since 2008. But the month’s real business is in the eleven features that finished their 30 months of support, because three of them let you delete something. Start with your card grids.

01. Subgrid

Verdict: Cleared · Safe everywhere as of March 15, 2026

A nested grid can adopt its parent’s rows or columns instead of declaring its own: the track sizes come from the parent, and the subgrid’s items feed their sizes back up.

Delete: the script that measures card sections and equalizes their heights, or the fixed row heights doing the same job with magic numbers.

CSS · before after

−/* every card hard-codes the shared row plan */
−.card  { display: grid; grid-template-rows: 3rem 6rem 2rem; }

+/* cards borrow their rows from the grid they sit in */
+.cards { display: grid; grid-template-columns: repeat(3, 1fr);
+         grid-template-rows: repeat(3, auto); }
+.card  { display: grid; grid-row: span 3;
+         grid-template-rows: subgrid; }

Track sizing, gaps and line names pass in all four current stable runs. The exception is baseline alignment: Firefox still fails most of the suite’s baseline tests inside subgrids. Before deleting, search your grid code for align-items: baseline and align-self: baseline, and check those in Firefox. In a browser without subgrid the declaration drops and rows fall back to auto: misaligned cards, not broken ones.

02. Hyphenation

Verdict: Cleared · Safe everywhere as of March 18, 2026

hyphens: auto breaks words at dictionary-approved points. Safari 17 completed the set in September 2023; the 30 months ran out on March 18. It already appears on about one page load in a thousand.

Delete: the script or build step that sprays soft hyphens into your text.

HTML · before after

−<!-- generated markup -->
−Silben&shy;trennung

+<!-- requires lang="de" (or whatever applies) on the markup -->
+<style> article { hyphens: auto; } </style>

The boundary is the language. The spec only requires hyphenation where the content language is known and the browser has a dictionary for it, so hyphens: auto without a lang attribute is a no-op by design. Coverage is also uneven: the suite’s eleven language-specific tests currently fail in all four stable runs, which names no single blocker but does say to spot-check the languages you actually publish. Failure is the gentle kind: no dictionary, no hyphens, a ragged edge.

03. `image-set()`

Verdict: Cleared · Safe everywhere as of March 18, 2026

Resolution switching for CSS backgrounds, the srcset of background-image. Chromium dropped the prefix in May 2023; Safari 17 was the last piece.

Delete: the -webkit-image-set() line.

CSS · before after

−background-image: url(hero.png);
−background-image: -webkit-image-set(url(hero.png) 1x, url(hero@2x.png) 2x);
−background-image: image-set(url(hero.png) 1x, url(hero@2x.png) 2x);

+/* keep the plain url() line */
+background-image: url(hero.png);
+background-image: image-set(url(hero.png) 1x, url(hero@2x.png) 2x);

Every rendering test passes in all four current stable runs. The only misses anywhere are in parsing, where Chrome, Edge and Firefox each pass 138 of 142 subtests and Safari passes all 142. Do keep the plain url() line: in a browser outside the core set that lacks image-set(), it is the difference between a low-resolution image and no image.

04. Custom highlights

Verdict: Hold · Not yet

Style ranges of text from script without wrapping them in elements: register a Highlight, style it with ::highlight(). Firefox 149 shipped the last piece on March 24.

CSS

::highlight(search-match) { background-color: Mark; }

The scores say wait. Chrome and Edge pass 94% of the stable suite. Safari, which has had the feature since late 2023, passes 66%. Firefox 149, the release that flipped the label, passes 70%, and it fails nearly the same tests Safari does. The failures are the visible kind: highlight painting over text sized with font-relative or container-relative units, vertical writing mode, and in Safari’s case text shadows inside highlights. Until both catch up, the span-wrapping you already do is the more predictable renderer.

05. `text-indent: hanging`

Verdict: Cleared · New this month, March 13, 2026

One keyword inverts text-indent, so every line except the first is indented: the hanging indent of bibliographies and transcripts.

Delete: the two-declaration pair that fakes it.

CSS · before after

−/* indent everything, pull the first line back */
−.ref { padding-left: 2em; text-indent: -2em; }

+.ref { text-indent: 2em hanging; }

Chromium shipped it on March 10, three days before the label; Safari has had it since 2021, Firefox since 2023. Every test passes in every current stable run, mobile included, which is rare enough this month to be worth saying. In an older browser the declaration is invalid and drops: lines sit flush, nothing breaks. Its sibling each-line went Baseline the same day.

That was March: four deletions and one wait, courtesy of test runs that say what the label does not.

Delete your RTL-detection script

Mon, 09 Mar 2026 00:00:00 GMT

Five features became newly available in February, and exactly one finished its 30 months of support. Four of the five arrivals live in JavaScript, WebAssembly, HTTP compression and a security API, outside this newsletter’s beat, so this is a thin month with two items: one CSS arrival worth starting now, and one deletion fourteen years in the making.

01. `dirname`

Verdict: Cleared · Safe everywhere as of February 1, 2026

An attribute for text fields. Add dirname and the browser submits a second field alongside the value: the direction the text was typed in, ltr or rtl. Chrome and Safari have shipped it since 2012. Firefox 116 completed the set in August 2023, and the 30-month clock ran out on February 1.

Delete: the direction-guessing code. If your site stores user text that might be Arabic or Hebrew, something today inspects each comment to decide whether it needs dir="rtl" when displayed again, a client script or a server-side heuristic. The browser already knows; let it tell you.

HTML · before after

−<!-- a script sniffs the value, fills a hidden field -->
−<input type="text" name="comment">

+<!-- the browser reports direction at submission -->
+<input type="text" name="comment" dirname="comment.dir">
+<!-- comment=%D9%85%D8%B1%D8%AD%D8%A8%D8%A7&comment.dir=rtl -->

The edges are less settled. On input types where the spec says the attribute does not apply, current stable runs disagree: Firefox 148 and Safari 26.3 submit the direction pair for a month input anyway, while Chrome 146 and Edge 145 omit it. Keep dirname on plain text fields and textareas, where every current run passes, and treat the extra field as optional on the server. A browser too old to know the attribute never sends it: your default direction applies, and nothing breaks.

02. `shape()`

Verdict: Cleared · New this month, February 24, 2026

A clip-path drawn with path commands in CSS syntax: lines, curves, arcs, in any CSS unit. The path() function it improves on takes one SVG string and, as the spec puts it, implicitly allows only the px unit. The spec defines shape() as a superset of path(): the same commands, but percentages, em, var() and calc() all work, so a curved shape can finally follow the box it clips.

The scoreboard argues. webstatus.dev shows stable Safari passing a third of the suite, which reads like a Hold. It is not. The current Safari 26.3 run fails seven subtests, and every one is the same complaint: when style is read back, Safari keeps the default from start and from origin keywords instead of dropping them from the serialization. Every parsing and computing subtest for the geometry itself passes, as it does in the current Chrome, Edge and Firefox runs. Nothing renders differently.

Firefox shipped it last, on February 24, so declare a fallback on the line above; a browser without shape() drops the declaration it cannot parse and keeps the earlier one:

CSS

clip-path: polygon(0 0, 100% 0, 100% 85%, 0 100%); /* older browsers stop here */
clip-path: shape(from 0 0, line to 100% 0,
                 line to 100% 85%, curve to 0 100% with 50% 80%);

Two footnotes. If your tests compare getComputedStyle strings for clip-path, Safari’s extra keywords will trip them; that is the entire defect. And Firefox Android has no current measurement: its newest test run predates the release that shipped the feature, so the low score there is a blank, not a fail. If it did turn out broken, the fallback line above is what those users would see.

That was February: a thin month for arrivals, and one deletion that waited fourteen years for its clock to run out.

Delete your is-transitioning class

Mon, 09 Feb 2026 00:00:00 GMT

January was one release wide. Firefox 147, on January 13, closed out all seven of the month’s arrivals by itself; nothing else moved. Four of the seven are the root-font versions of existing length units, full marks everywhere and nothing to do with them. The Navigation API reached Baseline the same day, but it is JavaScript, and this letter’s beat is CSS and HTML; it lives in the archive links below. The deletion this month belongs to everyone already running view transitions.

01. `:active-view-transition`

Verdict: Cleared · New this month, January 13, 2026

A pseudo-class that matches the root element while a view transition is running, and stops matching when it settles. Chromium has shipped it since May 2024; Firefox 147 was the last browser in.

Delete: the script that adds a marker class to the root before document.startViewTransition() and removes it when the transition finishes, just so your stylesheet can tell a transition is underway.

CSS · before after

−/* a script toggles this class on <html> */
−.is-transitioning .toolbar { pointer-events: none; }

+/* the selector tracks the transition itself */
+html:active-view-transition .toolbar { pointer-events: none; }

One thing to watch. In a browser too old to know this pseudo-class, the selectors spec makes any selector list containing an invalid selector invalid, whole. Appended to an existing comma-separated rule, :active-view-transition takes the other selectors down with it. Give it its own block, or wrap it in :where(), which parses forgivingly. Done that way, failure is graceful twice over: the rule never matches, and a browser without view transitions has no transition to style anyway.

The four desktop stable runs pass the feature’s tests without exception. Neither Android runner produces a number worth reading: Chrome Android fails the suite’s reftests wholesale at the same engine version that passes on desktop, so the fault is more likely in the test harness than in the browser, and Firefox Android’s runs carry no results for these reftests at all. If current Firefox on Android is broken here, the cost is that your transition styles do not apply. Usage is early, about one page load in a hundred thousand, which is also the audience: no view transitions, nothing to delete yet.

02. `animation-composition`

Verdict: Skip · Safe everywhere as of January 4, 2026

Skip, unless you run two animations against the same property of the same element. Then this is for you: it decides whether the second animation replaces the first, the default, or adds to it, or accumulates with it.

It finished its 30 months of support on January 4 with a perfect score in every current stable run, and Chrome’s developer site gave it a dedicated write-up, more promotion than a property this situational usually gets. Hence the printed verdict: in most stylesheets two animations never meet on one property, so there is nothing to delete and nothing to start. Where they do meet, it works everywhere today.

That was January: one release, one deletion, and a clearing shelf with nothing on it that needs removing.

Cleared

Delete your text-stroke hack

01. paint-order

02. Scroll anchoring

03. progress()

04. light-dark() image values

05. alpha()

Delete your declarative shadow DOM polyfill

01. Declarative shadow DOM

02. sibling-index() and sibling-count()

03. Media element pseudo-classes

AVIF cleared: one fallback can go

01. AVIF

Nesting cleared: delete a build step

01. Nesting

02. Lazy-loading images and iframes

03. :has()

04. field-sizing

05. Masks

Delete your form’s touched classes

01. :user-valid and :user-invalid

02. lh unit

03. Container style queries

Delete your role="search" wrapper

01. <search>

02. contrast-color()

Delete your equal-height card hack

01. Subgrid

02. Hyphenation

03. image-set()

04. Custom highlights

05. text-indent: hanging

Delete your RTL-detection script

01. dirname

02. shape()

Delete your is-transitioning class

01. :active-view-transition

02. animation-composition

01. `paint-order`

03. `progress()`

04. `light-dark()` image values

05. `alpha()`

02. `sibling-index()` and `sibling-count()`

03. `:has()`

04. `field-sizing`

01. `:user-valid` and `:user-invalid`

02. `lh` unit

01. `<search>`

02. `contrast-color()`

03. `image-set()`

05. `text-indent: hanging`

01. `dirname`

02. `shape()`

01. `:active-view-transition`

02. `animation-composition`