Andreas Reinhold / reiniandClaude Opus 5
24eb811f34
2.0.0 took Tailwind out of the stack, but the texts Boost copies into every application still taught its utilities: the core guideline said "built on Tailwind CSS", the always-on material-3 guideline wrote every rule as `bg-primary`, `type-*`, `rounded-corner-*`, `state-layer` and `medium:`, and both skills' tables and examples did the same. None of those classes exists in 2.0's stylesheets, so an agent following the guideline wrote markup that compiled to nothing. Found moving ReStride onto 2.0: its CLAUDE.md, and SealShare's, carry these texts. The guidelines and skills now teach what 2.0 has: component and layout component props (`gap="space200"`, `hide-from="medium"`), the `md-type-*`, `md-ink-*` and interaction classes, and `--md-sys-*` tokens in the application's own CSS, with breakpoints as range media queries. UPGRADE.md §1, §2 and §4 describe the finished move instead of the in-between state, and header comments that pointed at the removed tokens/utilities.css and tailwind.css, or called a component "still Tailwind", say what is true now. BoostVocabularyTest runs DesignGuard over the code in every shipped guideline and skill (fenced Blade and CSS, and each inline class list), so a text that teaches a class the stylesheets do not define fails the suite; it finds 268 violations in the texts as 2.0.0 shipped them. The guard's own table of what it reports is exempt. BoostResourcesTest now asks the design skill for each breakpoint's prop value and media query instead of the removed `medium:` variants. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
40 lines
2.2 KiB
CSS
40 lines
2.2 KiB
CSS
/*
|
|
* Livewire Material — the foundation, the one stylesheet every application imports, first:
|
|
*
|
|
* @import '../../vendor/nonameweb/livewire-material/resources/css/foundation.css';
|
|
* @import './material-scheme.css';
|
|
*
|
|
* Plain CSS, no build step of its own: an application's bundler (Vite) inlines the imports, and a
|
|
* browser could read the files as they are.
|
|
*
|
|
* Every rule of the package sits in a sub-layer of `material`, in this order, lowest first:
|
|
*
|
|
* material.reset foundation/reset.css — the browser's defaults taken back
|
|
* material.tokens foundation/tokens.css — every `--md-sys-*` and `--md-ref-*` property
|
|
* material.base foundation/base.css, foundation/interaction.css — the page, the font
|
|
* face, and md-state-layer, md-focus-ring, md-touch-target, md-link
|
|
* material.layout the layout components: scaffold, panes, the canonical layouts
|
|
* material.components the components
|
|
* material.text text.css — md-type-*, md-ink-*, and the few classes for text
|
|
* material.visibility hiding an element below or from a breakpoint, over a component's display
|
|
*
|
|
* Every package stylesheet opens with the same layer statement, before its imports, so the order
|
|
* holds whichever file a bundler reaches first. An application's own CSS is unlayered and
|
|
* 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;
|
|
|
|
@import './foundation/reset.css';
|
|
@import './foundation/hidden.css';
|
|
@import './foundation/tokens.css';
|
|
@import './foundation/base.css';
|
|
@import './foundation/interaction.css';
|
|
@import './text.css';
|