# tailwindcss — corrections from the Stale Priors Index

<!--
     Stale Priors Index · Unattended Works · https://stalepriors.com/rules/tailwindcss.md

     The Stale Priors Index, Unattended Works (https://stalepriors.com/rules/tailwindcss.md), CC BY 4.0. Retrieved 2026-09-06.
     Licence: https://creativecommons.org/licenses/by/4.0/  ·  SPDX-License-Identifier: CC-BY-4.0
     Quotations from third-party changelogs remain their authors'; nothing here grants any
     right in the libraries described. Full map: https://stalepriors.com/data/LICENSE

     Changed since the 2026-09-06 sweep: 5 of the 35 entries below, newest 2026-09-28
     — a change to this record, not a re-check against a source. The note below says why.

     GENERATED FILE — DO NOT EDIT BY HAND. Your edit will be destroyed by the next build.
     Rebuild:  node tools/build-rules.mjs
     Source:   data/tailwindcss/facts.json
-->

For projects on **tailwindcss@^4**. 35 corrections, 35 of them dated to the release that changed the behaviour; every entry links the primary source it was verified against. Latest tailwindcss: 4.3.3, verified 2026-09-06. Do **not** use this if you are pinned to tailwindcss@3 or earlier.

**This is the statements only** — no reproduced model failures, no code, no evidence. The full pack has all three: https://stalepriors.com/corrections/tailwindcss.md

**Two dates, and they answer different questions.** The entries below were last checked against their primary sources on 2026-09-06 — that date is the floor, and it is the only verification claim this file makes. Separately, 5 of the 35 entries have had their own text change since that sweep, the newest on 2026-09-28. A text change is a change to the record — a re-scored severity, a corrected release date, a clarified note — and it is **not** a re-check against the source. Do not read the later date as the fresher of two checks; per-entry dates are in `substance_changed_on` in the JSON.

**What was measured, and what this file is not.** The 2 benchmark runs so far measured the **prisma** and **zod** correction packs — not tailwindcss's, and not this shorter file. There is no measurement of what either does for tailwindcss. Every cell: https://stalepriors.com/benchmark

The corrections below are 26,556 characters. Read that as a cost: a rules file is added to requests, so it is a decision to make rather than a default to accept.

## Breaks the build, or throws at runtime

### `@apply inside Vue/Svelte/Astro <style> blocks and CSS modules`

**New requirement in tailwindcss 4.0.0** (2025-01-21).

Stylesheets bundled separately from the main CSS file — single-file-component `<style>` blocks, CSS module files — have no access to your theme variables, custom utilities or custom variants, so `@apply` fails there. Pull the definitions in first with `@reference`, pointing at your CSS entry file so custom `@theme` tokens resolve. `@reference` adds no CSS to the bundle.

*The stale belief:* That `@apply` works in any stylesheet the build touches, as it did in v3.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Using @apply with Vue, Svelte, or CSS modules"](https://tailwindcss.com/docs/upgrade-guide)

### `@layer utilities / @layer components (for defining custom classes)`

**Removed in tailwindcss 4.0.0** (2025-01-21).

v4 uses native CSS cascade layers and no longer hijacks the `@layer` at-rule, so a class defined inside `@layer utilities` is no longer registered as a utility and gets no variant support (`hover:`, `md:`). Custom utilities are declared with the `@utility` API, which also accepts functional forms.

*The stale belief:* That wrapping a class in `@layer utilities` is how you add a custom utility that works with variants.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Adding custom utilities"](https://tailwindcss.com/docs/upgrade-guide)

### `bg-[--var] (CSS variable shorthand in arbitrary values)`

**Renamed in tailwindcss 4.0.0** (2025-01-21).

The bare-variable shorthand inside arbitrary values moved from square brackets to parentheses: `bg-[--brand]` becomes `bg-(--brand)`. The explicit longhand `bg-[var(--brand)]` is unaffected and still works.

*The stale belief:* That `bg-[--brand]` resolves the custom property.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Variables in arbitrary values"](https://tailwindcss.com/docs/upgrade-guide)

### `bg-opacity-* / text-opacity-* / border-opacity-* / ring-opacity-* / placeholder-opacity-* / divide-opacity-*`

**Removed in tailwindcss 4.0.0** (2025-01-21).

The separate opacity utilities were removed. Use the slash opacity modifier on the colour utility itself.

*The stale belief:* That translucency is expressed as a second class, `bg-black bg-opacity-50`.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Removed deprecated utilities"](https://tailwindcss.com/docs/upgrade-guide)

### `commas in grid-cols-[…] / grid-rows-[…] / object-[…] arbitrary values`

**Stricter in tailwindcss 4.0.0** (2025-01-21).

v3 replaced commas with spaces inside these particular arbitrary values, a compatibility hack carried over from v2. That is gone: use underscores for spaces, as everywhere else in arbitrary values.

*The stale belief:* That `grid-cols-[max-content,auto]` means two columns.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Arbitrary values in grid and object-position utilities"](https://tailwindcss.com/docs/upgrade-guide)

### `prefix`

**Renamed in tailwindcss 4.0.0** (2025-01-21).

Prefixes now look like variants and sit at the front of the whole class: `tw:flex`, `tw:hover:bg-red-600`. The prefix is declared on the import, and theme variables are still authored unprefixed.

*The stale belief:* That the prefix is glued to the utility name after any variants, `hover:tw-bg-red-600`.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Using a prefix"](https://tailwindcss.com/docs/upgrade-guide)

### `resolveConfig`

**Removed in tailwindcss 4.0.0** (2025-01-21).

The `resolveConfig` export was removed. Theme values are real CSS custom properties at runtime, so reference them directly (`var(--color-blue-500)`), or read one in JS with `getComputedStyle(document.documentElement).getPropertyValue("--shadow-xl")`.

*The stale belief:* That you import `resolveConfig` from `tailwindcss/resolveConfig` to get theme values into JavaScript.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Theme values in JavaScript"](https://tailwindcss.com/docs/upgrade-guide)

### `safelist / corePlugins / separator`

**Removed in tailwindcss 4.0.0** (2025-01-21).

The `safelist`, `corePlugins` and `separator` options are not supported in v4, from a JS config or anywhere else. Their replacement did **not** ship with the removal: `@source inline(...)` — whose argument is brace-expanded — arrived in **4.1.0 (2025-04-01)**, ten weeks after 4.0.0 removed `safelist`. On 4.0.x there is no safelisting mechanism at all, and `@source inline("...")` is a build error there: the 4.0 parser accepts a quoted path only and throws ``@source` paths must be quoted.`

*The stale belief:* That runtime-assembled class names are rescued by a `safelist` array in `tailwind.config.js`.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Using a JavaScript config file"](https://tailwindcss.com/docs/upgrade-guide)

### `Sass / Less / Stylus`

**New requirement in tailwindcss 4.0.0** (2025-01-21).

v4 is not designed to be used with a CSS preprocessor. Tailwind is the preprocessor: you cannot use Sass, Less or Stylus for your stylesheets or for `<style lang="scss">` blocks in Vue, Svelte or Astro.

*The stale belief:* That Tailwind composes with Sass the way v3 tolerated.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Using Sass, Less, and Stylus"](https://tailwindcss.com/docs/upgrade-guide)

### `tailwind.config.js`

**Removed in tailwindcss 4.0.0** (2025-01-21).

JavaScript config files are still supported but are **no longer detected automatically**. A `tailwind.config.js` sitting in the project root is simply ignored, so every utility derived from it (`bg-brand`, `font-display`) silently emits nothing. Configure the theme in CSS with `@theme`, or load the legacy file explicitly with `@config`.

*The stale belief:* That dropping a `tailwind.config.js` in the project root configures the build, and that `theme.extend` is where custom colours and fonts go.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Using a JavaScript config file"](https://tailwindcss.com/docs/upgrade-guide)

### `tailwindcss as a PostCSS plugin / npx tailwindcss`

**Removed in tailwindcss 4.0.0** (2025-01-21).

The `tailwindcss` package is no longer itself the PostCSS plugin or the CLI. The PostCSS plugin moved to `@tailwindcss/postcss`, the CLI to `@tailwindcss/cli`, and Vite projects have a dedicated `@tailwindcss/vite` plugin, which is the documented install path. Import handling and vendor prefixing are built in, so `postcss-import` and `autoprefixer` can be removed.

*The stale belief:* That you install `tailwindcss postcss autoprefixer`, run `npx tailwindcss init -p`, and list `tailwindcss: {}` among your PostCSS plugins.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Using PostCSS" / "Using Tailwind CLI"](https://tailwindcss.com/docs/upgrade-guide)

## Runs, but is silently wrong

### `node_modules scanning`

**Default changed in tailwindcss 4.1.0** (2025-04-01).

As of 4.1.0 `node_modules` is ignored by default when detecting classes. A component library shipping Tailwind classes in its published files needs an explicit `@source` pointing into it.

*The stale belief:* That classes inside an installed package are picked up automatically.

*Verified against:* [tailwindcss CHANGELOG — 4.1.0 (2025-04-01), Changed](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md)

### `@tailwind base / @tailwind components / @tailwind utilities`

**Removed in tailwindcss 4.0.0** (2025-01-21).

The `@tailwind base` and `@tailwind components` directives no longer do anything: on v4 each compiles to an empty sheet, so preflight and the components layer are gone. `@tailwind utilities` is still accepted and still emits the utility sheet. A v4 entry file pulls all three of preflight, theme and utilities in with one plain CSS import: `@import "tailwindcss";`.

*The stale belief:* That a Tailwind entry stylesheet starts with `@tailwind base; @tailwind components; @tailwind utilities;`.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Removed @tailwind directives"](https://tailwindcss.com/docs/upgrade-guide)

### `border / divide (default colour)`

**Default changed in tailwindcss 4.0.0** (2025-01-21).

The default colour of `border-*` and `divide-*` changed from the configured `gray-200` to `currentColor`, matching browser defaults. An uncoloured `border` now renders in the element's text colour — usually near-black — where v3 rendered a light grey.

*The stale belief:* That `class="border"` draws a subtle grey hairline.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Default border color"](https://tailwindcss.com/docs/upgrade-guide)

### `container (center / padding configuration)`

**New requirement in tailwindcss 4.0.0** (2025-01-21).

The `container` utility's `center` and `padding` configuration options still work in v4, but **only from a config loaded explicitly with `@config`**. They are not gone — a config file sitting in the project root is simply never read (LF2), so a v3 project carried into v4 loses its centring and padding with no error. Either add `@config "./tailwind.config.js";` to the entry stylesheet, or extend the utility in CSS with `@utility container`. Both work at every v4 release.

*The stale belief:* That a `tailwind.config.js` in the project root still configures the container, because `theme.container.center` and `theme.container.padding` are where those live.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Container configuration"](https://tailwindcss.com/docs/upgrade-guide)

### `hover variant`

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21).

