/*
    Enquiries: the public contact and quote form, and the staff inbox that receives them.

    One sheet for both halves because they are one feature, and because the studio's palette is
    already defined in app.css - these rules only add what those two screens need. Every selector
    here is under .contact* or .inbox*, so this file cannot reach any other page.

    The public half borrows the site's serif and generous measure; the staff half borrows the denser
    admin type. They are the same business, seen from the two ends of the same message.
*/

/* ================================================================ the public form */

.contact {
    max-width: 42rem;
}

.contact-lede {
    font-size: 1.125rem;
    color: var(--ink-soft);
}

.contact-attached {
    margin: 0 0 2rem;
    padding: 1rem 1.1rem;
    border: 1px solid var(--rule);
    border-left: 4px solid var(--sapele);
    border-radius: 3px;
    background: var(--maple-deep);
}

.contact-attached h2 {
    font-size: 1.0625rem;
    margin-bottom: 0.35rem;
}

.contact-attached p {
    margin: 0;
}

.contact-field {
    margin-bottom: 1.5rem;
}

.contact-field label {
    display: block;
    font-weight: 700;
    margin-bottom: 0.3rem;
}

.contact-optional {
    font-weight: 400;
    color: var(--ink-soft);
}

/*
    Not `input[type="text"]`. Blazor's <InputText> renders a bare <input> with no type attribute,
    which is a text input to the browser and invisible to that selector - the admin sheet records
    the same trap, found by a screenshot of three fields at the browser's default width sitting
    beside one that filled its container.
*/
.contact-field input:not([type="hidden"]),
.contact-field textarea {
    width: 100%;
    padding: 0.5rem 0.6rem;
    border: 1px solid var(--ink-soft);
    border-radius: 2px;
    background: #fff;
    color: var(--ink);
    font: inherit;
    font-size: 1rem;
}

.contact-field textarea {
    line-height: 1.6;
    resize: vertical;
}

/*
    A field that failed is marked in the border AND in words below it. Colour alone fails WCAG 1.4.1,
    and someone who cannot see the red border is exactly the person who most needs the sentence.

    Targets Blazor's own `invalid` class rather than [aria-invalid="true"]. InputBase maintains
    aria-invalid itself from the EditContext and REMOVES one the page wrote by hand, so a selector on
    the attribute styles nothing - the page has to put the failure into the context, and this class
    and that attribute then arrive together.
*/
.contact-field input.invalid,
.contact-field textarea.invalid {
    border-color: #a3231b;
    border-width: 2px;
}

.contact-hint {
    margin: 0.35rem 0 0;
    font-size: 0.9375rem;
    color: var(--ink-soft);
}

/*
    Shown only when the security check could not load — see turnstile.js.

    Deliberately NOT styled as an error. Nothing has gone wrong for the customer and their message
    will send exactly as it would have; red would tell them the form is broken, which is the belief
    that makes somebody close the tab. A soft rule beside it, in the sapele the rest of the page
    uses for asides, is enough to say "read this" without saying "you have a problem".
*/
.contact-turnstile-error {
    margin-top: 0.75rem;
    padding: 0.6rem 0.9rem;
    border-left: 3px solid var(--sapele);
    background: var(--maple-deep);
}

.contact-turnstile-error__code {
    /* The code matters to whoever is diagnosing it and to nobody else on the page. */
    color: var(--ink-soft);
    font-size: 0.875rem;
}

.contact-field-error {
    margin: 0.4rem 0 0;
    font-weight: 700;
    color: #8c1c15; /* darkened from the border colour to clear 4.5:1 on the maple background */
}

.contact-notice {
    margin: 0 0 2rem;
    padding: 0.9rem 1.1rem;
    border-left: 4px solid var(--sapele);
    background: var(--maple-deep);
    max-width: none;
}

.contact-notice--error {
    border-left-color: #a3231b;
    background: #fdf6f4;
}

.contact-notice h2 {
    font-size: 1.0625rem;
    margin-bottom: 0.4rem;
}

.contact-notice ul {
    margin: 0;
    padding-left: 1.25rem;
}

.contact-notice li + li {
    margin-top: 0.35rem;
}

.contact-button {
    display: inline-block;
    padding: 0.6rem 1.4rem;
    border: 1px solid var(--ink);
    border-radius: 2px;
    background: #fff;
    color: var(--ink);
    font: inherit;
    font-size: 1.0625rem;
    text-decoration: none;
    cursor: pointer;
}

.contact-button--primary {
    background: var(--epoxy);
    border-color: var(--epoxy);
    color: var(--maple);
}

.contact-button:hover {
    border-color: var(--sapele);
}

.contact-privacy {
    margin-top: 1.25rem;
}

.contact-reference code {
    font-size: 1rem;
    padding: 0.1rem 0.35rem;
    background: var(--maple-deep);
    border-radius: 2px;
    word-break: break-all;
}

/*
    THE DECOY. display:none rather than the visually-hidden clipping pattern, and the difference is
    the whole point: clipped content stays focusable and stays in the accessibility tree, so a
    keyboard user would tab into a field that files their enquiry as spam and a screen reader would
    read them an instruction meant for a robot. display:none removes it from both outright.

    It is still in the DOM as an ordinary text input, which is what the scrapers this catches fill
    in. type="hidden" would not be - they all skip those. See SubmissionGuard.HoneypotValue.
*/
.contact-decoy {
    display: none;
}

