/*
 * What Unfold's compiled stylesheet cannot express.
 *
 * Design review §4.1: *inside the admin, Unfold's vocabulary exclusively.* This
 * file is not an exception to that — it is what §4.1's own text recommends.
 * Unfold's documentation, for the version we run: "we strongly recommend
 * writing your own custom CSS styles directly rather than attempting to set up
 * and configure Tailwind in your project". The project-level build this
 * replaces is what produced the @source invisible-class failure five times
 * across two projects.
 *
 * Twelve rules across five named classes — pinned BY VALUE in
 * `core/tests/test_admin_stylesheet.py::OURS` — plus two more keyed on
 * Django's own generated `field-` class rather than a name of ours (fourteen
 * declaration blocks in total). Re-settled 2026-09-11 after two browser-pass
 * fixes added four of them; this list is not a number to keep in sync by hand,
 * it is what `OURS` already asserts:
 *
 *   - `.fieldset-tabs` — six: font-size, resting colour (light and dark),
 *     active weight, hover/active colour (light and dark)
 *   - `.callout` — two: border (light and dark)
 *   - `.link:hover` — one
 *   - `.row-baseline` — one
 *   - `.print-full` — two: the base `max-width` and its print override
 *   - the changelist identity cell — two, `strong` and `p` under
 *     `#result_list th[class*="field-"]`, which names no class of ours or
 *     Unfold's and so sits outside `OURS`
 *
 * `docs/2026-09-11-admin-phase-4-design.md` §2.3 says why each named class
 * cannot be an Unfold class: Unfold ships `text-base-500` but never the `*:`
 * child variant of it, `border-l-2` but not `border-l-4`, no `border-l-primary-*`
 * at any weight, and no print variant of anything.
 *
 * ## The rule that governs every rule here
 *
 * THIS FILE LOADS FIRST. `unfold/layouts/skeleton.html` emits UNFOLD["STYLES"]
 * at line 26 and its own stylesheet at line 33, so on equal specificity Unfold
 * wins. Therefore: **own whole properties, and never put an Unfold utility
 * touching the same property on the same element.** Not "add specificity" — a
 * selector that wins by being `.a.b` loses to `.a.b.c` the day Unfold writes
 * one; a property no Unfold rule addresses cannot be beaten at all.
 *
 * The one case this "never" does not cover is below, in `.fieldset-tabs >
 * a:hover` / `.active`: Unfold styles the same property on the same states of
 * the same element and cannot be made to stop. The second-best answer, used
 * there and nowhere else, is to duplicate Unfold's own value rather than
 * invent one — so whichever rule wins paints the identical pixel. That only
 * works because the value is copied from Unfold's compiled stylesheet, not
 * chosen; it is not a general escape from the rule above.
 *
 * That is not a new rule. `crm/templates/crm/follow_up_queue.html` reached it by
 * measurement: the accent border compiled correctly and still rendered 1px in
 * base-700, because Unfold's `border-base-700` loaded later. The fix then was
 * arbitrary-value utilities our build compiled; the compiler is gone and the
 * reasoning is not.
 *
 * `core/tests/test_admin_stylesheet.py` pins the class list BY VALUE and fails
 * if any name here also exists in Unfold's stylesheet.
 */

/* The INNER fieldset tab strip -- `templates/unfold/helpers/fieldsets_tabs.html`.
 * 13px against the outer strip's 14px, and normal weight until active, so the
 * nesting reads as nesting. Phase 3 measured both strips at 14px/500 and found
 * them indistinguishable, which is what made the form read as "two screens
 * merged into one page".
 *
 * base-400 in dark is a CONTRAST measurement, not a preference. Against the
 * dark ground: base-300 12.05, base-400 6.82, base-500 3.67, base-600 2.35.
 * WCAG AA wants 4.5 for 13px text, so base-500 fails and base-400 is the one
 * that stays muted and still passes. Do not "simplify" these two into one. */
.fieldset-tabs            { font-size: 13px; }
.fieldset-tabs > a        { font-weight: 400; color: var(--color-base-500); }
.dark .fieldset-tabs > a  { color: var(--color-base-400); }
.fieldset-tabs > a.active { font-weight: 500; }

/* We took `color` on the selector above, so we must own it in EVERY state --
 * see the file header. Unfold styles `:hover` and `.active` on this same
 * element (`*:hover:text-primary-600`, `[&>.active]:text-primary-600`, and
 * their dark twins) and its dark-state selector compiles through `:where()`,
 * which contributes zero specificity -- so `.dark .fieldset-tabs > a` above
 * (0,2,1) was beating Unfold's dark hover/active rule (0,2,0) and leaving the
 * resting grey in place where Unfold intended blue. Measured in a real
 * browser: active tab computed `oklch(0.707 0.022 261.325)` (base-400, grey)
 * with this file loaded, `oklch(0.62 0.17 255)` (primary-500) with it
 * disabled. These four declarations are that same primary colour, made ours
 * to lose. */
