/* Styles for the scaffolded Identity pages under /Account, which use
   Bootstrap rather than MudBlazor. Everything else in the portal is themed
   through PortalTheme.cs, so this file is deliberately small and covers only
   what Bootstrap would otherwise leave in its own colours. */

html, body {
    font-family: Arial, Helvetica, "Segoe UI", sans-serif;
}

/* The button and form rules that used to live here were overrides of
   Bootstrap's defaults. Bootstrap is gone; the account pages carry their own
   styling in account.css and everything else is MudBlazor. */

.content {
    padding-top: 1.1rem;
}

h1:focus {
    outline: none;
}

/* Identifiers line up wherever they appear. */
/* Identifiers. Arial throughout was asked for, so these keep the same face
   and earn their scannability from figures that line up and a little extra
   letter-spacing rather than from a second family. */
.mono, code {
    font-family: Arial, Helvetica, "Segoe UI", sans-serif;
    font-variant-numeric: tabular-nums;
    letter-spacing: .02em;
}

.valid.modified:not([type=checkbox]) {
    outline: 1px solid #2C622C;
}

.invalid {
    outline: 1px solid #A6432F;
}

.validation-message {
    color: #A6432F;
}

/* The error bar Blazor shows when a circuit dies. Brick rather than the
   template's red, so it belongs to the same palette as everything else. */
#blazor-error-ui {
    color-scheme: light only;
    background: #F1B53D;
    color: #1D1D1B;
    bottom: 0;
    box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
    display: none;
    left: 0;
    padding: 0.6rem 1.25rem 0.7rem 1.25rem;
    position: fixed;
    width: 100%;
    z-index: 1000;
}

#blazor-error-ui .dismiss {
    cursor: pointer;
    position: absolute;
    right: 0.75rem;
    top: 0.5rem;
}

/* Identifiers - order numbers, containers, part codes - are quoted verbatim
   in this business, so they use the mono face and line up in a column. */
.portal-num {
    font-family: Arial, Helvetica, "Segoe UI", sans-serif;
    font-variant-numeric: tabular-nums;
    letter-spacing: .02em;
}

/* =====================================================================
   Classes handed to MudBlazor components
   ---------------------------------------------------------------------
   These belong here rather than in a component's .razor.css because of how
   Blazor CSS isolation works: the scope attribute is stamped onto HTML
   elements written in a .razor file, never onto a child component's rendered
   root. A rule for a class passed as Class="..." to a Mud component therefore
   compiles to `.that-class[b-xxxxx]` and matches nothing whatsoever.

   That is not a theoretical point. The app bar had no background and the
   navigation kept MudBlazor's own colours for exactly this reason, which is
   what made the day view unreadable: white-on-dark text sitting on a light
   ground, and deep forest green nav links on a navy drawer.

   Anything reachable through a plain element inside its own component uses
   `::deep` in that component's own file instead. Only the roots are here.
   ===================================================================== */

/* ------------------------------------------------------------------- bar
   The navy itself comes from the theme's AppbarBackground through MudBlazor's
   own .mud-appbar rule, so only the edge is set here. */
.portal-bar {
    border-bottom: 1px solid rgba(255, 255, 255, 0.1);
}

/* A green hairline under the whole frame: the one place the brand colour sits
   against the chrome, which is enough to place it without competing with the
   status colours the screens rely on. */
.portal-bar::after {
    content: "";
    position: absolute;
    inset: auto 0 -1px 0;
    height: 2px;
    background: #2C622C;
}

.portal-bar__avatar {
    font-size: 0.6875rem;
    font-weight: 600;
}

/* ------------------------------------------------------------------ main
   The bar is 56px; MudBlazor's own pt-16 assumes 64. Set explicitly so
   content clears the bar without a gap under it. */
.portal-main {
    padding-top: 56px;
    min-height: 100vh;
    background: var(--mud-palette-background);
}

/* The customer-preview banner, pinned under the bar. Below MudBlazor's appbar
   layer (1300) so a menu still opens over it, above everything else so the
   content cannot scroll past it. */
.viewas {
    position: sticky;
    top: 56px;
    z-index: 1100;
}

/* ------------------------------------------------------------------- nav
   The bug the screenshot showed: MudBlazor paints an active nav link in the
   palette's primary colour, and primary is AKVA's deep forest green
   (#234923). Against a navy drawer that is very nearly invisible - "Customer
   Orders" and "Customers" had all but disappeared.

   Fixed by taking the colour decision away from the palette. A drawer this
   dark needs its own contrast rules, and every state below is stated
   explicitly rather than inherited, so a palette change cannot make the
   navigation unreadable again. !important is deliberate: MudBlazor's own
   selectors are more specific than a bare class. */
.portal-nav {
    padding: 0.5rem 0;
}

.portal-nav .mud-nav-link {
    color: #C3CCD9 !important;
    font-size: 0.875rem;
    padding-top: 0.5rem;
    padding-bottom: 0.5rem;
}

.portal-nav .mud-nav-link .mud-nav-link-icon {
    color: #8E9BAD !important;
}

