/* Shared modal chrome — every TelerikWindow-based modal (navy titlebar, footer button bar, scrollable body split, highlighted panel, Add-New-X link styling). */

/* Shared modal chrome — every TelerikWindow-based modal in the app should carry Class="lh-modal" for
   Figma's consistent look (navy titlebar, light-gray footer band). Originally one-off styling on
   NewVesselFileModal.razor (Figma node 898:7751); generalized here so every modal draws from the same
   rules instead of each re-implementing its own header/footer colors.

   Navy titlebar with white text/close icon — Kendo's own window titlebar defaults to a light surface
   color, same swatch gap as the sidebar override elsewhere in this file.

   padding-block also needs overriding: Kendo's own default is --kendo-window-titlebar-padding-y, which
   isn't defined anywhere in this theme, so it falls back to its own fallback pair (--kendo-spacing-6
   var(--kendo-spacing-4), i.e. 24px top / 16px bottom) — an asymmetric top/bottom split that left the
   title text sitting noticeably below center in the bar. 20px/20px centers it (client feedback). */
.lh-modal .k-window-titlebar {
    background-color: var(--kendo-color-secondary);
    color: var(--kendo-color-on-secondary);
    --kendo-button-text: var(--kendo-color-on-secondary);
    --kendo-button-hover-text: var(--kendo-color-on-secondary);
    padding-block: var(--kendo-spacing-5);
}

/* Kendo draws a 2px solid outline (--kendo-color-on-base, effectively black) around the whole window
   whenever it's the focused element — an accessibility default, not something Figma's mock shows.
   Designer call: drop it entirely rather than swap in a subtler color. */
.lh-modal:focus,
.lh-modal.k-focus {
    outline: none;
}

/* Same unwanted Kendo default, different component: a focused radio input draws a 2px solid outline in
   --kendo-color-border-alt (pure black), not something Figma's mocks show either. Not scoped to a
   custom class — every TelerikRadioGroup in the app (cargo's Load/Discharge, the disbursement port
   expense modals' own radio groups) gets the same plain Kendo default, so this is a genuine app-wide
   gap rather than a one-off. */
.k-radio:focus,
.k-radio.k-focus {
    outline: none;
}

/* Footer button-bar treatment — applies to a modal's explicit .lh-modal-footer element (the
   content/body/footer split below) and, unmodified, to Kendo's own TelerikForm FormButtons wrapper
   (AddPortExpenseModal/EditPortExpenseModal use TelerikForm instead of manual buttons, but still get
   the same footer band this way with no markup changes). */
.lh-modal-footer,
.lh-modal .k-form-buttons {
    padding: var(--kendo-spacing-5);
    box-sizing: border-box;
    background-color: var(--kendo-color-base-subtle);
    border-top: 1px solid var(--lh-border-subtle);
    display: flex;
    justify-content: flex-end;
    gap: var(--kendo-spacing-3);
    margin: 0;
}

/* Footer band spans the window edge to edge by default. Kendo pads .k-window-content (the two vars below,
   with the same fallbacks Kendo itself uses), so a footer sitting directly in WindowContent or at the
   end of a TelerikForm would otherwise float inset from the window's edges; negative margins of exactly
   that padding pull it out to the edges and the bottom. .lh-modal-scroll zeroes both vars (its content
   has no padding, the footer is already flush), which turns these margins into 0 with no override. */
.lh-modal .k-window-content .lh-modal-footer,
.lh-modal .k-window-content .k-form-buttons {
    margin-inline: calc(-1 * var(--kendo-window-inner-padding-x, var(--kendo-spacing-6)));
    margin-block-end: calc(-1 * var(--kendo-window-inner-padding-y, var(--kendo-spacing-3)));
}

/* Breathing room above the footer band, always. The footer's own margin is zeroed above and its negative
   margins only pull it out to the window's edges, so a footer that directly follows content (a TelerikForm's
   last field, or a .lh-modal-footer placed straight in WindowContent) sat flush against it. Not needed —
   and reset just below — when the footer follows a .lh-modal-body, which already pads its own bottom. */
