Take Tailwind out of the package, and its detection out of the guard

Tailwind left the stack in 2.0.0, but the package still carried about 330
mentions of it. What the guard's Tailwind detection protected — a class
that compiles to nothing — is now protected by a check that does not care
where a dead class came from.

DesignGuard: about 500 lines of Tailwind tables, scales, palettes and
"2.0.0 replacement" hints give way to one check — a class a view or PHP
file writes that neither the application's stylesheets nor the package's
own declare. It catches a utility of any framework, a typo and a class
whose rules were deleted alike, so it also found two classes ReStride
draws nothing with. A stylesheet has to be in reach for it: the `.css`
files among the scanned paths, or what the `missingStylesheets()` entry
imports. The class reader no longer mistakes an array index for a class
list (`$block['base']`), and it reads the array a class helper is given,
where it read nothing before.

The package's own three Tailwind self-guards go with it. Only their one
unique check stays, as a test of its own: every `matchMedia` width in
resources/js is an M3 breakpoint.

The pagination views are `material.blade.php` and
`simple-material.blade.php`; only Laravel's and Livewire's default theme
names ever made them `tailwind`. The provider sets `Paginator`'s default
views and switches `livewire.pagination_theme` to `material` when it is
still Livewire's own default, so no application can forget the config; a
theme an application chose, and a component's own `$paginationTheme` or
`paginationView()`, still win.

The rest is prose: the layer-order guidance for an application that still
builds Tailwind, the Tailwind wording in the README, the Boost guidelines
and the development skill, and about 25 "this used to be a Tailwind
utility" comments, along with every "plan step NN" pointer into a
gitignored folder. The reset keeps its credit, and NOTICE now carries it
too.

Feature suite 1159 passed, Chrome browser suite 299 passed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

resources/css/all.css

