()` host, or an App that overrides `Shell`. Two things: forgetting the first renders structurally correct components with **no styling at all**, and forgetting the second leaves the page light whatever the reader chose. **1. Take the kit into your stylesheet.** One line in `Styles/app.css`, in place of `@import "tailwindcss";`: ```css @import "./vendor/rask-ui.css"; ``` Your app then compiles **one stylesheet** — Tailwind, the kit's theme, its `dark` variant, and the classes the kit's components write, beside the classes you write — exactly as a [Flux](https://fluxui.dev) app's one Tailwind build scans Flux's own views. The kit's class names are C# string literals inside a compiled assembly, where no scan can find them, so the package ships them as a list and the import reads it. There is nothing to set in the `.csproj`. The build sees the import, writes the kit's Tailwind sources into `Styles/vendor/` before Tailwind runs — `rask-ui.css`, `rask-ui.kit.css` and `rask-ui.classes.txt`; generated, not committed, no npm — and records in the assembly that the kit is already in the app's sheet. [The Tailwind guide](https://rask.sh/docs/guides/tailwind/#what-a-new-project-starts-with) walks through the four lines of `rask-ui.css`, and how to write them out yourself when you want Tailwind without its preflight or a layer of your own. **2. Link that sheet, with the dark-mode script before it** — the only code that runs ahead of the first paint, so the only place a dark page can start dark: ```csharp protected override Component? HeadAssets => [ Ui.AppearanceScript, Link.Rel("stylesheet").Href(LiveOptions.PathBase + "/css/app.css"), ]; ``` **The layer order is one statement, and the import owns it.** `rask-ui.css` opens with ```css @layer properties, theme, base, components, rask, utilities; ``` which puts your utilities above Tailwind's preflight and above the kit's own rules — a browser orders `@layer` names by *first appearance* and nothing later can reorder a name already placed, which is why the import is the first line of your sheet. `OneStylesheetCascadeTests` holds the order in a compiled app sheet, and `UiLayerOrderTests` in the kit's precompiled one. ### One sheet, never two The kit also compiles a sheet of its own (`UiStylesheet.Css`, or `UiStylesheet.Href()` after `true` writes it to `wwwroot/css/rask-ui.css`). **That sheet is for a surface with no Tailwind build of its own** — `Rask.DevTools` inlines it into a panel drawn inside somebody else's page; an app that draws only with `Ui.*` components and writes no utilities can link it and run no Tailwind at all. It must not sit in a document beside an app's own Tailwind output, which is how every Rask app used to be wired. Both sheets put utilities in `@layer utilities`, CSS layers do not merge across `` elements in any way that source order inside a sheet can settle, and the kit's `dark` variant is a `:where()` with no specificity of its own. So between a kit **variant** and any base utility the app wrote *anywhere*, layer and specificity tie and link order decides — the app's sheet, linked last: | the kit's component writes | the app writes, on some other element | computed, with two sheets | |---|---|---| | `bg-white dark:bg-white/4` (Flux's card) | `bg-white` | `rgb(255, 255, 255)` in dark mode | | `text-zinc-500 dark:text-zinc-300` | `text-zinc-500` | zinc-500 in dark mode | | `flex-col sm:flex-row` | `flex-col` | a column at every width | Measured on rask.sh, with every class in the markup correct and every gate green. In one sheet each of those utilities exists once and Tailwind's own order holds — a base utility before its variants, a shorthand before its longhands — so the build **refuses** the pairing: `RaskUiWriteStylesheet` in a project that compiles its own Tailwind stylesheet is an error that names the line to write instead. ## Dark mode Dark mode is [Flux UI's](https://fluxui.dev/docs/dark-mode): a `dark` class on ``, and `dark:` utilities that follow it. There is no theme list and no theme picker. `RaskApp` and the WASM host write `Ui.AppearanceScript` at the top of every page's head, as Flux's layout writes `@fluxAppearance`. A hand-wired host puts it in the root component's head assets, **before the stylesheets** (an App that still writes its own gets exactly one — its own, with its key): ```csharp protected override Component? HeadAssets => [Title["…"], Ui.AppearanceScript, /* stylesheets */]; ``` It runs before the first paint, so a dark page starts dark. The reader's **appearance** is `light`, `dark` or `system` — `system` is the default, follows `prefers-color-scheme` while the page is open, and is stored as no key at all; the other two are kept in `localStorage` under `rask.appearance` (`.StorageKey("…")` to change it). Only those exact words are a choice: anything else in storage means system. The class is put back after every morph, and another tab's change is followed. A control needs two properties, the ones Flux documents as `Flux.appearance` and `Flux.dark`: ```js Rask.appearance = 'light' | 'dark' | 'system' // get or set the reader's preference Rask.dark = true | false // get or set whether the page is dark right now ``` So a toggle is one line and **no C# handler** — it works before the app has booted, and costs no handler id (ids are positional, and one handler in every page's chrome moves every id after it): ```csharp Button.Type(ButtonType.Button).AriaLabel("Toggle dark mode") .Attributes(("onclick", "Rask.dark = !Rask.dark"))[Ui.Icon.Name(Ui.IconName.Moon).Mini] ``` That is the moon in rask.sh's own top bar. A Light / Dark / System menu sets `Rask.appearance` the same way. The kit's import already points `dark:` at the class, as Flux does — `@custom-variant dark (&:where(.dark, .dark *));` — and `.dark` also says `color-scheme: dark`, so scrollbars, native controls and `light-dark()` turn with the page. Nothing else switches it: there is no theme attribute and no operating-system arm outside the script. ### Re-skinning Two colours, per [Flux's theming](https://fluxui.dev/docs/theming). The **base** is Tailwind's `zinc` scale, written directly in the components, so an app changes every gray by re-pointing it in its own `@theme`: ```css @theme { --color-zinc-50: var(--color-slate-50); /* … 100 through 900 … */ --color-zinc-950: var(--color-slate-950); } ``` The **accent** is three variables, Flux's own names — the fill of a primary action (`--color-accent`), the same hue as readable text (`--color-accent-content`), and the text on the fill (`--color-accent-foreground`) — with a second set under `.dark`. Written after the kit's import, yours win over the kit's zinc defaults: ```css @theme { --color-accent: var(--color-red-500); --color-accent-content: var(--color-red-600); --color-accent-foreground: var(--color-white); } @layer theme { .dark { --color-accent: var(--color-red-500); --color-accent-content: var(--color-red-400); --color-accent-foreground: var(--color-white); } } ``` The utilities follow: `bg-accent`, `text-accent-content`, `text-accent-foreground`, `border-accent`, and `var(--color-accent)` in an arbitrary value. ### The typeface The kit is drawn in [Inter](https://github.com/rsms/inter), as Flux is, and `Ui.Chart` lays its labels out with Inter's metrics. Its theme names `"Inter"` first in `--font-sans` — the face Tailwind's preflight, the kit's own document reset and the `font-sans` utility all read — with the system stack after it, and its `@font-face` rules serve the variable face (every weight) from `/fonts/inter-latin.woff2` and, for text outside latin such as Hungarian's ő and ű, `/fonts/inter-latin-ext.woff2`. **Every app's build copies the two files into `wwwroot/fonts`**, with the OFL notice as `wwwroot/fonts/inter.LICENSE.txt`; in a one-project WebAssembly app the browser half writes them, as it does the editor's engine. An app that draws in another face re-points the token in its own `@theme`, and one that serves Inter itself turns the copy off: ```xml false ``` ```css @theme { --font-sans: "Geist", ui-sans-serif, system-ui, sans-serif; } ``` ## Buttons `Ui.Button` is [Flux's button](https://fluxui.dev/components/button) and `Ui.ButtonGroup` its `button.group`, measured against Flux's own page in light and in dark. A variant, a size and a colour are steps: ```csharp Ui.Button["Cancel"] // the outline — Flux's default Ui.Button.Primary["Save"] // filled with the accent; one per view Ui.Button.Filled["Edit"] // a tinted fill, no border Ui.Button.Danger["Delete"] // red Ui.Button.Ghost["More"] // no surface until hovered Ui.Button.Subtle["Skip"] // a ghost with a muted label Ui.Button.Sm["Small"] // 32px tall; 40px without a size Ui.Button.Xs["Extra small"] // 24px Ui.Button.Primary.Blue["Deploy"] // any Tailwind hue: Ui.Color Ui.Button.Red["Remove"] // on the outline it tints the label, the border and the hover ``` An icon is a prop, which is what lets the button pad itself around it — 12px on the icon's side, 16px on the other — and size the drawing: 16px beside a label, 20px alone. ```csharp Ui.Button.Icon(Ui.IconName.ArrowDownTray)["Export"] Ui.Button.IconTrailing(Ui.IconName.ChevronDown)["Open"] Ui.Button.IconTrailing(Ui.Badge.Sm["3"])["Categories"] // Flux's iconTrailing slot: content in the icon's place Ui.Button.Icon(Ui.IconName.XMark).AriaLabel("Close") // no children: a square. Name it. Ui.Button.Icon(Ui.IconName.Cog6Tooth).Tooltip("Settings") // a tooltip names it too: Flux's wrapper, by aria-labelledby Ui.Button.Icon(Ui.IconName.Moon).Tooltip("Toggle dark mode").TooltipKbd("D").TooltipPosition(Ui.TooltipPosition.Bottom) ``` ```csharp Ui.Button.Primary.Class("w-full")["Send invite"] // full width is a class, as in Flux Ui.Button.Ghost.Sm.Icon(Ui.IconName.XMark).Inset(Ui.Inset.All) // pulled out by its invisible padding Ui.Button.Type(Ui.ButtonType.Submit)["Sign in"] // `type="button"` unless you say so Ui.ButtonGroup[Ui.Button["Oldest"], Ui.Button["Newest"], Ui.Button["Top"]] // fused: one border between each pair ``` | Prop | What it takes | | --- | --- | | `Variant` | `Ui.ButtonVariant`: `Outline` (default) `Primary` `Filled` `Danger` `Ghost` `Subtle` | | `Size` | `Ui.ButtonSize`: `Base` (default) `Sm` `Xs` | | `Color` | `Ui.Color`: Tailwind's seventeen hues, `Red` … `Rose`, and its five grays. A hue recolours every variant but `Danger`; a gray changes only `Primary` | | `Icon`, `IconTrailing` | a `Ui.IconName`; `IconVariant` picks another drawing of it. `IconTrailing` also takes a component — Flux's `iconTrailing` slot — placed as it is where the icon would stand, the button padded as around an icon. One step: naming an icon AND handing content in one chain is RASK044 | | `Square` | as wide as tall. Automatic with an icon and no children; `Square(false)` turns that off | | `Align` | `Ui.Align.Start` / `Center` / `End`, for a button wider than its content | | `Inset` | `Ui.Inset` flags — `Top`, `Bottom`, `Left`, `Right`, `All` — for a ghost or subtle button | | `Loading` | see [Buttons that wait](#buttons-that-wait) | | `Tooltip`, `TooltipPosition`, `TooltipKbd` | Flux's shorthand: the button is wrapped in a [`Ui.Tooltip`](#tooltips) that says this, on that side (`Ui.TooltipPosition`), with that shortcut after it. It names a button that has only an icon (`aria-labelledby`), and still fuses inside a `Ui.ButtonGroup` | | `Kbd` | a shortcut drawn inside the button, after its label: `Ui.Button.Kbd("esc")["Cancel"]` | | `Href` | see [Buttons and links that go somewhere](#buttons-and-links-that-go-somewhere) | | `As` | `Ui.ButtonAs.Div` for the look of a button on something that is not one | | `Type`, `Disabled`, `Command`, `CommandFor` | the `