/* White text on a lifted ground, with a gold marker down the left edge. Gold
   appears in two places in the whole portal - here and on something that
   needs attention - which is what keeps it meaning anything. */
.portal-nav .mud-nav-link.active {
    color: #FFFFFF !important;
    background: rgba(255, 255, 255, 0.1);
    box-shadow: inset 3px 0 0 #F1B53D;
    font-weight: 700;
}

.portal-nav .mud-nav-link.active .mud-nav-link-icon {
    color: #F1B53D !important;
}

.portal-nav .mud-nav-link:hover {
    color: #FFFFFF !important;
    background: rgba(255, 255, 255, 0.06);
}

.portal-nav .mud-nav-link:hover .mud-nav-link-icon {
    color: #FFFFFF !important;
}

.portal-nav .mud-nav-link:focus-visible {
    outline: 2px solid #F1B53D;
    outline-offset: -2px;
}

/* The Administration heading sits quieter than the links it introduces, but
   not so quiet it disappears - which was the other half of the same problem. */
.portal-nav .mud-nav-group > .mud-nav-link {
    color: #8E9BAD !important;
    font-size: 0.6875rem;
    font-weight: 700;
    letter-spacing: 0.1em;
    text-transform: uppercase;
}

.portal-nav .mud-nav-group > .mud-nav-link .mud-nav-link-icon,
.portal-nav .mud-nav-group > .mud-nav-link .mud-nav-link-expand-icon {
    color: #8E9BAD !important;
}

/* A group heading that carries a roll-up count: the title and its chip on one
   line, inside MudNavGroup's TitleContent slot.

   This one class does sit on a plain element and would work as scoped CSS, but
   it lives here with the rest of the nav so that the next person looking for
   how the rail is styled finds all of it in one file. */
.portal-nav .portal-nav__group {
    display: flex;
    align-items: center;
    width: 100%;
}

/* A group holding the active page keeps its heading visible. */
.portal-nav .mud-nav-group:has(.active) > .mud-nav-link {
    color: #C3CCD9 !important;
}

.portal-nav .mud-divider {
    border-color: rgba(255, 255, 255, 0.14);
    margin-left: 0.875rem;
    margin-right: 0.875rem;
}

/* Numbers read as data. Gold when something is waiting on a person, plain
   otherwise - the count of open orders is information, not an alarm. */
.portal-nav .mud-chip {
    font-variant-numeric: tabular-nums;
    letter-spacing: 0.02em;
    height: 1.25rem;
    min-width: 1.25rem;
    background: rgba(255, 255, 255, 0.14) !important;
    color: #E9EDF2 !important;
    font-weight: 700;
}

.portal-nav .mud-chip.mud-chip-color-warning {
    background: #F1B53D !important;
    color: #14223A !important;
}

/* ------------------------------------------------------------ card roots
   Three cards whose own outermost element is a MudPaper. Only the parts that
   must sit on that element are here; everything inside stays scoped. */

/* Full height so three tiles in a row line up however many alerts each
   carries, with the alerts pushed to the bottom edge. */
.btile {
    display: flex;
    flex-direction: column;
    height: 100%;
    border-radius: 8px;
}

.opc {
    border-radius: 8px;
}

/* The customer's answer card. */
.custsum__eyebrow {
    display: block;
}

/* The one genuinely large piece of type in the portal. A customer reads this
   sentence and leaves; everything under it is supporting detail. */
.custsum__answer {
    font-weight: 700;
    line-height: 1.15;
    max-width: 32ch;
}


/* ------------------------------------------------------------ wide tables
   MudSimpleTable renders a div and a table and nothing else - no
   mud-table-container, which is where MudBlazor's own overflow-x lives. So a
   ten-column item list with nowrap figures in it had nothing to scroll inside
   and pushed the whole page sideways instead, taking the navigation and the
   header with it.

   Every simple table in the portal carries this. On a table that already fits
   it does nothing at all, which is why it can be applied without deciding
   table by table.

   contain-inline-size stops the scroller from participating in its parent's
   width calculation, so a wide table inside a flex or grid column scrolls
   rather than stretching the column. */
.portal-scroll {
    overflow-x: auto;
    contain: inline-size;
}

/* Squashing is the other failure. Below this the columns are too narrow to
   read and the row wraps to four lines, so past it the table scrolls instead.
   Only on the tables that genuinely have that many columns - the rest keep
   the plain scroller above and fit as they always did. */
.portal-scroll--wide table {
    min-width: 52rem;
}


/* ------------------------------------------------- a table on a phone
   A table with seven columns does not become readable by scrolling
   sideways; it becomes a thing you scrub back and forth across, reading
   one column at a time and losing your row. Below the small breakpoint
   the three screens somebody actually opens on a phone stop being tables
   and become a stack of cards, one per row, each cell labelled with the
   heading it sat under.

   The label comes from data-label on the cell rather than from the
   thead, because CSS cannot read one element's text into another. That
   is the cost of this pattern and the reason it is applied to three
   tables rather than all thirty-nine: every cell has to carry its own
   heading, and a heading that drifts from the column above it is worse
   than no heading.

   A cell with no data-label - the actions column, the row number -
   renders as a plain block with no label beside it.

   The pick and receive screens are not here. They were built for a phone
   from the start and are not tables at all. */
