/* Drawmetrics drawing workflow - shared page shell.

   Global rather than a `.razor.css` because TWO routes render this workflow and must stay identical:
   /drawings (the real assessment) and /try-drawmetrics (the public demo). Scoped stylesheets cannot be
   shared between components, and duplicating ~200 lines of measured values into a second file is how
   the two drift apart.

   Both pages opt in by putting `drawings-page portal-fullscreen-page` on their root and using the
   class names below. Every selector is anchored on `.drawings-page` - which is exactly what the Blazor
   scope attribute used to do - so specificity against MudBlazor's own rules is unchanged from when
   these values were measured against the running app.

   Loaded after MudBlazor.min.css in App.razor: several rules here rely on winning a specificity tie on
   source order. */

/* Single-screen drawing step, per the approved Drawmetrics design.

   The page root also carries `portal-fullscreen-page` (app.css), which sizes the MudLayout chain to
   the viewport and switches off the `min-height: 100vh` that normally makes every page scroll a
   little. From here down it is a flex column: progress rail, stepper (nav + canvas), actions. The
   canvas is the only elastic part, and it is sized through --drawing-pad-height rather than by
   percentage heights — the SignaturePad root element sits between this page and the <canvas> and
   does not carry a height of its own, so a percentage chain would collapse there.

   Every number below was measured in the browser against the running app rather than estimated;
   the comments record what each one is paying for. */

.drawings-page {
    /* Height left for the canvas once the app bar and the page's own chrome (progress rail,
       description block, action row and the gaps between them) are accounted for. Measured at
       1280x800: 266px of chrome plus an 81px description block leaves 453px, so 352px keeps the
       canvas 5px inside its budget instead of spilling into the content area's scrollbar. */
    --drawing-pad-height: clamp(150px, calc(100dvh - 352px), 450px);

    gap: 4px;
    padding: 4px 8px 8px;
}

/* Everything on this page is capped at the width of the drawing block (864px = 800px canvas + 24px
   gap + 40px palette) and centred with auto side margins, so closing the nav drawer does not leave
   the whole assessment hugging the left edge of a wide screen with 400px of dead space beside it.
   The header row is capped too, so "Progress - n of m" and Back stay on the block's own edges rather
   than drifting out to the corners of the viewport. */
.drawings-page .drawings-progress-row {
    display: flex;
    align-items: baseline;
    justify-content: space-between;
    gap: 16px;
    flex: 0 0 auto;
    width: 100%;
    max-width: 864px;
    margin-inline: auto;
}

.drawings-page .drawings-progress-caption {
    font-size: 0.875rem;
    font-weight: 600;
    color: var(--mud-palette-text-primary);
}

.drawings-page .drawings-back-link {
    display: inline-flex;
    align-items: center;
    gap: 4px;
    font-size: 0.8125rem;
}

/* The stepper owns the rest of the column. min-height: 0 is load-bearing on every level: a flex item
   defaults to min-height: auto and would refuse to shrink below its content, which is exactly how an
   over-tall canvas ends up pushing the action row past the bottom of the viewport. */
.drawings-page .drawings-stepper {
    flex: 1 1 auto;
    min-height: 0;
    display: flex;
    flex-direction: column;
}

.drawings-page .drawings-stepper .mud-stepper-content {
    flex: 1 1 auto;
    min-height: 0;
    padding: 0;
    /* Safety valve only. The clamp above is meant to keep the canvas inside its budget; if a future
       change (a taller description block, a browser with unusually large default controls) breaks
       that, the overflow scrolls here instead of turning into a page-level scrollbar. */
    overflow: auto;
}

/* --- Progress rail -------------------------------------------------------- */
/* The design shows numbered discs joined by thin lines and no step titles, so the titles are hidden
   rather than blanked out: MudStep still gets its Title, which keeps the nav buttons labelled for
   screen readers and preserves the click-a-disc-to-go-back navigation the built-in nav provides.

   Width is capped exactly like the action row below: the rail belongs to the canvas, and left
   unconstrained it ran the full content width, so the tail of the line and the last disc sat out past
   the canvas and across the palette column. 864px = 800px canvas + 24px gap + 40px palette; the 64px
   right padding then puts disc 10 on the canvas' right edge. */
.drawings-page .drawings-stepper-nav {
    flex: 0 0 auto;
    box-sizing: border-box;
    /* `width: 100%` is required, not redundant. The nav is a flex item of the stepper's column, so
       giving it auto side margins to centre it also cancels the default `align-self: stretch` — it
       collapsed to fit-content (measured 344px) and the rail floated in the middle of the block,
       detached from the canvas. */
    width: 100%;
    max-width: 864px;
    margin-inline: auto;
    padding: 4px 64px 10px 0;
}

.drawings-page .drawings-stepper-nav .mud-step .mud-step-label-content {
    display: none;
}

