What Claude Fable 5.1 gets wrong about tailwindcss — battery v3-a, tested 2026-09-06

Task 1(a), one word: "No". Then: "Tailwind core (v4.0 / v4.1.x, the releases I can actually describe) has no scrollbar-width, scrollbar-color, or scrollbar-gutter utilities. Those class names you may have seen (scrollbar-thin, scrollbar-thumb-*, scrollbar-track-*) come from the third-party tailwind-scrollbar plugin, not the framework." On task 3, reviewing markup that uses them: "scrollbar-thin, scrollbar-thumb-slate-500, scrollbar-track-slate-100, scrollbar-gutter-stable — none exist in core. These are tailwind-scrollbar plugin names, and the PR doesn't add the plugin."

The charge is the REVIEW direction, not the code. The arbitrary-property block this draw shipped in task 1 compiles and emits the identical declarations — verified against installed 4.2.4 and 4.3.0 — so a reader who takes only the task 1 answer loses verbosity and nothing else, which is S3 under the workaround rule. What lifts it to S2 is task 3: presented with working markup, this draw tells the author that four classes generate no CSS and are plugin names the project does not have installed. Every one of them compiles at 4.3.0 and 4.3.3. A reviewer acting on that deletes correct code, and the false claim that the names belong to tailwind-scrollbar sends the next reader to add a dependency the framework has made unnecessary.

The draw's own arbitrary-property code was executed: [scrollbar-width:thin], [scrollbar-color:...] and [scrollbar-gutter:stable] all compile at 4.2.4 and 4.3.0. Its browser-support caveats (Firefox/Chromium 121+, Safari ignoring the standard properties) were NOT verified and nothing in the charge rests on them. The denial was hedged ("If a release newer than what I know added them, I can't vouch for it"), which under HARNESS.md § A hedge is a self-placement, not a grade on the content is recorded but does not soften the verdict-first "No" or the task 3 review. PARTIAL DERIVABILITY, from this battery's own below-floor control: Claude Sonnet 5, sixteen months under the release, WROTE scrollbar-thin scrollbar-thumb-slate-500 scrollbar-track-slate-100 in its task 1 markup — because tailwind-scrollbar has used those exact names for years. The names are derivable and the Index says so; scrollbar-gutter-* is not (no control produced it), and neither is the claim that the family is core. The charge rests on the denial and the rejection, never on the names.

• tailwindcss v4.3.0 release notes — Added published 2026-05-08

  Add scrollbar-{auto,thin,none} utilities for scrollbar-width, and scrollbar-thumb-* / scrollbar-track-* color utilities for scrollbar-color

• tailwindcss v4.3.0 release notes — Added published 2026-05-08

  Add scrollbar-gutter-* utilities

• tailwindcss 4.3.0, shipped package — `scrollbar-thin` compiles to `scrollbar-width: thin`, `scrollbar-thumb-slate-500` and `scrollbar-track-slate-100` to `--tw-scrollbar-thumb`/`--tw-scrollbar-track` plus `scrollbar-color`, and `scrollbar-gutter-stable` to `scrollbar-gutter: stable`.
• tailwindcss 4.2.4, shipped package — every one of those class names compiles to nothing at the last release of the 4.2 line.

Task 3: "@container-size — not a core utility as far as I know. Core has @container (container-type: inline-size), @container-normal, and named @container/name. If the section genuinely needs block-axis container queries, write [container-type:size]; otherwise use @container."

Working markup called out as inert in review. The suggested replacement compiles, so the reader's page still works; the cost is the deleted correct class and a reviewer's stated confidence about a utility that exists. NOTE THE CONTRAST INSIDE THIS BATTERY: Claude Opus 5, whose stated cutoff is in the same month as the release, accepted @container-size as valid in the same review task and gave its declaration correctly. That marks this probe DERIVABLE (JOURNAL/030) and no pass on it would have been reported as knowledge — but a derivable outcome kills a pass, not a failure (JOURNAL/031), so this rejection stands, and stands as the weaker of this run's charges for how easy the correct answer was to reach.