@@ -1,9 +1,9 @@
 /*
  * Livewire Material for an application that wants everything: the foundation, every layout
  * stylesheet and every component stylesheet, each imported once. The blocks below are the same
- * groups `components.css` and `layout.css` used before this file replaced both of them (plan step
- * 37) — one block per group, so a stylesheet still lands in a predictable place — plus the
- * Layout block those two files didn't share.
+ * groups `components.css` and `layout.css` used before this file replaced both of them — one
+ * block per group, so a stylesheet still lands in a predictable place — plus the Layout block
+ * those two files didn't share.
  *
  * This is not the recommended way to bring the package's CSS in: importing `all.css` pulls in
  * every component's rules whether an application's views render them or not. The recommended path

resources/css/components/error-page.css

@@ -20,10 +20,10 @@
  * The page carries this file itself: `src/Support/ErrorPage.php` inlines it, with its imports, into
  * every error page (`Stylesheets::bundle()`) — beside the application's Vite tags when there is a
  * build (`layoutStyles()`), inside the whole fallback stylesheet when there is none
- * (`fallbackStyles()`, plan step 40) — so an application imports nothing for its error pages
- * (plan step 46). The body is still matched only when it holds the layout
- * (`body:has(> [data-md-error-page])`): an application that imports `all.css` has this file in
- * its bundle beside every other page, where a bare `body` rule would restyle them all.
+ * (`fallbackStyles()`) — so an application imports nothing for its error pages. The body is still
+ * matched only when it holds the layout (`body:has(> [data-md-error-page])`): an application that
+ * imports `all.css` has this file in its bundle beside every other page, where a bare `body` rule
+ * would restyle them all.
  *
  * The page's font is the foundation's, `--md-ref-typeface-brand` on `html` (foundation/base.css),
  * as the old `font-sans` was; only the fallback, which has no `@font-face`, uses a system stack.

resources/css/components/navigation-bar.css

@@ -78,14 +78,11 @@
      * A bar that has slid off the bottom of the window is no longer there to clear, so the offset
      * everything pinned to the bottom reads drops to the bottom safe area and whatever the
      * application has docked on the bar — a `fab` button, the snackbar and the page's own bottom
-     * padding all follow it down and come back up with it. Layered now, unlike before this
-     * rewrite: <x-scaffold> used to publish --material-bottom-bar with a Tailwind utility, which
-     * no rule in any layer could outrank regardless of specificity; now scaffold.css publishes it
-     * itself in `material.layout` (layout/scaffold.css), a layer this file's own
-     * `material.components` always outranks by declaration order alone — the same reason
-     * toolbar.css's and fab.css's overrides only have to beat another `material.components` rule,
-     * not chase a Tailwind utility out of the cascade. Keyed on `data-md-scaffold`, the hook the
-     * scaffold renders on its root, not `data-app-shell`, which that rewrite also retired.
+     * padding all follow it down and come back up with it. `<x-scaffold>` publishes
+     * `--material-bottom-bar` itself, in `material.layout` (layout/scaffold.css), a layer this
+     * file's own `material.components` always outranks by declaration order alone — the same
+     * reason toolbar.css's and fab.css's overrides only have to beat another `material.components`
+     * rule. Keyed on `data-md-scaffold`, the hook the scaffold renders on its root.
      */
     [data-md-scaffold]:has([data-md-navigation-bar][data-md-hide-on-scroll][data-md-hidden]) {
         --material-bottom-bar: calc(var(--material-safe-bottom, env(safe-area-inset-bottom)) + var(--material-bottom-extra, 0px));

resources/css/components/pagination.css

@@ -1,7 +1,8 @@
 /*
- * The paginators, Laravel's and Livewire's, drawn in M3 (resources/views/pagination/**): the package
- * puts its views in front of the frameworks' `tailwind` and `simple-tailwind` ones, whose names they
- * keep.
+ * The paginators, Laravel's and Livewire's, drawn in M3 (resources/views/pagination/**): named
+ * `material`/`simple-material`, put in front of the frameworks' own namespaces and set as
+ * Laravel's default view (`Paginator::defaultView()`/`defaultSimpleView()`) and, where Livewire
+ * still reads its own default, as its `pagination_theme`.
  *
  * The numbered paginator is a row: on its start, what the page holds in body-small on-surface-variant
  * — "21–30 of 95", or "Page 3 of 10" below `medium` (600px), where the page numbers give way and only

resources/css/foundation.css

@@ -24,10 +24,6 @@
  * therefore outranks every package rule, whatever the selector — an application's broad selector
  * (`button { … }`) restyles the components too. foundation/hidden.css keeps its two `!important`
  * rules outside the layers, so `hidden` and `x-cloak` hide an element whatever sets its display.
- *
- * An application still building Tailwind keeps it in a separate entry and opens both entries with
- * `@layer properties, theme, base, material, components, utilities;`, so the `material` layers sit
- * above Tailwind's preflight and below its utilities.
  */
 
 @layer material.reset, material.tokens, material.base, material.layout, material.components, material.text, material.visibility;

resources/css/foundation/base.css

@@ -11,7 +11,7 @@
  * Text is smoothed in grayscale where a platform offers the choice (macOS browsers): Google Sans
  * Flex is drawn for it, and subpixel smoothing thickens its strokes on light text over a dark
  * surface. Every surface the package draws — the showcase, the error pages — is set this way,
- * and so is an application, which drops Tailwind's `antialiased` class with nothing to replace.
+ * and so is an application, with no class of its own needed.
  *
  * In `material.base`, above the reset and below every component and text class.
  */

resources/css/foundation/reset.css

@@ -2,10 +2,10 @@
  * The reset: what a browser draws before any stylesheet, taken back to a clean start.
  *
  * Rule for rule the reset the components were built on, Tailwind CSS 4's preflight (MIT,
- * © Tailwind Labs, after modern-normalize), so a component looks the same whether an application
- * still builds Tailwind or not: every box `border-box` with a `0 solid` border and no margin or
- * padding, headings and lists unstyled, form controls inheriting font, colour and tracking with no
- * background or radius, media as blocks that never overflow their parent. Three differences:
+ * © Tailwind Labs, after modern-normalize): every box `border-box` with a `0 solid` border and no
+ * margin or padding, headings and lists unstyled, form controls inheriting font, colour and
+ * tracking with no background or radius, media as blocks that never overflow their parent. Three
+ * differences:
  *
  *   - no typeface here: foundation/base.css sets `--md-ref-typeface-brand` on <html>;
  *   - a placeholder is `on-surface-variant`, the colour of M3's text field placeholder (androidx