/* 28px on anything roomy, up from 22px: at 22 the discs read as small next to the canvas and the
   numbers were cramped.

   Fluid below that, because "it still fits" is not the same as "it still looks like a rail". At 28px
   fixed, ten discs take 280px of the 351px rail a 375px phone gives them, leaving 7px between
   neighbours — the connector line was technically drawn but read as the discs being fused together.
   The formula reserves ~12px per gap: rail is roughly the viewport less 24px of page padding, nine
   gaps at 12px is 108px, so the disc gets (100vw - 132px) / 10. Measured results: 320px -> 20px discs
   with 10px gaps, 375px -> 24px / 11px, 430px -> 28px / 13px, 768px -> 28px / 34px.
   The 20px floor stops it collapsing on a very narrow phone; the 28px ceiling means every viewport
   from about 412px up is unaffected, so this is purely a narrow-screen guard. */
.drawings-page .drawings-stepper-nav .mud-step .mud-step-label .mud-step-label-icon {
    box-sizing: border-box;
    width: clamp(20px, calc(10vw - 13.2px), 28px);
    height: clamp(20px, calc(10vw - 13.2px), 28px);
    font-size: 12px;
    font-weight: 600;
    /* MudBlazor gives the connector `margin: 0 -16px`, so each joining line deliberately runs 11px
       INTO the disc on both sides (measured: line 30->63 between discs at 17->41 and 52->76). The
       connector sits between its two steps in the DOM, so with everything at `position: static` it
       painted over the disc before it and under the disc after it — the line visibly cut through one
       side of every circle's outline. Lifting the disc into its own stacking position lets its opaque
       fill mask the line instead, so the line now stops cleanly at the circle edge on both sides. The
       geometry still overlaps; only the paint order changed, so the rail's spacing is untouched. */
    position: relative;
    z-index: 1;
}

/* Steps still to come. MudBlazor's default is a solid `--mud-palette-text-disabled` grey disc with a
   white number, which is why the rail read as washed out next to the design's crisp outlined discs.
   Repainted as surface-filled with a dark rim and a dark number.

   The `:not()` chain is what makes this safe. MudStepper colours the current, completed, error and
   skipped discs with an INLINE style (verified against the assembly: it emits
   `color:...;background-color:...` and tags the steps `active` / `mud-step-completed` /
   `mud-step-error` / `mud-step-skipped`). Inline wins over any rule here, so the background would be
   fine either way — but `color` is set inline too, and a blanket dark `color` would otherwise risk a
   dark number on a dark disc. Excluding the stateful discs outright removes the question. */
.drawings-page .drawings-stepper-nav .mud-step:not(.active):not(.mud-step-completed):not(.mud-step-error):not(.mud-step-skipped) .mud-step-label:not(.mud-step-label-active) .mud-step-label-icon {
    background-color: var(--mud-palette-surface);
    color: var(--mud-palette-text-primary);
    border: 2px solid var(--mud-palette-text-primary);
}

/* MudBlazor draws the joining line in `--mud-palette-lines-inputs`, a very light grey that all but
   vanished between the discs. */
.drawings-page .drawings-stepper-nav .mud-stepper-nav-connector-line {
    border-top-color: var(--mud-palette-text-primary);
    opacity: 0.35;
}

/* MudBlazor gives each step `padding: 24px`, which with the titles hidden makes a 70px slot per
   disc — 700px for ten of them. That fits a desktop rail and overflows a phone (measured 700px of
   scroll width inside a 406px nav on a 430px viewport, so steps 6-10 were off screen behind a
   sideways scroll). `flex: 1 1 0` makes every step take an equal share of whatever the rail is
   instead, so the discs spread evenly and the rail can never overflow at any width — no breakpoint
   guessing, and it survives the nav drawer opening and narrowing the content.
   The extra `.drawings-stepper` in the selector is not decoration: MudBlazor's own rule is
   `.mud-stepper .mud-stepper-nav .mud-step` at three classes, so a two-class override would only
   win on source order. */
.drawings-page .drawings-stepper .drawings-stepper-nav .mud-step {
    padding: 4px 0;
    flex: 1 1 0;
    min-width: 0;
    justify-content: center;
}

/* --- Action row ----------------------------------------------------------- */
/* MudStepper wraps ActionContent in `.mud-card-actions.mud-stepper-actions`, a flex row with 8px of
   horizontal padding. Zeroing it lets the row below line up with the drawing pad exactly rather
   than sitting 8px inside it at both ends. */
.drawings-page .drawings-stepper .mud-stepper-actions {
    padding-left: 0;
    padding-right: 0;
}

.drawings-page .drawings-actions {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 12px;
    /* Without `width: 100%` this is a flex item inside the wrapper above and shrink-wraps to its
       buttons — measured 371px, which parked Previous/Next in the middle of the page instead of at
       the right. */
    width: 100%;
    /* 800px canvas + 24px gap + 40px palette column: caps the row to the pad's own block so it stays
       left-aligned with the canvas once the viewport is wider than the pad. */
    max-width: 864px;
    margin-inline: auto;
    flex: 1 1 auto;
    padding-top: 8px;
    /* Palette column + its gap. Puts the right edge of Next exactly on the right edge of the canvas
       at every width (verified: 0px delta from 768px to 1440px), matching the design. Dropped below
       768px, where the palette moves under the canvas. */
    padding-right: 64px;
}