`hover:` is now wrapped in `@media (hover: hover)`, so it does not fire on touch devices that previously triggered hover on tap. Treat hover as an enhancement; if you genuinely depend on the old behaviour, override the variant.

*The stale belief:* That `hover:` styles apply on touch devices when the user taps.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Hover styles on mobile"](https://tailwindcss.com/docs/upgrade-guide)

### `outline-none`

**Renamed in tailwindcss 4.0.0** (2025-01-21).

In v3, `outline-none` did not set `outline-style: none` — it set an invisible outline that still appeared in forced-colors mode for accessibility. That behaviour is now called `outline-hidden`. The v4 `outline-none` really does remove the outline. Code carrying `focus:outline-none` from v3 therefore loses its forced-colors-mode focus indicator.

*The stale belief:* That `focus:outline-none` is the safe way to suppress the browser's focus ring before drawing your own.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Renamed outline utility"](https://tailwindcss.com/docs/upgrade-guide)

### `Preflight base styles`

**Default changed in tailwindcss 4.0.0** (2025-01-21).

Three Preflight defaults changed: placeholder text uses the current text colour at 50% opacity rather than `gray-400`; buttons use `cursor: default` rather than `cursor: pointer`; and margins are reset on `<dialog>`, so dialogs are no longer centred by default. Each is restorable with a small `@layer base` block.

