/* Sidebar + navigation (MainLayout / NavMenu) — the dark-navy nav rail, its links/groups, avatar, and logo. */

/* Kendo's stack-layout "stretch" distribution sets flex-basis:0% on every child by default, which
   overrides a plain `width` for main-axis sizing — pin the sidebar with the flex shorthand instead. */
.lh-sidebar {
    flex: 0 0 260px;
    width: 260px;
    height: 100vh;
    overflow-y: auto;
    padding: var(--kendo-spacing-6);
    box-sizing: border-box;
    justify-content: space-between;
    /* Figma's sidebar is a dark navy panel with white-ish content, expressed here via Kendo's own
       secondary/on-secondary tokens rather than hardcoded hex — the swatch doesn't define the navy
       yet (secondary currently resolves near-white), so this looks wrong until that's fixed, but it
       stays correct automatically once it is. */
    background-color: var(--kendo-color-secondary);
    color: var(--kendo-color-on-secondary);
    /* Decorative wave above the footer (Figma node 666:2695, exported unmodified). Drawn as this panel's
       own background rather than an absolutely positioned child: the design bleeds it past both edges
       (292px wide in a 260px panel, left -14.57px), which a child would turn into a horizontal scrollbar
       under this panel's overflow-y:auto, while a background is simply clipped. Its 97.11px bottom offset
       assumes the footer keeps its Figma height. Hidden when collapsed (see below). */
    background-image: url('/branding/sidebar-wave.svg');
    background-repeat: no-repeat;
    background-size: 292.133px 75.6279px;
    background-position: left -14.57px bottom 97.11px;
    /* .k-button-flat itself is `color: inherit`, so an enabled nav link already picks up the line
       above — but Vessels/Tasks & Alerts are Enabled="false" placeholders, and Kendo's disabled-text
       fallback chain is rooted in --kendo-color-on-app-surface, a token meant for a *light* surface.
       Against this dark sidebar that computes to near-invisible dark-on-dark text. Redefining Kendo's
       own button text variables (same technique as the PanelBar override below) fixes every state at
       once instead of chasing each fallback chain individually. */
    --kendo-button-text: var(--kendo-color-on-secondary);
    --kendo-button-hover-text: var(--kendo-color-on-secondary);
    --kendo-button-disabled-text: var(--kendo-color-on-secondary);
    /* FillMode="Outline" doesn't read --kendo-button-text at all — it has its own dedicated,
       more-specific rule (`.k-button-outline{color: var(--kendo-color-base-on-surface)}`) that beats
       the generic .k-button one above. That's what was making the collapse-toggle chevron black. */
    --kendo-color-base-on-surface: var(--kendo-color-on-secondary);
}

/* Same equal-share squash as .lh-dashboard: without this, header/links/footer would each get 1/3 of
   the sidebar's 100vh instead of their own content height. */
.lh-sidebar>* {
    flex: 0 0 auto;
}

/* Same squash again, one level down: without this, the logo and the collapse-toggle button split
   the header row's width evenly by default instead of sizing to their own content — squeezing the
   150px-wide logo down and, worse, stretching the button (which would otherwise be a compact square
   via Kendo's own k-icon-button sizing) out to a wide rectangle. */
.lh-sidebar-header>* {
    flex: 0 0 auto;
}

.lh-sidebar-collapsed {
    flex-basis: 93px;
    width: 93px;
    /* Figma's collapsed rail (node 1989:17261) ships its own purpose-cropped wave export for the
       narrow 93px width (branding/sidebar-wave-collapsed.svg) rather than the expanded rail's
       292px-wide one rescaled — same "Vector 1" wave shape, different crop. Figma places it at
       top:848px/height:80px inside a 1024px mock frame, i.e. 96px up from the bottom; unlike the
       expanded wave it doesn't bleed past the rail's own width, so no negative background-position
       is needed on that axis (only Figma's -0.5px). */
    background-image: url('/branding/sidebar-wave-collapsed.svg');
    background-repeat: no-repeat;
    background-size: 93px 80px;
    background-position: left -0.5px bottom 96px;
    /* .lh-sidebar sets overflow-y: auto above; per spec, setting only one axis computes the other
       ("visible" paired with a non-visible axis) to auto too, so the rail would otherwise clip the
       hover flyouts below horizontally. Collapsed nav never has enough content to need its own
       scrollbar by itself, so opting back into overflow: visible here is safe — PROVIDED the one thing
       that can still grow tall (Administration's hover flyout, for a user with many permissions) caps
       its own height and scrolls internally instead (.lh-nav-children's max-height/overflow-y below);
       without that cap this visible would let the flyout's real height push the whole page into an
       outer scrollbar instead of just scrolling the flyout (reported live, "administrator" role). */
    overflow: visible;
}