resources/css/layout/pane.css

@@ -21,7 +21,7 @@
  * way it goes, so it mirrors in a right-to-left document (§ Layout → Bidirectionality / RTL).
  *
  * In `material.layout`; `hide-below`/`hide-from` come from visibility.css. Imports app-bar.css and
- * button.css for the pane's own top app bar and its back button (plan step 36 carry-over).
+ * button.css for the pane's own top app bar and its back button.
  */
 
 @layer material.reset, material.tokens, material.base, material.layout, material.components, material.text, material.visibility;

resources/css/layout/scaffold.css

@@ -2,9 +2,7 @@
  * <x-scaffold>: M3's scaffold — bars, then rails, then panes (docs/reference/m3/foundations.md
  * § Layout → Scaffold) — as a column: an optional `banner` full width, a row below it holding the
  * adaptive navigation rail and the content region, the bottom navigation bar on a compact window,
- * and the snackbar host. Plan step 36 (navigation group) moves in everything the view drew with
- * Tailwind; `data-md-scaffold-fab` and the content region's `--md-layout-margin` are step 35's,
- * unchanged below.
+ * and the snackbar host.
  *
  * `--material-margin` is M3's window margin, which the content region pads itself with and an
  * application's own rules can read: 16px below `medium`, 24px from it
@@ -23,11 +21,11 @@
  * `[data-md-scaffold-content]` — the rail's sibling — is always a flex column, so the page's own
  * bar, the FAB wrapper and `<main>` stack regardless of the row's own display.
  *
- * `[data-md-scaffold-actions]`'s column layout is `rail-collapsed:flex-col`, the one Tailwind
- * variant scaffold.blade.php still used (`resources/css/tailwind.css`, removed with this rule): the
- * actions row is always inside a rail, never the rail element itself, so it reads
- * `--md-navigation-rail-value` with `@container style()` like any other application content does
- * (`resources/css/components/navigation-rail.css`), rather than copying the rail's own conditions.
+ * `[data-md-scaffold-actions]`'s column layout comes from a container style query on
+ * `--md-navigation-rail-value: collapsed`: the actions row is always inside a rail, never the rail
+ * element itself, so it reads that property with `@container style()` like any other application
+ * content does (`resources/css/components/navigation-rail.css`), rather than copying the rail's
+ * own conditions.
  *
  * `[data-md-scaffold-bar]` pins the navigation bar to the window's bottom edge below `medium`, at
  * z-index 30: over the page, under the rail's scrim (40) and the snackbar (50, toast.css). While a
@@ -38,8 +36,7 @@
  * (toast.css), a placed toolbar (toolbar.css) and the content region's bottom padding. Without a
  * bar, or from `medium`, the scaffold publishes nothing and each reader falls back to 0px. A bar that has slid
  * away on scroll drops its own height from the variable (navigation-bar.css); that rule wins
- * because `material.components` comes after this file's `material.layout`, where before this
- * rewrite the variable was a Tailwind utility and the override had to sit outside every layer.
+ * because `material.components` comes after this file's `material.layout` in the cascade.
  *
  * The content region's `<main>` is matched as the content wrapper's own child, so a `<main>` an
  * application nests inside the page takes none of the region's padding or clipping.

resources/css/showcase.css

@@ -1,7 +1,7 @@
 /*
  * The showcase's own chrome: what its pages draw beyond the layout components, the `md-*` text
- * classes and the shared interaction classes (plan step 38) — the rail's wordmark, the search box
- * and its results, a keyboard key in running text, an example's card and its code sample, and the
+ * classes and the shared interaction classes — the rail's wordmark, the search box and its
+ * results, a keyboard key in running text, an example's card and its code sample, and the
  * foundation pages' specimens: a colour swatch, a type-scale row, a corner swatch, an elevation
  * tile, a motion track and its dot, an icon search result and the Layout page's breakpoint cards.
  *