*The stale belief:* That buttons get a pointer cursor and dialogs are centred out of the box.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Preflight changes"](https://tailwindcss.com/docs/upgrade-guide)

### `px-* / py-* / mx-* / my-* / inset-x-* / inset-y-* / scroll-px-* / scroll-my-* / border-x-* / border-y-*`

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21).

Since 4.0.0 every x/y axis utility compiles to a LOGICAL property, not a pair of physical ones: `px-*` is `padding-inline`, `py-*` is `padding-block`, `mx-*`/`my-*` are `margin-inline`/`margin-block`, `inset-x-*`/`inset-y-*` are `inset-inline`/`inset-block`, `scroll-px-*`/`scroll-py-*`/`scroll-mx-*`/`scroll-my-*` are the `scroll-padding-*`/`scroll-margin-*` inline and block properties, and `border-x-*`/`border-y-*` set `border-inline-width`/`border-block-width`. In 3.x each of them emitted the physical pair (`padding-left` + `padding-right`, `top` + `bottom`, and so on). The single-side utilities did NOT move — `pl-*`, `mt-*`, `left-*` and the corner radii such as `rounded-t-*` still emit physical properties — and a single-side utility still sorts after its axis utility, so `px-4 pl-0` leaves the left padding at zero on every release, 3.4 and 4.x alike.