/* order:-1 flips the chevron above the logo (client feedback) without touching DOM order — the
   expanded header still needs logo-first/chevron-second for its own left-logo/right-chevron layout
   (.lh-sidebar-header's own justify-content:space-between), and this rule only matches when collapsed. */
.lh-sidebar-collapsed .lh-sidebar-collapse-btn {
    order: -1;
}

/* .k-button.k-button-outline (Kendo's own Outline rule) chains two classes together, giving it
   (0,2,0) specificity — a single-class .lh-sidebar-collapse-btn (0,1,0) can never beat that regardless
   of load order, same pattern as every other Kendo override this session. Compounding onto .k-button
   here matches that specificity so app.css's later load order actually wins the tie. `border-color:
   currentColor` ties the border to `color` by construction, so the chevron icon (which reads the same
   `color`) and the border can never drift out of sync — one value, not two coincidentally-equal ones. */
.k-button.lh-sidebar-collapse-btn {
    /* Figma node 666:2656: a 20x20 frame (1px stroke inside it) around a 12x12 chevron, so 3px of padding
       plus the 1px border puts the icon at the design's 4px inset. 3px is a Figma-exact off-scale value. */
    width: 20px;
    height: 20px;
    min-width: 0;
    padding: 3px;
    border-radius: var(--kendo-border-radius-lg);
    border: 1px solid currentColor;
    color: rgba(255, 255, 255, 0.30);
    /* Kendo sizes an icon button's span and svg from --kendo-icon-size-md via a five-class selector
       (.k-button.k-icon-button .k-button-icon.k-svg-icon > svg), which no plain override beats — re-pointing
       the token it reads is what gets the Figma 12px chevron without fighting that specificity. */
    --kendo-icon-size-md: 12px;
}

/* The icon slot also carries a min-width/min-height floor from `.k-icon-button .k-button-icon` (0,2,0),
   which held it at ~20px even after the token above shrank the glyph; three classes here beats that. */
.k-button.lh-sidebar-collapse-btn .k-button-icon {
    min-width: 0;
    min-height: 0;
}

/* Kendo's own .k-button-outline:hover rule sets `color:inherit` (which resolves to a near-white,
   picked up from .lh-sidebar's foreground) but *also* sets border-color independently to a fixed dark
   gray mix, untying the border from the icon's color specifically on hover — even though this button
   has no ThemeColor class (Base was never explicitly set), so Kendo's actual matching selector here is
   just `.k-button-outline:hover` at (0,2,0), tied with our own base rule above; it won that tie only on
   source order, not specificity, so a same-specificity fix would be equally fragile. Three tokens
   (2 classes + :hover) beats it outright regardless of load order. Reusing the sidebar's own foreground
   token rather than a literal white keeps this in step with the rest of the theme automatically. */
.k-button.lh-sidebar-collapse-btn:hover {
    color: var(--kendo-color-on-secondary);
    border-color: currentColor;
}

/* The chevron icon is a solid filled SVG path (fill only, no stroke), so
   stroke-width alone does nothing to it. Adding a matching stroke on top of
   the existing fill bulks up the silhouette to read as "thicker". Using
   vector-effect: non-scaling-stroke keeps the width in real screen pixels
   instead of the icon's internal viewBox units, so it stays predictable
   regardless of icon size. */
.k-button.lh-sidebar-collapse-btn svg path {
    stroke: currentColor;
    stroke-width: 1.5px;
    vector-effect: non-scaling-stroke;
}

.lh-sidebar-header {
    justify-content: space-between;
    width: 100%;
}

.lh-sidebar-links {
    flex: 1 1 auto;
    margin-top: var(--kendo-spacing-6);
    width: 100%;
}

/* Same equal-share squash as .lh-dashboard/.lh-sidebar/.lh-bottom-left, just in the other direction:
   .lh-sidebar-links itself is flex:1 1 auto so it fills the leftover height (pushing the footer to
   the bottom), and without this its children (each nav button, the PanelBar) get Kendo's default
   flex:1 0 0% and stretch to share that abundant space equally instead of sizing to their own
   content — the buttons end up many times taller than a normal nav row. */
.lh-sidebar-links>* {
    flex: 0 0 auto;
}

/* Figma NavItem: 12px padding all round around a 20px icon (44px tall), 8px corners. Two classes beats
   Kendo's single-class .k-button/.k-button-md padding; the collapsed-rail rule below (three classes)
   still wins for the narrow rail's own horizontal padding. */
.lh-sidebar-links .k-button {
    width: 100%;
    padding: var(--kendo-spacing-3);
    border-width: 0;
    border-radius: var(--kendo-border-radius-xl);
}

/* TelerikButton wraps all ChildContent in one <span class="k-button-text">, so the icon+label group
   and the optional trailing chevron both end up as children of that span, not of the button itself
   — space-between has to go here, not on .k-button, or there's nothing for it to space apart. */