.lh-modal .k-window-content .lh-modal-footer,
.lh-modal .k-window-content .k-form-buttons {
    margin-block-start: var(--kendo-spacing-6);
}

.lh-modal .k-window-content .lh-modal-body+.lh-modal-footer {
    margin-block-start: 0;
}

/* Viewport safeguard for every TelerikWindow, opted-in or not: a window never grows taller than the
   viewport (minus a margin top and bottom), and its content scrolls instead. Without it a long form
   (e.g. Office Document Details) is centered at its full height, so its titlebar and buttons end up
   off-screen with no way to scroll or drag it back. dvh tracks mobile browser chrome; vh is the fallback
   for browsers without it. Declared before the .lh-modal-scroll rule below so that opt-in split, which
   scrolls its own inner body, still wins on overflow. */
.k-window {
    max-height: calc(100vh - 2 * var(--kendo-spacing-6));
    max-height: calc(100dvh - 2 * var(--kendo-spacing-6));
}

.k-window .k-window-content {
    min-height: 0;
    overflow-y: auto;
}

/* Opt-in content/body/footer split for modals whose form can grow taller than the viewport. Kendo's
   TelerikWindow has no "footer" slot distinct from its scrollable content area, so this flex-column/
   overflow split is what keeps .lh-modal-footer pinned below the form instead of scrolling away —
   .lh-modal-content is the flex column, .lh-modal-body is the only part that scrolls (min-height:0 is
   the usual flex-child fix that lets a scrolling child actually shrink below its content height), and
   .lh-modal-footer (above) stays put at its own content height. position:relative on .lh-modal-content
   (rather than a raw wrapper div, which every other page's BusyOverlay leans on instead) is what gives
   the overlay's position:absolute something to size against. Modals short enough to never need
   scrolling (e.g. ChangeVesselModal) can skip this split and put .lh-modal-footer directly in
   WindowContent instead. */
.lh-modal-scroll .k-window-content {
    --kendo-window-inner-padding-x: 0;
    --kendo-window-inner-padding-y: 0;
    display: flex;
    flex-direction: column;
    padding: 0;
    overflow: hidden;
}

.lh-modal-content {
    position: relative;
    flex: 1 1 auto;
    min-height: 0;
}

.lh-modal-body {
    flex: 1 1 auto;
    min-height: 0;
    overflow-y: auto;
    padding: var(--kendo-spacing-6);
    box-sizing: border-box;
}

/* Highlighted "you're creating something new" panel — first used around NewVesselFileModal's inline
   new-vessel particulars form, reused identically by ChangeVesselModal's new-IMO panel. */
.lh-modal-panel {
    background-color: var(--kendo-color-base-subtle);
    border: 1px solid var(--lh-border-subtle);
    border-radius: var(--kendo-border-radius-xl);
    padding: var(--kendo-spacing-4);
    box-sizing: border-box;
}

/* "New IMO Details" heading (Figma node 902:10424, data-annotations "Secondary blue text here for
   heading") — secondary/navy, not primary/teal; kept as the semantic -on-surface token rather than the
   node's own hardcoded #073b7a, same reasoning as .lh-modal-add-link below. */
.lh-modal-panel-title {
    font-family: var(--lh-font-body);
    font-size: var(--lh-text-lg);
    font-weight: var(--lh-weight-semibold);
    color: var(--kendo-color-secondary-on-surface);
}