@media (max-width: 599.98px) {
    /* Every selector below names `table` as well as the wrapper. MudBlazor
       styles these through `.mud-simple-table.mud-table-dense * tr td`, which
       is two classes - and two classes beat any number of elements, so a
       selector of ours naming only `.portal-cards` loses however far down the
       file it sits. Specificity is not affected by a media query or by source
       order.

       So each selector below names the MudBlazor class it is overriding. That
       is uglier than a bare `.portal-cards` and more honest than reaching for
       !important: it says what it is fighting, and it stops working loudly
       rather than quietly if MudBlazor ever renames it.

       Two versions of this were wrong before it was right - labels dropped
       into cells that were still table cells, then padding that lost to a
       two-class rule and let a progress bar run over its own heading. Both
       were found by looking at wwwroot/dev/cards-preview.html, which exists
       because these three screens are behind a sign-in. */
    .mud-simple-table.portal-cards table,
    .mud-simple-table.portal-cards table tbody,
    .mud-simple-table.portal-cards table tr,
    .mud-simple-table.portal-cards table tbody tr td {
        display: block;
        width: auto;
    }

    /* The headings move into the cells, so the row of them goes. Hidden
       rather than removed from the markup: on a wider screen it is the
       table's header again, and a screen reader still meets it in source
       order. */
    .mud-simple-table.portal-cards table thead {
        display: none;
    }

    /* The min-width that makes a wide table scroll on a laptop would make
       this stack 52rem wide, so it is lifted here along with the scroller
       that carried it. */
    .portal-scroll--wide table {
        min-width: 0;
    }

    .portal-cards {
        overflow-x: visible;
    }

    .mud-simple-table.portal-cards table tr {
        border: 1px solid var(--mud-palette-lines-default);
        border-radius: 6px;
        padding: 0.5rem 0.75rem;
        margin-bottom: 0.625rem;
        background: var(--mud-palette-surface);
    }

    /* The brick edge a row uses to mean "look at this" runs down the side
       of the card the same way it ran down the side of the row. */
    .mud-simple-table.portal-cards table tr.inv-row--over,
    .mud-simple-table.portal-cards table tr.items__row--over {
        box-shadow: inset 3px 0 0 #A6432F;
    }

    /* The label is taken out of the flow and the content is pushed clear of
       it, rather than the two being flex items with space between them.

       A cell is not always one thing: "on" carries a consignment number and
       its date, "value" a total and a unit price, "on hand" a figure and its
       unit. As flex items with space-between, each of those was scattered to
       opposite edges of the card - the number hard left, the date hard right,
       with a gap in the middle that meant nothing. Out of the flow, the label
       sits where it always does and everything after it reads as one block of
       content. */
    .mud-simple-table.portal-cards table tbody tr td {
        position: relative;
        display: block;
        border: none;
        padding: 0.3rem 0 0.3rem 8.5rem;
        min-height: 1.5rem;

        /* Content to the right, label to the left, whatever the column
           carried inline on a wide screen. */
        text-align: right !important;
    }

    .mud-simple-table.portal-cards table tbody tr td::before {
        content: attr(data-label);
        position: absolute;
        left: 0;
        top: 0.4rem;
        width: 8rem;
        text-align: left;
        font-size: 0.6875rem;
        font-weight: 700;
        letter-spacing: 0.04em;
        text-transform: uppercase;
        color: var(--mud-palette-text-secondary);

        /* A heading longer than the space it has is cut rather than wrapped
           under the value it names. */
        overflow: hidden;
        text-overflow: ellipsis;
        white-space: nowrap;
    }

    /* No heading, no label - and then nothing to sit opposite, so the
       cell takes the full width. The actions column is the case: a row of
       buttons reads better spread across the foot of a card than crushed
       against one edge of it. */
    .mud-simple-table.portal-cards table tbody tr td:not([data-label])::before {
        content: none;
    }

    .mud-simple-table.portal-cards table tbody tr td:not([data-label]) {
        padding-left: 0;
        text-align: left !important;
    }

    /* What the card is about leads it, above a rule, with no label of its
       own - the part number and its description, or the item on a line.

       Named rather than taken from :first-child. On the order lines the
       first cell is the line number, which is a bare digit that needs its
       label more than any other cell on the card, and a positional rule
       would have suppressed exactly that one. */
    .mud-simple-table.portal-cards table tbody tr td.cards__lead {
        display: block;
        padding: 0 0 0.375rem;
        margin-bottom: 0.25rem;
        text-align: left !important;
        border-bottom: 1px solid var(--mud-palette-lines-default);
    }

    .mud-simple-table.portal-cards table tbody tr td.cards__lead::before {
        content: none;
    }
}