.lh-sidebar-links .k-button .k-button-text {
    display: flex;
    justify-content: space-between;
    align-items: center;
    width: 100%;
}

/* Collapsed: the label/chevron are still in the DOM (see .lh-nav-item-wrapper below) but display:none,
   so .k-button-text effectively has one visible child (the icon) — space-between just left-aligns a
   single child, which is what was making collapsed nav icons look off-center rather than centered in
   the narrow rail. Tightening the button's own horizontal padding gives the icon more of the
   already-scarce 45px-wide column to sit in. */
.lh-sidebar-collapsed .lh-sidebar-links .k-button .k-button-text {
    justify-content: center;
}

.lh-sidebar-collapsed .lh-sidebar-links .k-button {
    padding-left: var(--kendo-spacing-0-5);
    padding-right: var(--kendo-spacing-0-5);
}

/* Collapsed-rail hover popout (designer follow-up, Figma nodes 1989:17261 "Collapsed", 2006:19823
   "Collapsed ... Hover", 2006:20195 "Collapsed Administration Hover Expanded"). Each nav item's button
   (+ its children list, for Administration) is wrapped in one .lh-nav-item-wrapper (NavMenuLinkButton.razor)
   so hovering reveals both together as a single flyout, rather than needing separate rules per element.
   No-op outside the collapsed rail — width/background only apply under .lh-sidebar-collapsed, so the
   expanded rail's own layout is untouched. */
.lh-nav-item-wrapper {
    position: relative;
}

/* Same equal-share squash as everywhere else in this file (.lh-sidebar-links>*, .lh-nav-children>*, ...):
   this StackLayout sets no HorizontalAlign/VerticalAlign, so Kendo's default k-align-items-stretch/
   k-justify-content-stretch gives its two children (the button, .lh-nav-children) flex:1 0 0% each.
   Harmless as long as nothing gives either child a real intrinsic size to grow from — which is exactly
   what changed once .lh-nav-children got a real max-height (client feedback, "wrong sizes for the hover
   menu"): confirmed live, without this rule the button's own box was inflating to claim a large empty
   share of that height instead of sizing to its own content, pushing the children list down below a
   tall gap rather than sitting directly under it. */
.lh-nav-item-wrapper>* {
    flex: 0 0 auto;
}

.lh-sidebar-collapsed .lh-nav-item-wrapper {
    width: 44px;
}

