Styling

Three modes

The behavior contract is the same in every mode. A tab list works the same way whether it is unstyled, styled by the package or styled by a file you own, because the behavior reads and writes attributes (aria-selected, hidden) and never a class name.

Mode 1: your own CSS

Write CSS against the protocol attributes and the platform's own state selectors. Nothing from this package is required, and the markup carries no class name that a stylesheet has to know.

/* Mode 1: your own CSS. Target the protocol attributes and platform state directly;
 * nothing from @svelte-lean/styles is required. */
[data-slean='button'] {
	padding: 0.5rem 1rem;
	border: 1px solid currentColor;
	border-radius: 4px;
}

[data-slean='button'][data-variant='outline'] {
	background: transparent;
}

[data-slean='tabs'] [role='tab'][aria-selected='true'] {
	border-bottom: 2px solid currentColor;
}

[data-slean='dialog']::backdrop {
	background: rgb(0 0 0 / 0.4);
}

Mode 2: package CSS

Import the tokens, the base file and only the primitive files you use. This is the documented default and the path this site takes for its own controls.

// Mode 2: the package, one file per primitive. tokens.css and base.css are required by every
// primitive file; import only the primitives your markup uses. A file that builds on another
// imports it itself: menu.css brings popover.css, select.css brings control.css.
import '@svelte-lean/styles/tokens.css';
import '@svelte-lean/styles/base.css';
import '@svelte-lean/styles/button.css';
import '@svelte-lean/styles/dialog.css';
import '@svelte-lean/styles/menu.css';

// Everything, for a prototype or when most primitives are in use. Not the primary path.
import '@svelte-lean/styles';

Mode 3: owned styles

Copy a primitive's stylesheet into the application and edit it there; the behavior stays in the package. The steps, and the status of the planned command, are on Owned styles.

Entry points

Every file is a subpath export of the package, listed here from its package.json. Sizes are read from packages/styles/artifacts/size.json, written by the package's yarn size (gzip level 9, brotli quality 11 of the minified text). tokens.css and base.css are required by every primitive file. A file that builds on another imports it itself, so every file works when it is the only one imported: the Imports column lists those files, read from the stylesheets. A bundler includes a file imported twice once; without one, the second copy changes nothing, because the imported rules sit in an earlier layer (or, for the control shell, a sublayer) than the rules of the file that imports them.

bytes = shipped source; minified = comments and redundant whitespace removed by scripts/check.mjs minify (a bundler minifier may be slightly smaller); gzip level 9 and brotli quality 11 of the minified text. standalone = the file with the files it @imports inlined. "index.css (resolved)" inlines every @import once, depth first, and carries the budget.

Layers and specificity

All rules live in six cascade layers, and every selector is wrapped in :where(), which contributes no specificity. The order is declared at the top of every file, so the order in which you import primitive files does not matter. A stylesheet that restyles another primitive (a menu is a popover, a button group joins buttons, a toolbar flattens toggles, a context menu places a menu, a date picker lays out a calendar) keeps its rules in slean.compositions, after slean.components: it wins even where a bundler loads the restyled file later. The field shell every owned form control shares (control.css) sits in the sublayer slean.components.shell, below every rule of the component files.

/* Every file starts with the same layer statement, so import order between primitive files
 * does not matter. Every rule sits inside its layer and every selector is wrapped in :where(). */
@layer slean.reset, slean.tokens, slean.base, slean.components, slean.compositions, slean.utilities;

@layer slean.components {
	:where([data-slean='button']) {
		min-block-size: var(--slean-control-height-md);
		border-radius: var(--slean-radius-md);
		background: var(--slean-accent);
	}
}

Because layered rules lose to unlayered ones regardless of specificity, an override is a plain rule in your own stylesheet. No !important, no selector escalation.

/* An unlayered rule in your application wins over the package, whatever its specificity. */
[data-slean='button'] {
	border-radius: 0;
}

The reset touches only elements that carry data-slean or data-slean-part. Content nested inside a primitive, such as the body of a dialog or a tab panel, keeps the page's own styles: a global h2 rule applies to a <h2 data-slean-part="title"> as it applies anywhere else.

What is not provided

• No Tailwind dependency, no CSS-in-JS, no runtime style injection. The package works next to Tailwind CSS: Tailwind CSS gives the layer order and the token mappings.
• No JavaScript. The package is the files in css/; a change of theme is a change of token values, applied by the cascade.
• No Provider. Theme values belong in CSS, behavior routing attaches to the document, so no component has to wrap the application (Themes).
• No positioning engine. Popovers and menus are placed with CSS anchor positioning and keep the platform's default placement where it is unsupported.
• No fonts. Controls inherit the page font; --slean-font-sans is defined for the page to apply if it wants the token stack.
• No mirrored state. Styles select on :checked, :disabled, [open], :popover-open and ARIA attributes, never on a data-state copy (Variants).

Source: packages/styles/css, the static checks in scripts/check.mjs and the package README.