*The stale belief:* That `px-4` compiles to `padding-left` and `padding-right` (and `py-*`, `mx-*`, `inset-x-*` to their physical pairs) in Tailwind v4, as they did in v3 — so an axis utility is the same box on every element regardless of its writing mode.

*Verified against:* [tailwindcss CHANGELOG — [4.0.0-alpha.31] - 2024-10-29, Changed (shipped in the first stable, 4.0.0, 2025-01-21)](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md)

### `ring`

**Default changed in tailwindcss 4.0.0** (2025-01-21).

The bare `ring` utility changed from a 3px `blue-500` ring to a 1px `currentColor` ring. A v3 focus style written as `focus:ring` is therefore now a thin ring in the element's own text colour — on a coloured button with white text, effectively invisible. Use `ring-3` plus an explicit `ring-<color>` to restore the v3 appearance.

*The stale belief:* That `focus:ring` alone produces the familiar 3px blue focus ring.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Default ring width and color"](https://tailwindcss.com/docs/upgrade-guide)

### `shadow-sm / shadow / rounded-sm / rounded / blur-sm / blur`

**Renamed in tailwindcss 4.0.0** (2025-01-21).

The shadow, radius and blur scales were shifted one step so every utility has a named value. What v3 called `shadow` is now `shadow-sm`, and v3's `shadow-sm` is now `shadow-xs`. The same applies to `rounded`/`rounded-sm`, `blur`/`blur-sm` and `drop-shadow`/`backdrop-blur`. The old bare names still resolve, so nothing errors — they just render one step larger than the author intended.

*The stale belief:* That `shadow-sm` is the subtlest shadow in the scale.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Updated shadow, radius, and blur scales"](https://tailwindcss.com/docs/upgrade-guide)

### `space-x-* / space-y-* / divide-x-* / divide-y-* (selector)`

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21).