/* height:44px, scoped to just the TOP-level wrapper via .lh-sidebar-links > (client feedback: hovering
   was growing the sidebar's own height, misaligning it with the page and adding page-level scroll) —
   confirmed live: even with .lh-nav-children's own max-height capped/scrollable, it was still a
   NORMAL-FLOW sibling of the button inside this wrapper, so its real (large) height still pushed the
   wrapper's own auto-height, which in turn pushed every later sidebar item down and grew .lh-sidebar's
   total content past 100vh — capping the CHILD's height was never enough on its own while it stayed in
   flow. Pinning the wrapper's own height, and switching .lh-nav-children to position:absolute below
   (removing IT from flow entirely so it no longer contributes to this wrapper's height at all), fixes
   this at the source: the wrapper is always exactly 44px tall regardless of hover state, and the
   children list is purely a visual overlay on top of whatever's below it.

   `>` here matters for a second reason too (confirmed live): a NESTED child wrapper (each of
   Administration's own children is itself a .lh-nav-item-wrapper) would otherwise ALSO get forced to
   44px by this same rule if left unscoped — masking the smaller-row padding fix below entirely, since a
   fixed height doesn't care how much padding its content asks for. Nested wrappers were never meant to
   have a forced height at all; they should size to their own (now-smaller) button content. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper {
    height: 44px;
}

.lh-sidebar-collapsed .lh-nav-label,
.lh-sidebar-collapsed .lh-nav-item-wrapper .lh-nav-icon-sm,
.lh-sidebar-collapsed .lh-nav-children-flyout {
    display: none;
}

/* :has(:focus-visible), not :focus-within, so keyboard users tabbing onto a collapsed nav button still
   get the label (otherwise the button would have no accessible visible text while focused), but a mouse
   click doesn't leave the flyout "stuck" open — clicking a button also focuses it, and :focus-within
   would keep matching (and the flyout popped out) until focus moved elsewhere, well after the pointer
   left. :focus-visible specifically excludes that pointer-driven focus (browsers only set it for
   keyboard interaction), so hover is the only thing holding it open once the click completes, letting it
   close as soon as the mouse leaves like every other item — matching the requested "close again when
   selected" behavior.

   .lh-sidebar-links > (direct-child combinator), not a plain descendant selector, on every rule below
   that reads :hover/:has(:focus-visible) — confirmed live this was a real bug, not just theoretical:
   Administration's own children are themselves .lh-nav-item-wrapper instances (nested one level down),
   so a plain `.lh-nav-item-wrapper:hover` also matched whichever CHILD row the mouse happened to be
   directly over, making that one child independently "become a flyout" too (its own 218px width already
   fought back to 100% by the nested-width-fix rule below, but its own background/border-radius/z-index
   still applied on top of the real flyout panel's) — a small rounded box floating inside the real one.
   `>` restricts the panel-becoming rules to only ever match the item that's an actual direct child of
   the nav list (Dashboard/Vessels/Administration/Tasks & Alerts), never a nested child row — while
   :hover bubbling still correctly keeps it matching no matter which nested row the mouse is over, since
   a hovered descendant always keeps its ancestors' own :hover true too.

   z-index alone is enough to paint above .lh-app-main's content next to it: .lh-sidebar-links/.lh-sidebar
   are plain non-positioned ancestors, so this wrapper's stacking promotes straight up to the root
   stacking context, ahead of .lh-app-main's un-positioned (stacking-order-0) content, regardless of
   .lh-app-main coming later in the DOM. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) {
    z-index: 20;
    width: 218px;
    background-color: color-mix(in oklch, var(--kendo-color-secondary) 85%, white 15%);
    border-radius: var(--kendo-border-radius-xl);
}

/* Found via live DevTools inspection (client screenshot of the Styles panel) — this is the rule that
   was ACTUALLY still showing uniform 8px corners, not .lh-nav-children-flyout (already fixed to top/
   bottom-only radius earlier). The wrapper needs its own background here at all because Administration's
   button is always .lh-nav-item-inactive (a group header never carries a route, so it can never be
   .lh-nav-item-active) — Kendo's own `.k-button.k-button-flat.k-button-base{background:none!important}`
   base rule means an inactive button paints NO background of its own, so the wrapper's background is
   the only thing actually visible behind it. The button's own bottom corners were already squared off
   (the :has(.lh-nav-children) rule further below), but this wrapper sits at the exact same position/size
   BEHIND it with its OWN full 4-corner rounding still active — its rounded bottom corners were peeking
   out right where the (transparent-cornered) button meets the flyout below, which is what actually read
   as "the border is wrong" both times. Same :has(.lh-nav-children) condition, applied here too, so a
   wrapper WITH children squares its own bottom corners to match its button exactly; Dashboard/Vessels/
   Tasks & Alerts (no children) are untouched and keep their full pill shape. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(.lh-nav-children):hover,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(.lh-nav-children):has(:focus-visible) {
    border-radius: var(--kendo-border-radius-xl) var(--kendo-border-radius-xl) 0 0;
}

.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .k-button .k-button-text,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .k-button .k-button-text {
    justify-content: space-between;
}

.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .k-button,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .k-button {
    padding: var(--kendo-spacing-3);
}

.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .lh-nav-label,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .lh-nav-label {
    display: inline;
}

.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .lh-nav-icon-sm,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .lh-nav-icon-sm {
    display: inline-flex;
}

/* position:absolute unconditionally (not just while visible) — display:none already keeps it out of
   layout while hidden, but setting position here rather than only in the hover-triggered rule below
   avoids the element having to switch positioning schemes at the same instant it starts participating
   in layout, which is more fragile to reason about than "always absolute, sometimes hidden". Anchored
   to .lh-nav-item-wrapper's own position:relative, sitting directly below the always-44px button (top:
   44px) — see the wrapper's own height:44px comment for why this needs to be absolute at all: being
   removed from normal flow is what stops this list's real (potentially tall) height from contributing
   to the wrapper's own height and, through it, growing the sidebar's total content past 100vh.

   .lh-nav-children-flyout (the raw div NavMenuLinkButton.razor wraps .lh-nav-children in) is a second
   split from an earlier version of this fix that put position/background/radius/overflow-y all on
   .lh-nav-children itself: confirmed live, a real (non-headless) browser's native scrollbar squared off
   this box's rounded top-right corner despite border-radius being computed correctly — overflow:auto
   doesn't reliably clip a native scrollbar to a border-radius in the way overflow:hidden does. So this
   outer div now owns ONLY position/size/background/radius/overflow:hidden (a reliable clip mask, never
   itself scrolling), and .lh-nav-children (the inner TelerikStackLayout, still holding the actual
   scrollbar) is a plain 100%-filling child of it below — the mask is what makes the scrollbar's own
   corner render rounded, not the scrolling element's own radius. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper .lh-nav-children-flyout {
    position: absolute;
    top: 44px;
    left: 0;
    width: 218px;
    overflow: hidden;
}

.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .lh-nav-children-flyout,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .lh-nav-children-flyout {
    display: flex;
    z-index: 20;
    background-color: color-mix(in oklch, var(--kendo-color-secondary) 85%, white 15%);
    /* Bottom corners only — the button directly above squares off its own bottom corners to match (see
       the :has(.lh-nav-children) rule below) so the seam between the two reads as one continuous panel
       rounded only at its outer top/bottom, not a pinched double-curve where they meet. */
    border-radius: 0 0 var(--kendo-border-radius-xl) var(--kendo-border-radius-xl);
}

