/* sf-dialog-panels.css — per-instance SfDialog panel overrides.

   A consumer that needs custom width or internal scroll-region layout for one of its
   <SfDialog> instances cannot express that from its own scoped .razor.css file, even via
   ::deep. sfDialog.js's _relocateToBody() moves .sf-dialog (and its backdrop) to be a direct
   child of <body> the instant the dialog opens, so it's no longer a DOM descendant of
   anything in the consumer's own render tree by the time the dialog is actually visible.

   Blazor's CSS isolation compiles a consumer's `::deep .sf-dialog...` rule to
   `[consumer-scope] .sf-dialog...` — a genuine CSS descendant combinator requiring some
   element carrying the CONSUMER's own scope attribute to be an ancestor of .sf-dialog in the
   live DOM. That's briefly true (the dialog starts out nested inside the consumer's own
   wrapper markup, before JS relocates it) but permanently false from the moment
   sfDialog.js moves it — confirmed by inspecting the compiled bundle
   (obj/Debug/net8.0/scopedcss/bundle/SafetyFolder.Server.styles.css). Giving .sf-dialog a
   per-instance PanelClass (SfDialog.razor's parameter, applied directly to the element)
   doesn't fix this by itself — SfDialog.razor.css's OWN rules survive relocation only
   because that file owns .sf-dialog/.sf-dialog__body/etc. directly (its scope attribute is
   attached to the element itself, not required on an ancestor); a consumer's .razor.css file
   can never reach the same elements the same way, ::deep or not — there's no ancestor of
   .sf-dialog left carrying the consumer's scope attribute once it's under <body>.

   The only thing that keeps matching regardless of where .sf-dialog currently sits in the
   DOM is fully unscoped, global CSS — which is what this file is. It's a plain <link>
   (see Pages/_Layout.cshtml), outside Blazor's CSS isolation entirely, not a .razor.css file.
   Each block below is keyed off one consumer's unique PanelClass value, so in practice rules
   still only ever match one dialog instance — just not through Blazor's own scoping. See
   docs/ai/standards/Migrations/RiskManager.md's "footer floating" fix entry for the full
   incident writeup that led to this file existing. */

/* RiskAssessmentFormModal.razor — main wizard dialog: wide on desktop for the two-column
   control picker. SfDialog's own default width (unconditional 80vw as of 2026-09-04 — see
   CMS.md's "Shared component change: SfDialog default width" entry) already applies below
   this breakpoint; this block only adds a wider max-width cap above it. */
@media (min-width: 992px) {
    .sf-dialog.raf-main-dialog-panel {
        width: min(75rem, 95vw);
    }
}

/* RiskAssessmentFormModal.razor — PaginatedFormContainer's Previous/Next/Submit row sticks
   (position:sticky; bottom:0) to whatever scrolls it — but it's the LAST child of
   .paginated-form-container, flush against that container's own bottom edge, so there's
   never any room for it to actually hold at the viewport's bottom: the "start sticking" and
   "run out of container to stick within" points are the same scroll position. The robust fix
   doesn't fight position:sticky at all: split the dialog body into a fixed-height flex column
   where only the step content (.paginated-form) scrolls, and the actions row
   (.paginated-form-actions) sits below it as a plain, non-scrolling flex sibling — so it's
   simply always visible at the bottom of the dialog, the same way SfDialog's own Cancel
   footer already is, regardless of how much or how little step content there is. */
.sf-dialog.raf-main-dialog-panel .sf-dialog__body {
    display: flex;
    flex-direction: column;
    overflow: hidden;
}

.sf-dialog.raf-main-dialog-panel .paginated-form-container {
    flex: 1;
    min-height: 0;
    margin: 0;
}

.sf-dialog.raf-main-dialog-panel .paginated-form {
    /* overflow-x must be set explicitly alongside overflow-y: the CSS overflow spec doesn't
       allow "visible" to pair with a non-visible value on the same box, so leaving this
       unset made the browser treat it as auto too — and Bootstrap's .row (used in Step 3)
       uses negative left/right margins for its gutters, which was enough spillover to
       trigger a horizontal scrollbar that never existed before this element scrolled. */
    overflow-x: hidden;
    overflow-y: auto;
    min-height: 0;
}

/* RiskAssessmentFormModal.razor — PaginatedFormContainer's own Previous/Next/Submit row is
   replaced by the unified footer (Cancel + Previous + Next/Save together, instead of Cancel
   sitting separately in SfDialog's own footer) — hide the built-in row rather than trying to
   repurpose it, since its buttons aren't exposed as anything else can redirect to. */
.sf-dialog.raf-main-dialog-panel .paginated-form-actions {
    /* !important is required here: the element also carries Bootstrap's .d-flex utility
       class (class="paginated-form-actions d-flex ..."), and Bootstrap's display utilities
       are themselves !important by design (so they can reliably override component styles)
       — a plain display:none loses to that regardless of selector specificity. */
    display: none !important;
}

/* RiskAssessmentFormModal.razor — control-preview / create-control dialogs: a bit wider than
   the SfDialog default, matching their previous min(900px, 95vw) sizing. */
@media (min-width: 768px) {
    .sf-dialog.raf-preview-dialog-panel,
    .sf-dialog.raf-create-dialog-panel {
        width: min(56rem, 95vw);
    }
}

/* MusterPlanningUpsertComponent.razor — create/edit dialog: slightly wider on desktop for the
   three stage editors. SfDialog's own 80vw default still applies below this breakpoint. */
@media (min-width: 768px) {
    .sf-dialog.mpu-dialog-panel {
        width: 42rem;
    }
}

/* RiskAssessmentAreaFormModal.razor — create/edit dialog: slightly wider on desktop for the
   appearance row. SfDialog's own min(90vw, 32rem) default still applies below this
   breakpoint. */
@media (min-width: 768px) {
    .sf-dialog.rafm-area-dialog-panel {
        width: 42rem;
    }
}

/* VesselCertificatesIndex.razor — create/edit dialog (_createDialog only): SfDialog itself is
   already an unconditional 80vw at every width (no width media query of its own) — this
   block only adds a max-width cap on desktop so the dialog doesn't keep growing past a
   readable line length on very wide screens. It does not change the width below 768px. */
@media (min-width: 768px) {
    .sf-dialog.vc-create-dialog-panel {
        width: 80vw;
        max-width: var(--sf-content-max);
    }
}