The selector behind these utilities changed from `> :not([hidden]) ~ :not([hidden])` to `> :not(:last-child)`, for performance, and the spacing now hangs off the *bottom* of each child rather than the top of each sibling. Layouts using these with inline elements, or with per-child margin tweaks, can shift. Prefer `flex`/`grid` with `gap`.

*The stale belief:* That `space-y-4` adds top margin to every child after the first.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Space-between selector"](https://tailwindcss.com/docs/upgrade-guide)

### `stacked variant order`

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21).

Stacked variants now apply left to right instead of right to left, to read more like CSS. Order-sensitive stacks must be reversed: v3's `first:*:pt-0` is v4's `*:first:pt-0`. In practice this bites the direct-child variant `*` and plugin variants like `prose-headings`.

*The stale belief:* That `first:*:pt-0` targets the first child.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Variant stacking order"](https://tailwindcss.com/docs/upgrade-guide)

### `transform-none / rotate-* / scale-* / translate-*`

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21).

These utilities are now built on the individual `rotate`, `scale` and `translate` CSS properties rather than the `transform` shorthand. Two consequences: `transform-none` no longer resets them (reset the individual property, e.g. `scale-none`), and a custom transition list containing `transform` no longer transitions them — list the individual properties, `transition-[opacity,scale]`.

*The stale belief:* That `transform-none` clears a scale or rotation, and that `transition-[opacity,transform]` animates `scale-*`.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Individual transform properties"](https://tailwindcss.com/docs/upgrade-guide)

## Deprecated, or a better API now exists

### `@container-size`

**Added in tailwindcss 4.3.0** (2026-05-08).

Since 4.3.0 the `@container-size` utility sets `container-type: size`, alongside the long-standing `@container` utility which sets `container-type: inline-size`. Use `@container-size` where a container query needs to read the container's block size as well as its inline size; `@container` is unchanged and is still the right default.

*The stale belief:* That `@container` is the only container-type utility, so `container-type: size` needs `[container-type:size]` or a hand-written rule.

*Verified against:* [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0)

### `@variant (stacked and compound variants)`

**Added in tailwindcss 4.3.0** (2026-05-08).

Since 4.3.0 the `@variant` at-rule accepts a stacked variant (`@variant hover:focus { … }`, applying when both conditions hold) and a comma-separated compound list (`@variant hover, focus { … }`, applying when any of them holds). Both spellings work with modifier-carrying variants too, so `@variant group-hover:focus { … }` is legal. Before 4.3.0 `@variant` took exactly one variant name and anything else was a BUILD ERROR: `Cannot use @variant with unknown variant: hover:focus`.

*The stale belief:* That `@variant` takes a single variant only, so combining two conditions means nesting one `@variant` block inside another, and a comma-separated list has no equivalent at all — a model holding this belief will tell the author of a working `@variant hover:focus { … }` block that Tailwind cannot parse it.

*Verified against:* [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0)

### `scrollbar-auto / scrollbar-thin / scrollbar-none / scrollbar-thumb-* / scrollbar-track-* / scrollbar-gutter-*`

**Added in tailwindcss 4.3.0** (2026-05-08).

Since 4.3.0 Tailwind ships first-class scrollbar utilities and no plugin is needed. `scrollbar-auto`, `scrollbar-thin` and `scrollbar-none` set `scrollbar-width`. `scrollbar-thumb-*` and `scrollbar-track-*` set `scrollbar-color` — each writes one half into a CSS variable (`--tw-scrollbar-thumb` / `--tw-scrollbar-track`) and both emit the same `scrollbar-color` declaration, so use them as a pair or the unset half falls back to the variable's default. `scrollbar-gutter-auto` and `scrollbar-gutter-stable` set `scrollbar-gutter`. Colour utilities take the theme palette and arbitrary values alike: `scrollbar-thumb-slate-500` and `scrollbar-thumb-[#123456]` both compile. Do not install `tailwind-scrollbar` and do not hand-write a `::-webkit-scrollbar` block for the standard properties.