/* max-height/overflow-y (client feedback, logged in as an administrator — many permissions means many
   Administration children): without a cap, this list's own height could still run past the bottom of
   the viewport even though it's no longer inflating the sidebar itself — capping it and scrolling
   internally keeps the "Administration" header row always visible/anchored while only the children
   below it scroll. Unconditional (not hover-scoped) since the OUTER .lh-nav-children-flyout being
   display:none already hides this whole element when not needed — no need to also gate these.

   calc(100vh - 340px), not a flat/small cap (client feedback: it should only scroll once it actually
   runs out of room, not well before) — 340px approximates the fixed chrome above a child list on a
   collapsed rail (sidebar's own 24px top padding + collapsed header ~92px [.lh-logo-icon's own 60px +
   12px header Spacing + the 20px collapse-toggle button] + .lh-sidebar-links' 24px margin-top +
   Dashboard/Vessels/Document Search 44px each, when shown, + gaps + Administration's own ~44px row), so
   this only actually clips/scrolls once there truly isn't room below it, rather than an arbitrary
   viewport fraction. Was 303px before Document Search was added between Vessels and Administration
   (confirmed live via Playwright measurement of .lh-nav-children-flyout's actual top offset — 340px, not
   303 — and the flyout overflowing the viewport bottom by exactly that 37px difference at a short-window
   size) — this needs revisiting again if a row is added/removed above Administration, or the header's own
   height changes. An approximation, not pixel-exact — Vessels/Document Search being permission-gated
   shifts the real number slightly, erring toward clipping a little early rather than risking the original
   page-scroll bug back. */
.lh-sidebar-collapsed .lh-nav-children {
    width: 100%;
    max-height: calc(100vh - 340px);
    overflow-x: hidden;
    overflow-y: auto;
}

/* Thin, theme-colored scrollbar instead of the browser's default (client feedback: the native one read
   oversized/out of place against this flyout). scrollbar-width/-color cover Firefox; the -webkit- rules
   cover Chrome/Edge/Safari — between them that's every browser this app already assumes elsewhere
   (color-mix, :has()). The outer .lh-nav-children-flyout's own overflow:hidden is what actually clips
   this to a rounded corner (see its comment) — this is just the scrollbar's own cosmetics. */
.lh-sidebar-collapsed .lh-nav-children {
    scrollbar-width: thin;
    scrollbar-color: color-mix(in srgb, var(--kendo-color-on-secondary) 40%, transparent) transparent;
}

.lh-sidebar-collapsed .lh-nav-children::-webkit-scrollbar {
    width: 6px;
}

.lh-sidebar-collapsed .lh-nav-children::-webkit-scrollbar-thumb {
    background-color: color-mix(in srgb, var(--kendo-color-on-secondary) 40%, transparent);
    border-radius: var(--kendo-border-radius-full);
}

/* Tighter row spacing to match Figma's flyout (node 2006:20204: a flat flex column, 12px gap, no
   per-row padding) — each child is a full nav button, though, not bare text, so its own kendo-spacing-3
   (12px) padding compounds with .lh-nav-children's 4px gap into a much taller ~28px gap between rows
   than Figma's flat 12px. Shrinking just the padding to kendo-spacing-1 (4px) does the rest of the work:
   4px padding + 4px gap + 4px padding = 12px, matching Figma without touching the gap (which is Telerik's
   own inline style — Spacing="4px" on the StackLayout in NavMenuLinkButton.razor — and can't be
   overridden by a plain class rule anyway). Unscoped to .lh-sidebar-collapsed (client feedback: the
   expanded rail's own always-visible Administration children should read smaller too, not just the
   collapsed-hover flyout) — Administration's own (unaffected) button keeps its normal padding either
   way, since this only reaches inside .lh-nav-children. */
.lh-nav-children .k-button {
    padding: var(--kendo-spacing-1);
}