/* ================================================================ the staff inbox */

.inbox-tabs {
    list-style: none;
    display: flex;
    flex-wrap: wrap;
    gap: 0.5rem;
    margin: 0 0 1.5rem;
    padding: 0;
}

.inbox-tab {
    display: inline-block;
    padding: 0.4rem 0.9rem;
    border: 1px solid var(--rule);
    border-radius: 999px;
    background: #fff;
    color: var(--ink);
    text-decoration: none;
    font-size: 0.9375rem;
}

.inbox-tab:hover {
    border-color: var(--sapele);
}

/*
    The selected tab is marked three ways - filled, bordered, and carrying aria-current in the
    markup. A filter whose state is only a background colour is a filter that lies to anyone reading
    the page in monochrome, and "which pile am I looking at?" is the question this row answers.
*/
.inbox-tab--current {
    background: var(--epoxy);
    border-color: var(--epoxy);
    color: var(--maple);
    font-weight: 700;
}

.inbox-status {
    display: inline-block;
    padding: 0.1rem 0.55rem;
    border: 1px solid currentcolor;
    border-radius: 999px;
    font-size: 0.8125rem;
    white-space: nowrap;
}

/*
    New is the one that has to shout. Everything else is a state Scott has already seen; an unread
    message is work nobody has touched, and it is the entire reason he asked for this screen.
*/
.inbox-status--new {
    background: var(--epoxy);
    border-color: var(--epoxy);
    color: var(--maple);
    font-weight: 700;
}

.inbox-status--acknowledged {
    color: var(--sapele);
}

.inbox-status--inprogress {
    color: #7a5a12;
}

.inbox-status--answered {
    color: #2f6b3a;
}

.inbox-status--closed {
    color: var(--ink-soft);
}

.inbox-status--spam {
    color: #a3231b;
}

/*
    The grid scrolls inside itself on a narrow screen instead of pushing the page sideways. The
    min-width is what makes the columns legible while it does: without it the browser simply
    squeezes five columns into 390 pixels and every cell wraps to one word per line, which is what
    the mobile screenshot showed before this existed.
*/
.inbox-table-scroll {
    overflow-x: auto;
}

.inbox-table-scroll .admin-table {
    min-width: 46rem;
}

/* "7 Aug 2026, 19:06 UTC" is one fact and reads as nonsense broken across four lines. */
.inbox-table-scroll td time {
    white-space: nowrap;
}

.inbox-preview {
    display: block;
    color: var(--ink-soft);
    font-size: 0.9375rem;
    margin-top: 0.2rem;
}

.inbox-pager {
    margin-top: 1.5rem;
    display: flex;
    gap: 1rem;
    align-items: center;
}

/* --------------------------------------------------- one request */

.inbox-detail-grid {
    display: grid;
    gap: 2rem;
    grid-template-columns: minmax(0, 3fr) minmax(0, 2fr);
    align-items: start;
}

@media (max-width: 62rem) {
    .inbox-detail-grid {
        grid-template-columns: 1fr;
    }
}

.inbox-facts {
    margin: 0 0 1.5rem;
    display: grid;
    grid-template-columns: max-content minmax(0, 1fr);
    gap: 0.35rem 1rem;
    font-size: 0.9375rem;
}

.inbox-facts dt {
    font-weight: 700;
    color: var(--ink-soft);
}

.inbox-facts dd {
    margin: 0;
    word-break: break-word;
}

/*
    The customer's own words, laid out the way they laid them out. pre-wrap rather than a paragraph
    per line because somebody specifying a sign types the four lines they want carved, and collapsing
    that whitespace would destroy the meaning of the message - RequestDocument stores it with the
    line endings normalised precisely so this can be true.
*/
.inbox-message {
    white-space: pre-wrap;
    overflow-wrap: anywhere;
    padding: 1rem 1.1rem;
    border: 1px solid var(--rule);
    border-radius: 3px;
    background: #fff;
    max-width: none;
}

.inbox-thread {
    list-style: none;
    margin: 0;
    padding: 0;
}

.inbox-note {
    border-left: 3px solid var(--rule);
    padding: 0.5rem 0 0.5rem 0.9rem;
    margin-bottom: 1rem;
}

.inbox-note--customer {
    border-left-color: var(--sapele);
}

.inbox-note--system {
    border-left-color: #a3231b;
    background: #fdf6f4;
}

.inbox-note__meta {
    display: block;
    font-size: 0.8125rem;
    color: var(--ink-soft);
    margin-bottom: 0.25rem;
}

.inbox-note__body {
    margin: 0;
    white-space: pre-wrap;
    overflow-wrap: anywhere;
    max-width: none;
}

.inbox-note__shared {
    display: inline-block;
    margin-left: 0.4rem;
    padding: 0 0.4rem;
    border: 1px solid currentcolor;
    border-radius: 999px;
    font-size: 0.75rem;
}

.inbox-checkbox {
    display: flex;
    align-items: flex-start;
    gap: 0.5rem;
    margin-bottom: 1rem;
}

.inbox-checkbox input {
    width: auto;
    margin-top: 0.35rem;
}

.inbox-checkbox label {
    font-weight: 400;
    margin: 0;
}