*The stale belief:* That Tailwind has no scrollbar utilities, so styling a scrollbar means installing the third-party `tailwind-scrollbar` plugin, writing `::-webkit-scrollbar` rules in your own CSS, or reaching for arbitrary properties. A model holding this belief will also reject working `scrollbar-thin scrollbar-thumb-slate-500` markup in review as classes that generate nothing.

*Verified against:* [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0)

### `zoom-* / tab-*`

**Added in tailwindcss 4.3.0** (2026-05-08).

Since 4.3.0 Tailwind ships `zoom-*` utilities for the CSS `zoom` property and `tab-*` utilities for `tab-size`. `zoom-*` takes a percentage-style number — `zoom-50` emits `zoom: 50%`, `zoom-150` emits `zoom: 150%` — and `tab-*` takes a plain integer, so `tab-4` emits `tab-size: 4`. Both accept arbitrary values: `zoom-[1.5]` emits `zoom: 1.5` (a bare ratio, not a percentage) and `tab-[3]` emits `tab-size: 3`.

*The stale belief:* That neither CSS `zoom` nor `tab-size` has a Tailwind utility, so both need arbitrary properties or hand-written CSS.

*Verified against:* [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0)

### `pbs-* / pbe-* / mbs-* / mbe-* / border-bs-* / inline-* / block-* / min-inline-* / max-block-* / inset-bs-*`

**Added in tailwindcss 4.2.0** (2026-02-18).

Since 4.2.0 Tailwind ships first-class utilities for the CSS block axis and for logical sizing. Spacing: `pbs-*`, `pbe-*`, `mbs-*`, `mbe-*`, and the scroll variants `scroll-pbs-*`, `scroll-pbe-*`, `scroll-mbs-*`, `scroll-mbe-*`. Borders: `border-bs-*`, `border-be-*`. Sizing: `inline-*`, `min-inline-*`, `max-inline-*` for `inline-size` and its bounds, and `block-*`, `min-block-*`, `max-block-*` for `block-size`. Insets: `inset-s-*`, `inset-e-*`, `inset-bs-*`, `inset-be-*`. Do not reach for `[padding-block-start:...]` arbitrary values and do not substitute the physical `pt-*` / `mb-*` / `h-*` utilities, which are not equivalent in a vertical writing mode. The INLINE axis is the older half of the family and keeps its v3 spelling: `ps-*`, `pe-*`, `ms-*`, `me-*`. There is no `pis-*`, `pie-*`, `mis-*`, `mie-*` or `border-is-*` at any release, 4.3.3 included.

*The stale belief:* That Tailwind covers the inline axis only (`ps-*`, `ms-*`, `start-*`, `end-*`) and offers nothing for `padding-block-start`, `border-block-start`, `inline-size` or `block-size`, so a writing-mode-agnostic component needs arbitrary values or hand-written CSS. A model holding this belief will also reject working `pbs-6` / `inline-full` markup in review as classes that generate nothing.

*Verified against:* [tailwindcss CHANGELOG - 4.2.0 (2026-02-18), Added](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md)

### `start-* / end-*`

**Deprecated in tailwindcss 4.2.0** (2026-02-18).

As of 4.2.0 the logical inset utilities `start-*` and `end-*` are deprecated in favour of `inset-s-*` and `inset-e-*`, alongside a new family of logical-property utilities (`pbs-*`, `mbe-*`, `border-bs-*`, `inline-*`, `block-*`).

*The stale belief:* That `start-0` / `end-0` are the current logical inset utilities.

*Verified against:* [tailwindcss CHANGELOG — 4.2.0 (2026-02-18), Deprecated](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md)

### `bg-gradient-*`

**Deprecated in tailwindcss 4.0.0** (2025-01-21).