.fieldset-tabs > a:hover,
.fieldset-tabs > a.active        { color: var(--color-primary-600); }
.dark .fieldset-tabs > a:hover,
.dark .fieldset-tabs > a.active  { color: var(--color-primary-500); }

/* The follow-up queue's accent card. Every border property is declared here, so
 * the element carries no Unfold border utility at all -- see the rule above. */
.callout       { border: 1px solid var(--color-base-200);
                 border-left: 4px solid var(--color-primary-600); }
.dark .callout { border-color: var(--color-base-700);
                 border-left-color: var(--color-primary-500); }

/* The "Copy link" button inside a success message (assets/js/copy-link.js). It takes the banner's
 * own colour, so it reads in light and dark without a token of its own. */
.copy-link { margin-left: 8px; padding: 2px 12px; border: 1px solid currentColor;
             border-radius: 6px; background: transparent; color: inherit;
             font-weight: 600; cursor: pointer; }
.copy-link:hover { text-decoration: underline; }
code[data-copy-fallback]:not([hidden]) { display: block; margin-top: 8px; word-break: break-all; }

/* Unfold ships `underline`, never `hover:underline`. */
.link:hover { text-decoration: underline; }

/* Unfold ships `items-center` and `items-start` only. Baseline alignment is a
 * real typographic choice where a heading sits beside a smaller count. */
.row-baseline { align-items: baseline; }

/* Unfold ships NO print variant of anything, and Unfold ships `.max-w-4xl`
 * itself -- so `<div class="max-w-4xl print-full">` and Unfold's own rule were
 * both (0,1,0), a media query adds no specificity, and Unfold's sheet loads
 * second: at print time `max-width` stayed 56rem and this rule did nothing.
 * Not a regression -- the `print:max-w-none` this replaced lost the same way
 * -- but it is the file's own non-competition rule broken by the file that
 * states it. Fixed by owning the WHOLE property, on screen and in print, so
 * nothing Unfold ships addresses `max-width` on this element at all; the
 * template drops `max-w-4xl` to match. */
.print-full            { max-width: var(--container-4xl); }
@media print {
    .print-full { max-width: none; }
}

/* The changelist identity cell below Unfold's `lg` breakpoint (1024px).
 * `unfold/helpers/display_header.html` renders the title in a `<strong>` and
 * the subtitle in a `<p>`, both inside a `<th class="field-<method name>">` --
 * a hook Django generates from the `@display` method name, not an Unfold
 * utility, so it is stable across an Unfold upgrade the way a class from its
 * compiled stylesheet would not be.
 *
 * Two defects, measured live at 390px on `/admin/documents/documentpackage/`:
 *
 * 1. `display_header.html:19` hardcodes `text-right lg:text-left` on the
 *    title/subtitle wrapper, so every identity cell -- the row's ONLY link --
 *    renders right-aligned below 1024px. Broken-looking beside two
 *    left-aligned columns, and Unfold's own choice: nothing here is wrong to
 *    override.
 * 2. The subtitle wraps unbounded. On that page the identity column was the
 *    NARROWEST of three (120px against 136px and 94px) and its subtitle wrapped
 *    to six lines, 120px tall alone; rows averaged 145px and the 51-row page
 *    was 7,830px.
 *
 * Unfold ships `.truncate` and `.text-ellipsis` -- single-line only -- and no
 * line-clamp utility at any line count, so a multi-line clamp cannot be
 * reached by adding an Unfold class; the only alternative was forking
 * `display_header.html`, which `core/tests/test_fieldset_tabs_fork.py`'s own
 * reasoning says to avoid wherever a CSS rule can do the job instead.
 *
 * The selector below names NO class of ours or Unfold's -- `#result_list` is
 * Django's id, `field-` is Django's generated prefix (matched with `*=` since
 * the full class names by method name), `strong`/`p` are bare elements. An
 * earlier draft selected `span.flex.flex-col`, which names two of Unfold's
 * own utility classes and would have made `classes_named_in()` add them to
 * the parsed set -- `test_no_class_we_own_also_exists_in_unfolds_stylesheet`
 * would then correctly fail. Keying on Django's class instead means `OURS`
 * needs no new entry and that test needs no exception.
 *
 * `63.9375rem` is 1px below Unfold's `lg` (64rem), so this rule surrenders the
 * property exactly where `lg:text-left` takes over -- the same non-competition
 * rule as the rest of this file, applied to a breakpoint instead of a state.
 *
 * Measured effect at 390px: first row 153px -> 73px, average row 145px ->
 * 80px, page height 7,830px -> 4,580px (42% shorter), subtitle left-aligned. */
@media (max-width: 63.9375rem) {
    /* No `display` here: `display_header.html` already writes
     * `<strong class="block ...">`, Unfold's own `.block` utility, on this
     * exact element. Declaring the same value again here is dead weight --
     * same value either way, so nothing renders differently. */
    #result_list th[class*="field-"] strong { text-align: left; }
    #result_list th[class*="field-"] p {
        text-align: left;
        display: -webkit-box;
        -webkit-line-clamp: 2;
        line-clamp: 2;
        -webkit-box-orient: vertical;
        overflow: hidden;
    }
}