/* The collapsed-hover flyout's own OnHover .k-button padding rule (`.lh-sidebar-collapsed .lh-sidebar-
   links > .lh-nav-item-wrapper:hover .k-button { padding: var(--kendo-spacing-3) }` above) reaches every
   button inside the hovered flyout — including a child's, since its "reach" is deliberately a general
   descendant match so the same rule also restores the trigger BUTTON's own padding on hover (see that
   rule's own comment). That makes it 5 selectors deep, beating this file's plain `.lh-nav-children
   .k-button` (2 selectors) rule above back to 12px right when the flyout is open — exactly when the
   smaller rows actually matter (confirmed live: children stayed full-size specifically while hovering).
   Matching the same 5-selector hover chain plus .lh-nav-children here (6) wins outright. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .lh-nav-children .k-button,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .lh-nav-children .k-button {
    padding: var(--kendo-spacing-1);
}

/* Squares off the seam between a group's own button and its children list (client feedback: "borders
   are incorrect ... for the Administrator") — confirmed live, since .lh-nav-children became its own
   separate absolutely-positioned box (see its own comment on why), it and the button above it are two
   independently-rounded boxes sitting flush against each other, so BOTH having all four corners rounded
   pinched a visible double-curve into the seam where they meet instead of reading as one continuous
   panel. :has(.lh-nav-children) scopes this to only a wrapper that actually has children (Administration
   today) — Dashboard/Vessels/Tasks & Alerts have no .lh-nav-children at all, so :has() simply never
   matches them and their own full 4-corner pill stays untouched.

   > .k-button (direct child), not a general descendant match (confirmed live this was a real bug, not
   just theoretical): NavMenuLinkButton.razor puts the button as a direct child of .lh-nav-item-wrapper,
   but a nested child row's OWN button sits several levels deeper (wrapper > .lh-nav-children-flyout >
   .lh-nav-children > nested .lh-nav-item-wrapper > .k-button) — a plain descendant selector matched
   BOTH, so every child button (Agency Charges, Commodities, ...) was ALSO getting its bottom corners
   squared off despite having no seam of its own to square against, breaking their own independent pill
   shape on hover/active. `>` restricts this to only the trigger's own immediate button. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(.lh-nav-children):hover>.k-button,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(.lh-nav-children):has(:focus-visible)>.k-button {
    border-radius: var(--kendo-border-radius-xl) var(--kendo-border-radius-xl) 0 0;
}

/* Administration's children are themselves NavMenuLinkButton instances, so each gets its own nested
   .lh-nav-item-wrapper too. flex: 0 0 auto on .lh-nav-children>* (below) resolves flex-basis from
   width, so left at the base rule's 44px a revealed child label would just overflow that box rather
   than sizing the row to the 218px flyout — widen nested wrappers to fill it instead. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .lh-nav-item-wrapper,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .lh-nav-item-wrapper {
    width: 100%;
}

/* Expandable groups (Administration) are just NavMenuLinkButton rendering a header button plus a
   nested list of child NavMenuLinkButton instances now, rather than a separately-themed TelerikPanelBar
   — so children automatically get the exact same .lh-nav-item-active/-inactive treatment as every other
   link (see that rule below) instead of needing their own PanelBar CSS-variable overrides.

   Indent enough that child text lines up under the parent's text, not its icon: the parent's own label
   starts at its button's spacing-3 (12px) padding + 20px icon + 12px icon/label gap = 32px (spacing-8) in
   from the row's left edge — children render with no icon of their own, so naively matching that same
   32px was the right idea, but a child's own button has its own left padding too (spacing-1, 4px, from
   the tighter-row-spacing rule below), which stacks on TOP of this padding-left rather than being part of
   it. Confirmed live (Playwright measurement of both labels' actual x position, 8px off) that plain
   spacing-8 therefore undershoots by exactly that child button's spacing-1 vs the parent's own spacing-3
   — this calc adds that 8px difference back in, rather than a flat 40px, so it keeps tracking correctly if
   either button's own padding rule changes. */
.lh-nav-children {
    width: 100%;
    padding-left: calc(var(--kendo-spacing-8) + var(--kendo-spacing-3) - var(--kendo-spacing-1));
    box-sizing: border-box;
}

.lh-nav-children>* {
    flex: 0 0 auto;
}

/* Active/inactive nav item treatment (Figma NavItem): active gets a slightly-lighter tint of the
   sidebar's own background, the accent color's right border, and full-strength content; inactive is
   dimmed via opacity rather than a separate muted color, so it still tracks whatever the sidebar's
   foreground color ends up being.

   Both buttons are FillMode="Flat" now (see NavMenuLinkButton.razor), and Kendo's real rendered class
   list is `k-button k-button-flat k-button-base`, which its own theme CSS targets with the *combined*
   selector `.k-button.k-button-flat.k-button-base { background:none !important; border-color:
   rgba(0,0,0,0) !important }` — three classes, (0,3,0) specificity. A two-class override (even with
   !important) still loses to that outright. Matching all three of Kendo's own classes plus ours gets
   to (0,4,0), which wins regardless of stylesheet load order. The explicit :hover variant re-asserts
   the same background so hovering the currently-active link doesn't flash to Kendo's own hover tint.

   inset box-shadow, not border-right (client feedback: "borders are incorrect" on the first/active item)
   — confirmed live: a plain border-right painted as a hard rectangle regardless of this same rule's own
   border-radius, giving every active pill a rounded left edge but a flat-cut square right edge right
   where the accent line sits (most visible on the collapsed-hover flyout's own free-floating 218px pill,
   but the same mismatch existed everywhere this rule applies). An inset box-shadow is explicitly clipped
   to the element's own border-radius per spec, so it curves correctly at the corners instead. */