Linear gradient utilities were renamed from `bg-gradient-*` to `bg-linear-*`, making room for the new `bg-radial-*` and `bg-conic-*` families and for angle values like `bg-linear-45`. The old spelling was kept, not removed: `bg-gradient-to-r` still compiles to a working linear gradient at every 4.x release. It is not an exact alias — from 4.1.0 the two spellings emit different declarations, and only `bg-linear-*` gets the `@supports` interpolation branch — so adopt the new name for that as well as for the angle and radial/conic families. Gradients also keep their other stops when a variant overrides one — use `via-none` to drop back to a two-stop gradient in a given state.

*The stale belief:* That `bg-gradient-to-r` is the current spelling of the linear gradient utility. It is the v3 spelling, still compiled but no longer identical to the new one.

*Verified against:* [Tailwind CSS v4.0 announcement — Expanded gradient APIs](https://tailwindcss.com/blog/tailwindcss-v4)

### `flex-shrink-* / flex-grow-* / overflow-ellipsis / decoration-slice / decoration-clone`

**Deprecated in tailwindcss 4.0.0** (2025-01-21).

These v3 aliases were dropped from the documentation, not from the compiler. `flex-shrink-*`, `flex-grow-*`, `overflow-ellipsis`, `decoration-slice` and `decoration-clone` are still registered utilities in every 4.x release and emit exactly the same declarations as `shrink-*`, `grow-*`, `text-ellipsis`, `box-decoration-slice` and `box-decoration-clone`. Markup carrying the old names keeps working and renders identically. Adopt the new spellings because the old ones are undocumented and no longer suggested by tooling — not because anything breaks.

*The stale belief:* That `flex-shrink-0` is the current, documented spelling. It is the v3 spelling: it still compiles to `flex-shrink: 0`, and it is no longer in the docs.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Removed deprecated utilities" (accurate about the docs, not about the compiler)](https://tailwindcss.com/docs/upgrade-guide)

### `the important modifier (!flex)`

**Deprecated in tailwindcss 4.0.0** (2025-01-21).

The `!` that marks a utility important moved from the start of the class name to the end: `!flex` becomes `flex!`, `hover:!bg-red-600` becomes `hover:bg-red-600!`. The leading form is still supported for compatibility but is deprecated.

*The stale belief:* That the important marker goes after the variants and before the utility.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "The important modifier"](https://tailwindcss.com/docs/upgrade-guide)

### `theme() function`

**Deprecated in tailwindcss 4.0.0** (2025-01-21).

Prefer the generated CSS variables over `theme()`. The dot path is **deprecated, not removed**: `theme(colors.red.500)` and `theme(screens.xl)` still resolve in v4 and compile to exactly the same declarations as `theme(--color-red-500)` and `theme(--breakpoint-xl)`. Write the CSS-variable form in new code — `var(--color-red-500)` outside media queries, `theme(--breakpoint-xl)` inside them, where CSS variables are not supported — but existing dot-path stylesheets are not broken and do not need an urgent migration.

*The stale belief:* That theme values are addressed with dot notation, `theme(colors.red.500)`, and that this is the current idiom rather than a deprecated one.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Using the theme() function" (advice, not a removal)](https://tailwindcss.com/docs/upgrade-guide)

## Wrong facts about the library

### `browser support baseline`

**New requirement in tailwindcss 4.0.0** (2025-01-21).

v4 targets Safari 16.4+, Chrome 111+ and Firefox 128+, because it depends on `@property` and `color-mix()` for core features. It will not work in older browsers; projects that must support them should stay on v3.4.

*The stale belief:* That upgrading to the current major is browser-support-neutral.

*Verified against:* [Tailwind CSS docs — Upgrade guide, "Browser requirements"](https://tailwindcss.com/docs/upgrade-guide)

---

*The Stale Priors Index, Unattended Works (https://stalepriors.com/rules/tailwindcss.md), CC BY 4.0. Retrieved 2026-09-06. Licence: <https://creativecommons.org/licenses/by/4.0/> (`SPDX-License-Identifier: CC-BY-4.0`).*
*Quoted changelog text belongs to its authors; nothing here grants any right in the libraries described.*
*Terms in full: <https://stalepriors.com/data/LICENSE>.*