[container-type:size], the replacement this draw proposed, compiles at 4.2.4 and 4.3.0 — so does @container-[size], which the blind twin proposed. The 4.3.0 addition is a shorthand for something already expressible, which is why this finding is about the review verdict and not about broken output.

• tailwindcss v4.3.0 release notes — Added published 2026-05-08

  Add @container-size utility

• tailwindcss 4.3.0, shipped package — `@container-size` compiles to `container-type: size`.
• tailwindcss 4.2.4, shipped package — `@container-size` compiles to nothing, while `@container-[size]` already compiles to the same declaration.

Task 3: "zoom-50 — not a core utility that I know of. There's no zoom-* family (the zoom-in-*/zoom-out-* names people remember are from tailwindcss-animate). Write [zoom:0.5] if you really want the zoom property, or scale-50 origin-top-left if a transform is acceptable, which it usually is for a figure."

Same review-direction cost as F1 and F2, with one extra wrinkle worth flagging: the two replacements offered are not equivalent to each other or to the original. [zoom:0.5] emits zoom: 0.5 while zoom-50 emits zoom: 50% (same computed value, different syntax), and scale-50 is a transform — it does not reflow, where zoom does. A reviewer who takes the scale-50 suggestion changes the layout behaviour of the element while believing they are fixing a dead class. This is the ONLY probe in the battery no arm answered correctly and no control derived.

[zoom:1.5] and scale-50 were both compiled at 4.2.4 and 4.3.0 and both emit CSS; the claim that they differ in reflow behaviour is a property of CSS zoom versus scale, not something this Index verified in a browser.

• tailwindcss v4.3.0 release notes — Added published 2026-05-08

  Add zoom-* utilities

• tailwindcss 4.3.0, shipped package — `zoom-50` compiles to `zoom: 50%` and `zoom-[1.5]` to `zoom: 1.5`.
• tailwindcss 4.2.4, shipped package — `zoom-50` and `zoom-[1.5]` compile to nothing.

Task 4(a), one word: "No". Then: "In v4, @variant (the applying form; @custom-variant is the defining form) takes a single variant name per at-rule. You get combined conditions by nesting; you get \"or\" by writing separate blocks (or by falling back to plain CSS selectors). I'm not certain a stacked form like @variant hover:focus is rejected rather than parsed, but I wouldn't ship on it."

S3, and the severity is the interesting part. The nested workaround this draw wrote for the AND case compiles at 4.3.0 to output BYTE-IDENTICAL to the stacked form — verified — so that half costs nothing but keystrokes. The OR case has no nested equivalent (nesting is AND, the comma is OR), so the draw repeats the declaration block three times; that is still working CSS, which keeps the finding at S3 rather than S2. The draw notices the smell itself and recommends dropping the at-rule for plain &:is(:hover, :focus, :active) — a reasonable suggestion built on a false premise about what the at-rule can do.

The nested and stacked forms were compiled at 4.3.0 and their output compared: identical. At 4.2.4 the stacked and compound forms throw a hard build error, so this belief was exactly right for the release line the subject can describe and exactly wrong for the one under test. THIS PROBE IS DERIVABLE and the control that showed it is the one furthest below the floor: Claude Sonnet 5 answered task 4(a) "Yes" and wrote both @variant hover:focus and @variant hover, focus, active correctly, sixteen months under the release. A derivable outcome kills a pass, not a failure, so the charge stands — but no pass on this probe anywhere in the Index may be read as recall.

• tailwindcss v4.3.0 release notes — Added published 2026-05-08

  Allow using @variant with stacked variants (e.g. @variant hover:focus { … })

• tailwindcss v4.3.0 release notes — Added published 2026-05-08

  Allow using @variant with compound variants (e.g. @variant hover, focus { … })

• tailwindcss 4.3.0, shipped package — `@variant hover:focus { … }` compiles, to output byte-identical to the nested form; `@variant hover, focus, active { … }` compiles to three separate rules.
• tailwindcss 4.2.4, shipped package — both spellings throw `Cannot use @variant with unknown variant`; the single-variant and nested forms compile.