.k-button.k-button-flat.k-button-base.lh-nav-item-active,
.k-button.k-button-flat.k-button-base.lh-nav-item-active:hover {
    background-color: color-mix(in oklch, var(--kendo-color-secondary) 85%, white 15%) !important;
    box-shadow: inset -3px 0 0 0 var(--kendo-color-primary) !important;
    font-weight: var(--lh-weight-bold);
}

/* Designer feedback: inside the collapsed-hover flyout, an active CHILD row was invisible — its
   active background is the exact same color-mix tint the flyout PANEL itself uses (.lh-nav-item-wrapper
   :hover above), so a selected item just blended into its own container. Darkening it to the sidebar's
   own solid navy (its "main color", i.e. .lh-sidebar's own background-color, one step darker than the
   85%-tint) restores the contrast. Scoped to .lh-nav-children so this only affects a child row, not the
   Administration trigger button itself (whose own active state — N/A today, since a group header never
   carries a route of its own — would otherwise also go needlessly darker for no visual gain, and every
   OTHER item's flyout, which has no children, has nothing to contrast against in the first place). Six
   class-ish selectors + !important beats the four-class rule above outright, regardless of load order. */
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:hover .lh-nav-children .k-button.k-button-flat.k-button-base.lh-nav-item-active,
.lh-sidebar-collapsed .lh-sidebar-links>.lh-nav-item-wrapper:has(:focus-visible) .lh-nav-children .k-button.k-button-flat.k-button-base.lh-nav-item-active {
    background-color: var(--kendo-color-secondary) !important;
}

/* Kendo's own flat-button hover tint (capes-theme.css) mixes in --kendo-color-on-base — a token meant
   for dark text on a *light* surface — at only 3%, which is close to invisible against this dark navy
   sidebar. Overriding with the sidebar's own light foreground token at a higher percentage gives
   inactive items (and expandable-group children, which reuse this same class) a hover state that's
   actually visible here, while staying a plain wash rather than competing with the active item's own
   dedicated background above. Same specificity/!important reasoning as that rule. */
.k-button.k-button-flat.k-button-base.lh-nav-item-inactive:hover {
    background-color: color-mix(in srgb, var(--kendo-color-on-secondary) 10%, transparent) !important;
}

.lh-nav-item-inactive {
    opacity: 0.7;
}

/* Figma: the selected item is bold (700, .lh-nav-item-active above) and every other item regular (400).
   Kendo's own .k-button rule sets semibold for all buttons, so this needs the same four-class specificity
   as the active rule rather than relying on load order. */
.k-button.k-button-flat.k-button-base.lh-nav-item-inactive {
    font-weight: var(--lh-weight-normal);
}

/* Bare TelerikSvgIcons used as nav-item content (not a Button's own Icon slot) need explicit sizing
   for the same reason as .lh-icon-fixed — see that rule's comment. */
.lh-nav-icon.k-svg-icon {
    width: 20px;
    height: 20px;
    flex-shrink: 0;
}

.lh-nav-icon.k-svg-icon svg {
    width: 100%;
    height: 100%;
}

/* Telerik's "file" and "dashboard" glyphs (Document Search, Dashboard) are thin single-stroke outlines,
   unlike Anchor/Gear's bold filled glyphs — designer feedback, 2026-09-30. Neither has a non-obsolete
   bold/solid variant in this Telerik version to swap to (Dashboard's Solid variant exists but is flagged
   obsolete, removed in v5 — see NavMenu.razor's comment), so both are corrected here instead: painting a
   matching-color stroke on top of the fill "dilates" the glyph's thin border lines to the same weight,
   without needing a different icon. Widths picked by comparing actual 20px renders (device-scale-factor 4
   Playwright screenshots) against Gear's stroke weight side by side — a naive crop-and-eyeball check at
   small sizes looked fine well past double these values, but a true-scale render showed that already
   closing the icons' inner cutouts into a solid blob. */
.lh-nav-icon.k-svg-icon.k-svg-i-file path {
    stroke: currentColor;
    stroke-width: 35;
    paint-order: stroke;
}

.lh-nav-icon.k-svg-icon.k-svg-i-dashboard-outline path {
    stroke: currentColor;
    stroke-width: 25;
    paint-order: stroke;
}

.lh-nav-icon-sm.k-svg-icon {
    width: 12px;
    height: 12px;
    flex-shrink: 0;
}

.lh-nav-icon-sm.k-svg-icon svg {
    width: 100%;
    height: 100%;
}