/* Small "Add New X" / "Use Existing IMO" toggle links (NewVesselFileModal, Figma node 898:7751) —
   plain navy text with a small icon, not Kendo's bold underlined default for FillMode="Link". Kendo's
   real rendered class list for a Link-fill button is `k-button k-button-link`, and its own theme CSS
   targets that combined selector directly — same specificity fight as .lh-nav-item-active above, so
   color/text-decoration need the matching combined selector plus !important to win regardless of
   stylesheet load order.

   Color corrected against a fresh pull of the "Add New IMO" instance (Figma node 935:22261,
   ChangeVesselModal) — that node itself carries a designer annotation ("Review add link color, weight,
   and spacing between the field and link"), and the client's own request matches it field for field:
   kendo-color-secondary-on-surface (#05347a). secondary-on-surface and plain secondary happen to
   resolve to the same hex in this theme today, but on-surface is the token the design actually names,
   so that's what's referenced here — same reasoning as preferring -on-surface/-subtle pairs over raw
   semantic tokens elsewhere in this file (the In Port status chip, the cargo Save/Cancel icons).

   Weight is plain 400/regular, NOT the --kendo-font-weight-semibold token despite its name: every
   Add-New-X/Use-Existing-IMO instance pulled across both modals (NewVesselFileModal 902:13420/1106:26557
   area, ChangeVesselModal 935:22261) exports that same variable with a "semibold,400" fallback pair —
   the variable's own name is misleading, but the fallback number is the actual applied weight. An
   earlier pass here read the variable's name at face value and shipped 600, which is what prompted the
   client's follow-up "these need a thinner font weight" — 400 is correct. */
.k-button.k-button-link.lh-modal-add-link {
    color: var(--kendo-color-secondary-on-surface) !important;
    text-decoration: none !important;
    font-family: var(--lh-font-body);
    font-size: var(--lh-text-sm);
    font-weight: var(--lh-weight-normal);
    padding: 0;
    gap: var(--kendo-spacing-1);
}

.k-button.k-button-link.lh-modal-add-link:hover {
    color: var(--kendo-color-secondary-on-surface) !important;
    text-decoration: underline !important;
}

/* Kendo's Link fill mode underlines via its inner .k-button-text span, not the button element itself,
   so the base rule's text-decoration: none above never reaches it — same fix, one level deeper. */
.k-button.k-button-link.lh-modal-add-link .k-button-text {
    text-decoration: none !important;
}

.k-button.k-button-link.lh-modal-add-link:hover .k-button-text {
    text-decoration: underline !important;
}

.lh-modal-add-link .k-icon,
.lh-modal-add-link .k-svg-icon {
    width: 16px;
    height: 16px;
}

/* NewVesselFileModal's form (Components/VesselFiles/NewVesselFileModal.razor): a four-column grid instead of
   one long column, so the whole form fits without scrolling on a laptop screen. The window itself is wide and
   sized to its content. Fields are laid out by their order in the markup (see the comments there); a field
   that needs more room takes extra columns with the span classes. minmax(0, 1fr) lets a long combobox value shrink inside its column instead of forcing it
   wider. */
.lh-modal-body.lh-vessel-file-form {
    display: grid;
    grid-template-columns: repeat(4, minmax(0, 1fr));
    align-items: start;
}

.lh-form-span-2 {
    grid-column: span 2;
}

.lh-form-span-all {
    grid-column: 1 / -1;
}

/* The "New IMO Details" panel lays its eleven particulars out six across (Vessel Name takes two), so they
   take two short rows; its heading — title, note and "Use Existing IMO" — is one row spanning them all. */
.lh-vessel-panel.lh-modal-panel {
    display: grid;
    grid-template-columns: repeat(6, minmax(0, 1fr));
    align-items: start;
}

.lh-vessel-panel-heading>* {
    flex: 0 0 auto;
}

.lh-vessel-panel-heading>.lh-itin-note-row {
    flex: 1 1 auto;
}

/* On a narrower window drop columns so labels and values aren't squeezed. */
@media (max-width: 1100px) {
    .lh-modal-body.lh-vessel-file-form {
        grid-template-columns: repeat(2, minmax(0, 1fr));
    }

    .lh-vessel-panel.lh-modal-panel {
        grid-template-columns: repeat(3, minmax(0, 1fr));
    }
}