.drawings-page .drawings-actions-primary {
    display: flex;
    align-items: center;
    gap: 12px;
    margin-left: auto;
}

.drawings-page .drawings-reset-button {
    color: var(--mud-palette-text-secondary);
}

.drawings-page .drawings-previous-button,
.drawings-page .drawings-next-button {
    min-width: 104px;
}

.drawings-page .drawings-pad-wrap {
    display: flex;
    flex-direction: column;
    min-height: 0;
}

/* The pad is rendered by DrawingPad, so it carries no scope attribute of this page and has to be
   reached with ::deep. Same 864px cap and auto margins as the rows above it, which is what keeps the
   rail, canvas, description and action row on one shared centred column. */
.drawings-page .drawings-pad-wrap .drawing-pad {
    max-width: 864px;
    margin-inline: auto;
}

/* Tablet and up — the widths where the palette still sits BESIDE the canvas.
   Centring the 864px block (canvas 800 + gap 24 + palette 40) is geometrically correct but reads as
   off-centre, because the eye takes the canvas for the content and the canvas then sits half a
   palette-gutter — 32px — left of centre (measured: canvas centre 605 against a viewport centre of
   640). Mirroring the gutter on the left makes the CANVAS the centred element, which is what the
   design looks like, and everything that aligns to the canvas edges keeps aligning: 64 + 800 + 24 + 40
   = 928.

   The cost is 64px of canvas width once the viewport is too narrow for the canvas to reach its 800px
   cap — 609px instead of 673px on a 768px tablet. Accepted in exchange for the canvas being centred at
   every width; a conditional gutter (`min()` against the container width) would claw it back but makes
   the rule depend on which element the percentage resolves against, which is exactly the kind of
   cleverness that has misfired in this stylesheet before.
   Phones are excluded: below 768px the palette moves under the canvas, so there is no gutter to
   mirror and the canvas should keep the full width. */
@media (min-width: 768px) {
    .drawings-page .drawings-progress-row,
    .drawings-page .drawings-actions {
        max-width: 928px;
        padding-left: 64px;
    }

    .drawings-page .drawings-stepper-nav,
    .drawings-page .drawings-pad-wrap .drawing-pad {
        max-width: 928px;
        padding-left: 64px;
    }
}

/* Phone: the palette wraps under the canvas (DrawingPad.razor.css), costing about 40px of height,
   and removes the reason for the action row's right gutter. */
@media (max-width: 767.98px) {
    .drawings-page {
        /* 356px, not 352px: the horizontal palette row and its gap are now inside the content area.
           Verified at 375x667 and 430x745 with zero content overflow. */
        --drawing-pad-height: clamp(140px, calc(100dvh - 356px), 380px);
        padding: 4px 4px 8px;
    }

    .drawings-page .drawings-actions {
        padding-right: 0;
    }

    .drawings-page .drawings-stepper-nav {
        max-width: 100%;
        padding-right: 0;
    }

    .drawings-page .drawings-previous-button,
    .drawings-page .drawings-next-button {
        min-width: 88px;
    }
}

/* Short viewports — in practice a phone in landscape (measured 932x430). A vertical palette is
   ~290px tall on its own, which is more than the whole content area at this height, so the pad has
   to stack and the palette has to lie down; see the matching block in DrawingPad.razor.css.
   Keyed on height only, so it also catches a short desktop window. */
@media (max-height: 560px) {
    .drawings-page {
        --drawing-pad-height: clamp(110px, calc(100dvh - 320px), 300px);
    }

    /* Every row drops from 864px to 800px here, and all four have to change together. The palette has
       moved below the canvas so there is no gutter to reserve, which makes the block exactly the
       canvas' 800px cap. Leaving the header row and the pad at 864 while the rail and actions moved to
       800 was fine while everything was left-aligned, but once each row centres itself they centre at
       different widths and land on four different left edges (measured 34 / 66 / 29 / 66). */
    .drawings-page .drawings-progress-row,
    .drawings-page .drawings-actions {
        max-width: 800px;
    }

    .drawings-page .drawings-actions {
        padding-right: 0;
    }

    .drawings-page .drawings-stepper-nav {
        max-width: 800px;
        padding-right: 0;
    }

    /* Cancels the mirrored left gutter from the tablet-and-up block above: landscape is wider than
       768px, but the palette has moved below the canvas here so neither side has a gutter to balance. */
    .drawings-page .drawings-progress-row,
    .drawings-page .drawings-actions,
    .drawings-page .drawings-stepper-nav,
    .drawings-page .drawings-pad-wrap .drawing-pad {
        padding-left: 0;
    }

    .drawings-page .drawings-pad-wrap .drawing-pad {
        max-width: 800px;
    }
}