.application-body.application-mail {
    /* Mail app styling. Compiled into the per-app block in
       assets/base/applications/_registry.scss by
       scripts/compile_sass.py:generate_registry_scss(). The CSS field on the
       configuration App record is appended on top of this file at compile time.

       Mirrors the Favourites app (apps/favourites/styling/all.css): the native
       interface reuses the generic .pat-link-list.cards layout plus a circular
       letter avatar painted in the app colour. */

    & {
        --app-colour: var(--app-colour-mail, #0078D4);
    }

    .document-body {
        --pat-x-list-padding: 20px;
    }

    /* The compose rich-editor's checklist option doesn't apply to e-mail. It has
       no allow_* flag of its own (it rides on allow_unordered_list), so hide its
       menu row here. */
    #editor-toolbar-mail-markdown li:has(.button-checklist) {
        display: none;
    }

    /* Same treatment for the image button, for the opposite reason: the toolbar
       MUST carry it (pat-tiptap only registers the Image node when the toolbar has
       a .button-image, and without that node a pasted screenshot has nowhere to
       land — see kik-mail-paste-image.js), but its picker inserts a link to an
       image on THIS server, which no recipient can load. Pasting stages the bytes
       and sends them inline; that's the path we want people on. */
    #editor-toolbar-mail-markdown li:has(.button-image) {
        display: none;
    }

    /* Sender avatar: the sender's first letter painted in the app colour over a
       10% wash (same treatment as the Favourites team-space avatars). Both list
       shapes: the message list is a pat_table (mail.tables), the compose
       recipients and attachment lists are still pat-link-lists. */
    .pat-link-list .pat-avatar,
    .pat-table .pat-avatar {
        display: flex;
        align-items: center;
        justify-content: center;
        box-sizing: border-box;
        aspect-ratio: 1;
        border-radius: 50%;
        border: 1px solid var(--app-colour);
        background: color-mix(in srgb, var(--app-colour) 10%, white);
        color: var(--app-colour);
        font-weight: 700;
        font-size: 1.6em;
        line-height: 1;
        text-transform: uppercase;
    }

    /* Message detail: the subject page-head at a calmer size on phones — long
       (marketing) subjects at the stock 2.25rem pat-rich h1 fill half the
       screen before the message even starts. The line-height must be unitless:
       the brand pins the h1 line-height at a fixed 2.7rem, which reads as
       double-spacing under a smaller font.

       ONE, as every title on a phone has it (themes/usugami: "the line box is the
       type size") — so the byline stands the same distance under the subject as
       it does under the list's "Inkomend" (Daniel, 2026-09-26: "the distance
       between byline and title should be the same on all screens"). At 1.2 the
       subject's half-leading pushed its byline 3px further down than the list's. */
    @container screen style(--screen-small: true) {
        #page-head-mail-message h1 {
            font-size: 1.7rem;
            line-height: 1;
        }
    }

    /* Roundcube (iframe) mode — full-bleed webmail. */
    #application-body-mail .mail-webmail-frame {
        display: block;
        width: 100%;
        height: 100%;
        border: 0;
    }

    /* Message detail toolbar on phones: the Trash, Create-task, Create-event and
       Reply-all controls crowd the sticky action toolbar, so they're pulled off it
       and surfaced as items in the More menu instead (the .mail-phone-only <li>s in
       #mail-more-menu, mirroring each toolbar control's wiring).

       The two states are symmetric on the --screen-small flag (set on the ``screen``
       container ≤769px): the toolbar copies hide on phones, the menu copies hide
       everywhere else. The context-menu popover mounts on document.body — itself the
       ``screen`` container — so the style query resolves inside it too. */
    @container screen style(--screen-small: true) {
        #mail-message-toolbar .mail-toolbar-wide-only {
            display: none;
        }
    }

    /* On phones the generic .document-body fills itself with an opaque white
       (--colour-base-background, components/document-body.css). That fill covered
       the Mail app body's own background, which is the whole point of this app:
       #application-body-mail carries --application-body-background-colour — either
       the opened e-mail's own outer colour (the per-mail tint the message view
       sets) or the default canvas. The message body iframe is pinned to that same
       var (_message_body.html), so the message read as a tinted block on a white
       sheet and the chrome no longer matched the mail.

       Re-point the fill at that var instead of removing it. It must stay OPAQUE:
       on phones the sidebar and the document body occupy the same space and
       focus-* decides which is on top, so this fill is what hides the folder list
       behind an open message. `transparent` (the Chokhmah / Search opt-out) showed
       the two panes through each other. */
    @container screen style(--screen-small: true) {
        .document-body {
            background-color: var(--application-body-background-colour);
        }
    }
    @container screen style(--screen-small: false) {
        .pat-menu-list .mail-phone-only {
            display: none;
        }
    }

    /* THE MAILBOXES WELL (sidebar_boxes.html): every box under a separation
       header carrying its ADDRESS, with its vendor's brandmark before it. A team
       space's address (<space>.<hub>@hub.kikaron.com) is longer than the sidebar
       is wide, so the address is one line with an ellipsis (hover for the whole
       thing) — min-width:0 is what lets it shrink at all, since a flex item's
       automatic minimum is its min-content width, which for an unbroken address
       is the whole string. The header is a flex row so mark and words sit on one
       line — and that is ALL this adds: size, weight and spacing are the well
       separation header's own (components/well.css), untouched (Daniel,
       2026-09-30: "use well separation headers within the well Postvakken" — a
       first version restyled it smaller and fainter, which made it a different
       heading from the one every other well divides itself with). */
    #sidebar-mail .mail-box-header {
        display: flex;
        align-items: center;
        gap: 0.4em;
        min-width: 0;

        .mail-box-address {
            min-width: 0;
            overflow: hidden;
            text-overflow: ellipsis;
            white-space: nowrap;
        }

        .well-vendor-brandmark,
        .mail-box-glyph {
            flex: none;
        }

        svg.well-vendor-brandmark {
            width: 1.1em;
            height: 1.1em;
        }
    }

    /* The folders of a cold box, while they load: the lazy anchor stands where
       the list will, one row tall, so the box below it does not jump up and
       down as the folders arrive. */
    #sidebar-mail .mail-box-folders-loader {
        height: 2.5em;
    }

    /* SEPA "Betaal" card (mail.payments) — the euro tile on the pat-message
       media+action row. Sizing/centring/spacing come from the shared pat-message
       vendor CSS; this only paints the tile green and the amount weight. */
    .kik-pay-card .icon.euro {
        background-color: color-mix(in srgb, green 12%, white);
        color: color-mix(in srgb, green 70%, black);
        border: 1px solid color-mix(in srgb, green 35%, transparent);
        font-weight: 700;
    }
    .kik-pay-card .message-byline { font-variant-numeric: tabular-nums; }

    /* Compose/reply body on a phone: #mail-body is a rich-text well, and a well's
       card treatment (20px padding, white ground, shadow ring) buys nothing here —
       it is the whole screen, it sits directly under a properties well that IS a
       card, and its inset stacks on the page's own --small-screen-padding, which
       is what squeezes the quoted reply into a column. Strip the card and let the
       editor use the full width; the id outranks the literal `padding: 20px` the
       pat-well mixin paints under this same container query. */
    @container screen style(--screen-small: true) {
        #mail-body {
            padding: 0;
            background: none;
            box-shadow: none;
        }
    }

    /* --- The compose toolbar's trailing end ------------------------------------
     *
     * Three things keep the bar's right-hand inset (Daniel, 2026-08-18). In a
     * window, the maximise and close toggles overlay the bar's trailing end, and
     * windowed-mode.css reserves their slot as a padding-right on the
     * quick-functions section. A padding is only ever as good as the content
     * inside it: a flex row of nowrap buttons that cannot shrink simply overflows
     * and paints straight through the reservation, which is how "Concept bewaren"
     * ended up sitting under the close button. So the controls give way first, and
     * the reservation never does.
     */

    /* (1) The empty saved-state span. It has to EXIST — it is the target the
     * autosave subform injects into, and pat-inject aborts on a missing one — but
     * an untouched composer has nothing to say, and a zero-width flex item still
     * takes a full --pat-toolbar-element-separation gap on each side: 10px of the
     * trailing cluster spent on a control that paints nothing. Out of the flow
     * until it has words. */
    .mail-draft-state:empty {
        display: none;
    }

    /* (2) "Concept bewaren" AND "Verstuur" collapse to their marks when the
     * composer is narrow — the same treatment, in the same container band, that
     * Cancel beside them already gets from toolbar.css. Three text buttons is
     * more label than a narrow window can carry, and each of the three means
     * something as a glyph: a paper plane sends, a floppy keeps a draft, a
     * circled × throws the message away.
     *
     * SEND HELD ITS WORD HERE UNTIL 2026-08-20, on the reasoning that the primary
     * action never collapses — and what a phone actually did with that was worse
     * than a collapse: it is the one flexible control on the cluster (rule 3), so
     * the row took its width out of Send alone until the button was 36px of blue
     * with "Verstuur" clipped across the paper plane and no mark to be seen
     * (Daniel). A disc it cannot shrink says the same thing and stays legible;
     * it keeps its `.default` accent, so it is still the one coloured control on
     * the bar.
     *
     * Geometry only — ALMOST. The mark is an inline SVG, and toolbar-icons.css
     * centres one absolutely over an indented-away label in this very band, so
     * this rule's job is to give it the square box to be centred in. That holds
     * for Save draft, which carries ``icon-floppy``. It does NOT hold for Send.
     *
     * The house rule keys the collapse on the ``icon-`` substring, and hands a
     * .pat-button without one back to ``position: static`` on the reasoning that
     * such a button keeps its label at every width and therefore keeps its mark
     * inline (toolbar-icons.css, "…but only a control that ACTUALLY collapses").
     * Send is the exception that reasoning does not know about: it was given a
     * label at every width when this file was written, and lost it here in
     * 2026-08-20 — the class list never followed. So its mark went back to being
     * inline content on a button whose content is indented a thousand ems away,
     * and the primary action on the phone's composer was a blank blue disc
     * (Daniel, 2026-09-02; measured at 390px: the <svg> sat at x = -17660).
     *
     * Centred HERE rather than by adding ``icon-… no-icon`` to the markup, which
     * is the other way to satisfy that rule: those two classes also strip the mark
     * at text sizes (``.no-icon … > svg { display: none }``), and above this band
     * Send does still show its word AND its plane, which is worth keeping. */
    @container screen style(--screen-small: true) {
        .pat-toolbar .pat-button.save-draft,
        .pat-toolbar .pat-button.send {
            /* The disc is what the centred mark is centred IN — stated here so it
             * does not depend on another file having made the button a containing
             * block. */
            position: relative;
            box-sizing: border-box;
            width: var(--pat-toolbar-button-height);
            min-width: var(--pat-toolbar-button-height);
            height: var(--pat-toolbar-button-height);
            padding: 0;
            overflow: hidden;
            text-indent: -1000em;
            text-align: left;
            body[dir=rtl] & { text-align: right; }
        }
        /* The same centred state the house gives a collapsed control, restated
         * for the one button on this bar its selector cannot reach. Save draft is
         * left to the house rule, which already covers it. */
        .pat-toolbar .pat-button.send > svg.kik-icon {
            display: block;
            position: absolute;
            top: 50%;
            left: 50%;
            transform: translate(-50%, -50%);
            margin: 0;
            text-indent: 0;
            /* …and the mark's own size with it. Left alone, the plane keeps the
             * line-box height the wide branch gives it — which inside a 35px disc
             * IS 35px, a drawing filling the button edge to edge while Cancel and
             * Save draft beside it sit at 21. Same token the house collapse uses. */
            width: var(--kik-toolbar-icon-size);
            height: var(--kik-toolbar-icon-size);
        }
    }

    /* (3) …and the floor under both: the trailing cluster may shrink, and its
     * flexible control — Send, the one with a label left to give — ellipsises
     * rather than pushing the row through the reserved slot. `min-width: 0` is
     * what lets a flex item shrink below its content at all; without it the
     * section is rigid at max-content whatever the window does. */
    #mail-compose-toolbar .toolbar-section.quick-functions {
        min-width: 0;

        /* …but not the one that IS its mark. A collapsed control's square is
         * its min-width, and this selector carries an id: it would out-rank the
         * collapse above and let the disc squash. Only a button still showing a
         * label has width to give. */
        > .pat-button:not(.save-draft) {
            min-width: 0;
            overflow: hidden;
            text-overflow: ellipsis;

            /* …and on a phone that is nobody. Send collapses there too (2), so
             * the one control this exemption was written for is a mark like the
             * rest — and a mark that may shrink is a mark squashed flat: it went
             * to literal zero width the moment it joined that collapse. The
             * exemption is a NARROW-WINDOW measure, not a small-screen one; above
             * the breakpoint Send is still the label with width to give, which is
             * what keeps the row out of the window frame's close.
             *
             * Nested rather than said as a `:not(.send)` above, because this rule
             * is the only thing between the collapse and a squashed disc: in here
             * it carries this selector's own id AND a class more, so it wins by
             * construction over the very declaration it is correcting. */
            @container screen style(--screen-small: true) {
                &.send {
                    min-width: var(--pat-toolbar-button-height);
                }
            }
        }
    }

    /* "(3 CC)" in the page-head byline — the small-screen stand-in for the hidden
       To/Cc grid. It is a modal opener, but it reads as part of the byline it sits
       in, so it takes the byline's own colour and only reveals the underline on
       hover: the same treatment the recipient chips get (message_view.html), for
       the same reason — a raw hyperlink mid-sentence there looks like a mistake. */
    .mail-byline-cc {
        color: inherit;
        text-decoration: none;
    }
    @media (hover: hover) {
        .mail-byline-cc:hover,
        .mail-byline-cc:focus {
            text-decoration: underline;
        }
    }

    /* ===========================================================================
       THE OPEN MESSAGE — a modal in the app's own space (mail/panels/message.html)

       These rules used to be a <style> block at the top of message_view.html, back
       when the message rendered into the document body. They address the panel's
       body root (.mail-message-panel-body) now, and live here with the rest of the
       app's CSS.
       =========================================================================== */

    /* A mail panel is a reading and writing surface, not a form dialog: it runs
       wider than the stock large panel so a message keeps its measure and the
       composer's bar has room for its own controls.

       ONE class for all of them (.mail-panel), because the dialog element outlives
       what it holds: stepping from a message to a reply to an attachment replaces
       the panel's CONTENTS and leaves the dialog alone, so a class on the dialog
       saying which of the three is up would go stale on the first step. Anything
       that differs between them keys on the content root instead — those travel
       with the content. */
    .mail-panel {
        --modal-panel-width-large: min(980px, 95%);

        /* THE PANEL'S SIDE, SAID IN THE SPACE'S UNITS — the same number the width
           above resolves to, but with every percentage rewritten as `cqw` so it can
           be mirrored into a HEIGHT: a percentage in a height resolves against the
           space's HEIGHT and would mean something else entirely. The last term is
           the panel's own max-width restated, so the side already accounts for the
           gutters and that cap never has to bind — a bound cap would narrow the
           width and leave the height where it was, which is the one thing a square
           stated in two properties must not do.

           Medium band: the stock 840px, which carries no percentage of its own. */
        --mail-panel-side: min(
            var(--modal-panel-width-medium),
            100cqw - 2 * var(--modal-panel-gutter-inline)
        );
    }

    /* Wide window: the same gate the stock `.large` width uses, asked of the same
       container (the nearest named `screen` above the dialog — the body, or the
       window in windowed mode), so the two never disagree about which band the
       panel is in. */
    @container screen style(--screen-large: true) {
        .mail-panel {
            --mail-panel-side: min(
                980px,
                95cqw,
                100cqw - 2 * var(--modal-panel-gutter-inline)
            );
        }
    }

    /* The composer holds a body editor, so give it a working height instead of
       letting an empty reply open as a shallow slot. Only while it is a panel —
       collapse-screen hands it the whole app body and states its own height. */
    @container screen style(--screen-small: false) {
        .mail-panel .mail-compose-panel-body {
            min-height: min(60vh, 620px);
        }
    }

    /* A MAIL THAT DECLARES NO COLOUR TAKES THE PANEL'S. The HTML-mail frame pins
       itself to --mail-body-background (see _message_body.html), which the message
       view sets per message when the mail states a page colour. When it doesn't,
       this is the answer: the surface the panel itself is painted in, so the frame
       and the chrome around it are one sheet either way.

       The frame's own fallback — the app body's canvas — stays for the Drive's
       read-only e-mail viewers, which render the same body in a document body
       where the canvas IS the surface. In a panel it is not, and a beige app
       canvas inside a white panel is exactly how that showed.

       Declared on the CONTENTS, not on the body: the per-message tint is set on
       the contents too (message_view.html), and a default sitting closer to the
       frame than the tint does would win the inheritance whatever its
       specificity. Same element, and there the tint's ids beat these classes. */
    /* THE SQUARE. It holds whether or not the Ask-Kiki dock is open beside the
       panel: opening the chat must not resize the mail being read. The dock used
       to cancel it — the panel stretched to the dock's full height so the two read
       as a pair — and what that actually looked like was the message reflowing
       under the reader the moment they asked a question. Beside the chat the
       square simply has less room to be a square in: the panel's max-width answers
       for the narrower space, and it stays as tall as it is wide.

       ``&`` is the app body: this file is compiled nested inside
       ``.application-body.application-mail``. */
    .mail-panel > .modal-panel-contents {
        /* A SQUARE PANEL. Mail's own shape: as tall as it is wide, whatever is
           in it — a two-line note and a twenty-line newsletter open the same
           box, and stepping from one to the next moves nothing. The content
           scrolls inside it (the contents is the scroller), and the panel's
           own max-height still caps the square in a short window.

           STATED AS A HEIGHT, NOT AS `aspect-ratio: 1 / 1` (Daniel, 2026-08-21).
           A ratio is a two-way bargain: the box has to satisfy it in whichever
           axis has least room, so in a SHORT window the max-height fed back into
           the WIDTH and the whole panel shrank. A 13" laptop with a browser
           toolbar and a screen-share bar leaves the app body around 690px, and an
           open mail came out ~650px wide there where a taller window gave it 980
           — the reading column paying for the window's height, which is not a
           trade this shape is worth.

           A height pays one way only. The width is whatever the band allows, the
           height matches it, and where there is not enough room above the panel
           its own max-height simply clips it: a mail on a short screen is then
           wider than it is tall, which is the right way for the square to give.

           NOT ON A PHONE. Collapse-screen has taken the whole app body there and
           states its own height, which this must not argue with. */
        @container screen style(--screen-small: false) {
            height: var(--mail-panel-side);
        }
    }

    /* THE WIDTH IS THE PANEL'S OWN, and the side token above is already clamped to
       the room beside it, so nothing here re-caps it. This used to carry a second
       max-width — `min(space width, 100cqh)` — which made the height a *cap on the
       width*; that is the half of the square that has gone, and the height above
       is what replaced it.

       AND NOT ON A PHONE, where the panel is not a panel: collapse-screen has
       handed it the whole app body, and a cap phrased in gutters and a square's
       side is a cap that keeps it off two edges it is supposed to be flush with
       (Daniel, 2026-08-20) — the composer opened as a 280px column with its
       toolbar overflowing both sides of it. The width below is gated the same way
       for the same reason: a screen is the shape of the screen. */
    @container screen style(--screen-small: false) {
        .pat-modal-panel.mail-panel {
            width: var(--mail-panel-side);
        }
    }

    .mail-panel > .modal-panel-contents {
        /* The frame ground is theme-steerable: sender HTML mostly assumes a
           light page (default black text), so a dark theme pins the frame to a
           light paper tone rather than its own dark canvas — until the body
           itself is dark-adapted, a dark frame around a mail's black text is an
           unreadable message. Light themes resolve the fallback: the panel's
           own canvas, as before. */
        --mail-body-background: var(--kik-mail-frame-ground, var(--colour-base-background));
    }

    /* Tighten the To/Cc/Date header grid: the global .pat-grid-list rule
       (robot.css) lays it out 30%/70% with no gap at >=769px, wasting space on the
       short labels. Override to a content-width label column + a real gap. */
    @container screen style(--screen-small: false) {
        .mail-message-panel-body .pat-grid-list {
            display: grid;
            grid-column-gap: 14px;
            grid-template-columns: 70px auto;
        }
    }

    /* Small: the To/Cc grid takes vertical space a phone doesn't have — so drop
       it, and reveal the byline's Cc count in its place (the one thing a hidden
       list of recipients can't be replaced by silence). The DATE is not part of
       this pair any more: it rides the byline at every width now, because when a
       message arrived is the last fact a narrow box should lose.

       A CONTAINER query, not a media query: this pair asked how wide the WINDOW
       was, and a message is not the window — in windowed mode a narrow pane in a
       wide window kept the desktop grid and overflowed. --screen-small is
       re-derived from the app's own box (libraries/kikaron/application-body), so it
       asks how wide the MESSAGE is. */
    .mail-byline-date-mobile {
        display: none;
    }

    @container screen style(--screen-small: true) {
        .mail-message-panel-body .message-headers.pat-grid-list {
            display: none;
        }

        .mail-byline-date-mobile {
            display: inline;
        }

        /* (A 0.35em row-gap on the title/byline hgroup and a 1.15 title line-height
           used to sit here, so the byline would not hug the subject. It stood 6px
           further off than on every other screen — the list's head, and this same
           message on a wide one — so it went: the byline's own top margin is the
           distance, everywhere. Daniel, 2026-09-26.) */

        /* The grid's own top margin used to be most of the space between the page
           head and the body; gone now that it's hidden, so the page-head's stock
           1.5rem bottom margin is the whole gap on its own — too much on a phone. */
        .mail-message-panel-body .quaive-page-head {
            margin-bottom: 0.75rem;
        }

        /* Plain-text mail (.pat-rich, no HTML body) inherits the ambient 1rem
           already, same as the byline — explicit here so it stays that way
           regardless of what else sets font-size up the tree. The HTML-mail path
           (pat-iframe) gets its own mobile floor via default-font-size-mobile in
           _message_body.html — a real media query INSIDE the frame's stylesheet,
           since custom properties can't cross the iframe boundary. */
        .mail-message-panel-body article.pat-rich.message-body {
            font-size: 1rem;
        }
    }

    /* Recipient chips (sender byline + To/Cc) read as plain text and only reveal
       the underline on hover/focus, so the name doesn't look like a raw hyperlink
       in the page head. */
    .mail-message-panel-body .mail-recipient {
        text-decoration: none;
    }

    @media (hover: hover) {
        .mail-message-panel-body .mail-recipient:hover {
            text-decoration: underline;
        }
    }

    .mail-message-panel-body .mail-recipient:focus {
        text-decoration: underline;
    }

    /* The composer's secondary button collapses to its mark ONE BAND EARLY in
       the panel. A modal's bar never gets the app's full width — at 980px it was
       still showing "Annuleren", "Concept bewaren" and "Versturen" in a track that
       could hold about two of them, so all three ellipsised at once and none of
       them read. Below --screen-large the same square treatment the small band
       already gives Save draft (rule 2 above) applies here, and Send — the primary
       action, and the one whose word carries the meaning — keeps its label.
       (Cancel collapsed with it until 2026-09-11; it is the panel's × now.) */
    @container screen style(--screen-large: false) {
        .mail-panel #mail-compose-toolbar .pat-button.save-draft {
            position: relative;
            box-sizing: border-box;
            width: var(--pat-toolbar-button-height);
            min-width: var(--pat-toolbar-button-height);
            height: var(--pat-toolbar-button-height);
            padding: 0;
            overflow: hidden;
            text-indent: -1000em;
            text-align: left;

            body[dir=rtl] & {
                text-align: right;
            }

            /* AND THE MARK STAYS. Two things were taking it away. The label is
               indented a thousand ems off-screen and an inline mark rides along
               with it — and, above the small band, toolbar-icons.css hides the
               mark on a ``no-icon`` button outright, which is exactly right for a
               button still showing its label and exactly wrong for one this rule
               has just collapsed to a disc. So the mark takes the same centred,
               shown state the house gives it on a small screen: this IS that
               state, one band early, because a modal's bar is narrower than the
               screen it sits on. */
            > svg.kik-icon {
                display: block;
                position: absolute;
                top: 50%;
                left: 50%;
                transform: translate(-50%, -50%);
                width: var(--kik-toolbar-icon-size);
                height: var(--kik-toolbar-icon-size);
                text-indent: 0;
            }
        }
    }

    /* THE RICH CONTROLS TAKE THE TITLE'S PLACE. The composer's bar leads with who
       the message is going to and follows it with the body's editor toolbar — two
       things in one leading cluster, which on a modal's bar is not wide enough for
       both plus Cancel, Save draft and Send. The addressee is worth reading while
       there is nothing else there; the moment the editor is up, its controls are
       what the bar is for.

       ``.editor-toolbar.tiptap`` is the signal, and it is the right one: pat-tiptap
       adds ``tiptap`` when it binds the editor to this toolbar, so the title stays
       while the editor is still coming up and goes exactly when the controls
       appear. */
    #mail-compose-toolbar .toolbar-section.micro-navigation:has(> .editor-toolbar.tiptap) > .toolbar-title {
        display: none;
    }

    /* THE BODY WELL IS NOT A WELL. The composer's message module is the sheet the
       user writes on — the panel around it is the card, and a second card inside it
       is one border and one shadow too many. Through the well's own tokens wherever
       there is one, so the component keeps deciding HOW each property is applied
       and this only says what to. (backdrop-filter is not var-driven on the well,
       so that one is stated directly.) */
    #mail-body.quaive-page-module-edit {
        --pat-well-padding: 0;
        --pat-well-padding-top: 0;
        --pat-well-padding-right: 0;
        --pat-well-padding-bottom: 0;
        --pat-well-padding-left: 0;
        --pat-well-box-shadow: none;
        --pat-well-background-colour: transparent;
        --pat-surface-backdrop-filter: none;

        backdrop-filter: none;
    }


    /* --- SHOW BCC ---------------------------------------------------------------
       The Bcc row is rendered on every composer and shown on demand, and the demand
       is the tickbox in the toolbar's More menu — a real checkbox in a live popover
       panel (compose_toolbar_quick_functions.html), drawn by pat-checklist like
       every other tickbox in the instance. Nothing here draws anything; this is the
       one thing CSS has to do that the component cannot, which is to let a control
       in the menu decide what a row in the form does.

       The subject is the APP BODY (``&``, since this file is nested under it): the
       menu's panel and the composer are in different subtrees — the panel is
       adopted where it was authored, the form sits in the app's modal space — and
       the app body is the box they are both certainly inside. */
    &:not(:has(.mail-bcc-state:checked)) .mail-bcc-row {
        display: none;
    }

    /* The attachments field, now that it stands on its own under the properties
       well (compose.html) instead of inside a metadata row. Two things the row
       used to do for it:

       the FILE INPUT stays out of sight. It carries the ``hidden`` attribute and
       is driven by a <label for> in the toolbar's paperclip menu — but ``hidden``
       is only a default display, and out here it met a rule that sets one, so the
       browser's own "Choose Files / No file chosen" box appeared under the well;

       and the field claims no room while there is nothing attached — no list, no
       bar, nothing but the hidden input, so an empty composer looks exactly as it
       did before. */
    #mail-compose .attachments-value input[type="file"][hidden] {
        display: none;
    }

    #mail-compose > .attachments-value:not(:has(.pat-table)) {
        display: contents;
    }

    /* ---- Thread wells ---------------------------------------------------------
       The other messages of the conversation, one collapsed well each: in the open
       message (_thread_wells.html) and, in the reply composer, the single well
       holding the message being answered (compose.html).

       HERE, NOT IN _message_body.html's inline block. That block only renders with
       a message body, and the composer has none — so the rules written there
       dressed the wells on one of the two surfaces and left the composer's at full
       strength (Daniel, 2026-09-02). */
    .mail-thread-well {
        /* THE WHOLE HEADER RECEDES. A thread well names a message you are not
           reading — the one this one answers, or the one before that — so its
           heading is a reference, and at full strength a stack of them competed
           with the message the page is about. Half-transparent rather than a grey:
           the token feeds the heading, its collapse chevron and its toolbar alike,
           and mixing toward transparent keeps whatever colour each of those had,
           on any theme. */
        --pat-well-header-text-colour: color-mix(in srgb,
            var(--body-font-colour) 50%, transparent);
        /* And a step below a well's own heading (22px in usugami): these messages
           sit under the one being read, not level with it. */
        --pat-well-well-header-font-size: 20px;

        /* The date half of the header, exactly as it reads in the open message's
           byline: "Apple Support, 28 Aug" — the sender at full strength, the comma
           and date at half, not bold. The page head styles its own byline; a plain
           .well-header is a heading and inherits none of that, so the one span
           says it. Opacity rather than a colour token, so it recedes by the same
           amount whatever colour the heading is. Scoped to the well header: the
           same class in the page-head byline is already muted, and half of that
           again would fade it out. */
        .well-header .mail-byline-date {
            opacity: 0.5;
            font-weight: normal;
        }
    }
}