/* The site's whole stylesheet, as one file — the only <link> any page needs.
   `src/content/_layout/head.html` links it, and every page gets that partial spliced in at
   build time, so a page can't be missing a style. See frontend/design-system.md.

   ## Why one file

   Every page used to hand-list 6–13 individual <link> tags, and they had drifted: the shape
   reference pages omitted displays.css, and videos/pdf-lessons/color-graphing each ordered
   theirs differently. A page silently missing a stylesheet is a visual bug nobody notices,
   which made per-page style lists a worse deal than they looked.

   Bundling doesn't just remove that failure mode, it's also *faster* here. The whole thing is
   ~40KB unminified — smaller than a single photo — and it's one request cached across the
   entire site, where per-page lists meant every new page pulled a different subset. Second
   page load now fetches no CSS at all.

   ## Why @import rather than concatenating at build time

   @import needs no build machinery whatsoever: this file is served as-is by both
   webpack-dev-server (devServer.static) and Rack::Files, so dev and production behave
   identically. Concatenating would mean a generated file that also has to exist for the dev
   server, which buys either a staleness footgun or a new build step — and dev/prod divergence
   is the same objection that ruled out splicing the header nav server-side.

   Yes, @import serializes discovery: the browser must parse this file before it learns about
   the 19 below, costing one extra round trip on a cold load. That's the textbook argument
   against @import and it's immaterial at this size. Will's call, and the reasoning is worth
   keeping: *"if one day our styling becomes so big that it has performance problems for
   people, we can then start to split it up again. But let's not solve a problem we don't
   have."* If that day comes, the fix is to split this file — not to go back to per-page lists.

   ## Order matters

   These are cascade-ordered, not alphabetical, and the grouping is the load order every page
   used to hand-maintain: tokens first (everything else reads its custom properties), then
   element defaults, then layout/typography, then components, then the page-specific sheets
   that override components (color-graph-viewer.css deliberately overrides buttons.css for its
   dark overlay). Adding a sheet means putting it in the right group, not at the end. */

/* Tokens — colors, spacing, dark mode. Must come first: everything below reads these. */
@import "variables.css";

/* Element-level defaults and page-wide typography/layout primitives. */
@import "base.css";
/* The page surface's texture. Directly after base.css, which sets the background color it
   sits on top of, and before everything that draws on top of it. */
@import "board.css";
@import "typography.css";
@import "layout.css";
@import "padding-and-margins.css";
@import "displays.css";

/* Shared components of the design system. */
@import "header.css";
@import "buttons.css";
@import "forms.css";
@import "alerts.css";
@import "cards.css";
@import "tables.css";

/* Page/feature-specific sheets. These come last so they can override the components above. */
@import "home.css";
@import "cartesian-plane.css";
@import "base-conversion.css";
@import "quiz.css";
/* After quiz.css, which it reframes rather than replaces — every rule in it is scoped under
   `.quiz-window` and has to win over the flowing-page version of the same component. */
@import "quiz-window.css";
@import "video.css";
@import "pdf-lesson.css";
@import "color-graph-input-panel.css";
@import "color-graph-viewer.css";