/* Same equal-share squash as .lh-dashboard/.lh-sidebar: without this, the avatar (no text content
   demanding room) gets flexed down to 0 width while its siblings take the space instead. */
.lh-avatar {
    flex: 0 0 auto;
}

/* Real logo artwork exported from Figma (node 100:2597) — icon + "Lighthouse" wordmark +
   "Capes Shipping Agencies" wordmark composited into one asset, already authored in white for a
   dark background. No Telerik component wraps a plain image, so it's shown as a background-image on
   a fixed-size box rather than an <img> tag. Natural size is 219x74 (~2.96:1); Figma's header slot is
   180x60 (node 666:2654), and `contain` scales it to that height keeping the ratio. */
.lh-logo-image {
    width: 180px;
    height: 60px;
    background-image: url('/branding/lighthouse-logo.svg');
    background-repeat: no-repeat;
    background-size: contain;
    background-position: left center;
}

/* Collapsed-rail logo: the same asset, cropped via background-size/-position to show just its icon
   portion (the illustration sits flush at the asset's own top-left corner, 63x74 of the 219x74 viewBox —
   Figma's own icon-only variant, node 100:2904, is that same 63x74 — so no positional offset is needed,
   only a scale-up). Keeps the real lighthouse mark in the collapsed rail instead of swapping to an
   unrelated generic icon. background-size scales the *whole* asset up by the same factor that makes
   its icon portion exactly the element's own width; background-position stays at the origin; anything
   beyond this element's box (i.e. the wordmarks) is simply outside its bounds and never paints.

   51.081x60 is Figma's own icon-only LighthouseLogo instance size (node 1989:17261's collapsed
   SidebarHeader, mode="Dark" orientation="Icon" — the exact w-[51.081px] h-[60px] client feedback asked
   for directly), scaled up from an earlier 32x37 guess. background-size scales the whole 219x74 asset by
   the same factor (60/74) that makes its 63x74 icon portion land on exactly 51.081x60 — 219*(60/74) =
   177.57, 74*(60/74) = 60. Wider than the 45px collapsed content column (93px rail - 24px padding each
   side) by design, per this exact Figma spec — it bleeds a few px into the rail's own side padding
   rather than being constrained to that column. */
.lh-logo-icon {
    width: 51.081px;
    height: 60px;
    background-image: url('/branding/lighthouse-logo.svg');
    background-repeat: no-repeat;
    background-position: 0 0;
    background-size: 177.57px 60px;
}

.lh-sidebar-footer {
    /* A hairline at 11% of the sidebar's own foreground color reads correctly in both a dark sidebar
       (a faint white line) and today's near-white one (a faint dark line), rather than assuming which. */
    border-top: 1px solid color-mix(in srgb, var(--kendo-color-on-secondary) 11%, transparent);
    padding-top: var(--kendo-spacing-5);
    width: 100%;
}

.lh-sidebar-user {
    flex: 1 1 auto;
    min-width: 0;
    overflow: hidden;
}

/* Same equal-share squash as everywhere else: name and role size to their own content, not half the row each. */
.lh-sidebar-user>* {
    flex: 0 0 auto;
}

/* Two classes to override the stack layout's own display:flex — text-overflow only ellipsizes a block container. */
.lh-sidebar-user .lh-user-name,
.lh-sidebar-user .lh-user-role {
    display: block;
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
}

.lh-user-name {
    font-family: var(--lh-font-body);
    font-size: var(--lh-text-md);
    font-weight: var(--lh-weight-semibold);
    color: var(--kendo-color-on-secondary);
}

.lh-user-role {
    font-family: var(--lh-font-body);
    font-size: var(--lh-text-xs);
    font-weight: var(--lh-weight-normal);
    color: var(--kendo-color-primary);
}

/* Log-out icon button (Figma node 666:2692): 6px padding around the 18px glyph, drawn at 70% of the
   sidebar foreground like the inactive nav items. Three classes (k-button + k-button-flat + ours) beats
   Kendo's own flat-button padding/color without leaning on load order; the stack layout's equal-share
   squash would otherwise stretch this button, so it opts out of flex sizing too. */
.k-button.k-button-flat.lh-logout-btn {
    flex: 0 0 auto;
    min-width: 0;
    padding: var(--kendo-spacing-1-5);
    color: color-mix(in srgb, var(--kendo-color-on-secondary) 70%, transparent);
}

/* Kendo's button-text span is inline with the button's 1.43 line-height, which made the button taller than
   Figma's 30px square; a flex span + block svg collapses it to the glyph plus padding. */
.k-button.k-button-flat.lh-logout-btn {
    border-width: 0;
}

.k-button.k-button-flat.lh-logout-btn .k-button-text {
    display: flex;
}

.lh-logout-btn svg {
    display: block;
}

.k-button.k-button-flat.lh-logout-btn:hover {
    color: var(--kendo-color-on-secondary);
}