/* Article normalisation — make Industrial Precision govern legacy article HTML (issue #147).
   ══════════════════════════════════════════════════════════════════════════════════════════

   The article corpus is imported legacy markup. Measured over the 1,783 non-deleted articles:

       width= attribute        1,427   (80%)
       inline color:             155
       <font> tag                145
       inline background:         17
       inline font-size:           5
       inline font-family:         3
       nested lists            1,147   (64%)

   All of it carries its own presentation, and inline presentation beats a stylesheet — so the theme
   was losing on nearly every article. This file wins those arguments back.

   CSS only. Rewriting the stored HTML was considered and dropped: presentation is the whole of the
   problem, CSS solves all of it, and a migration over 1,783 rows of real customer content carries
   risk that buys nothing here. So the stored bodies keep their cruft and this file makes it stop
   mattering — it takes effect on every article the moment it ships, it cannot lose a single
   character of content, and any rule is reversible by deleting it.

   `!important` is used on purpose and only here. An inline `style` attribute outranks every normal
   declaration, so neutralising one is the single case where there is no alternative. Every value is
   `inherit`, `auto` or a token: this file takes presentation AWAY so the cascade can decide, it
   never adds any of its own.

   Loaded after the compiled bundle and after theme-dark.css, so it can override both, and scoped
   entirely inside `.article-body` so nothing outside an article is touched. */

/* ── Fixed widths (1,427 articles) ─────────────────────────────────────────────────────────
   The big one. Tables and cells imported with width="600" and friends cannot reflow, so an
   article overflows its column on a narrow screen and ignores the table chrome the theme draws.
   `.article-body table` is already `display:block; overflow:auto`, which only scrolls the
   overflow — it does not stop it being 600px wide in a 320px column. */

.article-body table[width],
.article-body table[style*="width"] {
    width: 100% !important;
    max-width: 100% !important;
}

.article-body td[width],
.article-body th[width],
.article-body td[style*="width"],
.article-body th[style*="width"],
.article-body colgroup,
.article-body col[width] {
    width: auto !important;
    max-width: none !important;
}

/* An image sized in markup still may not exceed its column. The bundle already sets max-width;
   height must go with it or the aspect ratio breaks once the width is capped. */
.article-body img[width],
.article-body img[height],
.article-body img[style*="width"],
.article-body img[style*="height"] {
    max-width: 100% !important;
    height: auto !important;
}

/* ── Legacy <font> (145 articles) ─────────────────────────────────────────────────────────
   Deprecated for a quarter of a century and still carrying face, size and color attributes. Made
   transparent to the cascade rather than removed, so the text inside it is untouched. */

.article-body font {
    font-family: inherit !important;
    font-size: inherit !important;
    color: inherit !important;
}

/* ── Inline colour, font and background (155 + 17 + 5 + 3 articles) ───────────────────────
   Hardcoded colours are what make an article look like it came from somewhere else, and they are
   the reason a light-mode colour turns unreadable in dark mode. The theme owns colour.

   Substring matching is deliberately broad: "color" catches background-color too, and inheriting
   both is what we want. */

.article-body [style*="color"],
.article-body [style*="font-family"],
.article-body [style*="font-size"],
.article-body [style*="background"] {
    color: inherit !important;
    background-color: transparent !important;
    font-family: inherit !important;
    font-size: inherit !important;
}

/* A link must stay a link: the rule above would otherwise inherit body ink over the link colour
   the theme sets, making anchors indistinguishable from prose. */
.article-body a[style],
.article-body a font,
.article-body a[style*="color"] {
    color: var(--surface-link, #0055a0) !important;
}

/* Table headers keep their chrome — the rule above would strip the navy fill the theme draws. */
.article-body th[style*="background"],
.article-body th[style*="color"] {
    background-color: var(--navy, #001428) !important;
    color: var(--white, #fff) !important;
}

/* ── Quill's list model (1,147 articles exposed) ───────────────────────────────────────────
   Quill 1.x has no nested-list model. It flattens nesting to `class="ql-indent-N"` on a flat
   <li>, and nothing outside the editor styled those — so a list that had been through the rich
   editor lost its indentation entirely on the published page. That is the fault reported as
   "lists are still broken like tables were", and it is the same shape: the editor's
   representation and the theme's disagreed.

   Nested lists are also blocked from the rich editor now (article-editor.js), so nothing NEW gets
   flattened. These rules are for what already has been: rendering it correctly is not the same as
   permitting the loss, and both are needed.

   Quill's own steps, so an indent looks the same inside the editor and out. */

.article-body .ql-indent-1 { padding-left: 3em; }
.article-body .ql-indent-2 { padding-left: 6em; }
.article-body .ql-indent-3 { padding-left: 9em; }
.article-body .ql-indent-4 { padding-left: 12em; }
.article-body .ql-indent-5 { padding-left: 15em; }
.article-body .ql-indent-6 { padding-left: 18em; }
.article-body .ql-indent-7 { padding-left: 21em; }
.article-body .ql-indent-8 { padding-left: 24em; }

/* Quill marks a code block this way; the bundle styles `pre` but not the class. */
.article-body pre.ql-syntax {
    background-color: var(--navy, #001428);
    color: var(--accent2, #7dd4f8);
    border-radius: 4px;
    padding: 16px;
    font-size: 13px;
    overflow: auto;
}

/* ── The construct audit (issue #147) ──────────────────────────────────────────────────────
   Every construct the issue lists, rendered inside a real .article-body and measured rather than
   guessed at. Most were already fine and are recorded here so the next person does not re-check:

       h1-h3, blockquote      themed correctly, left alone
       hr, abbr, small, kbd   themed correctly, left alone
       mark                   Bootstrap's dark amber, adequate, left alone
       caption, footnotes     muted ink, reads in both themes, left alone
       img[align]            float honoured; only the missing gutter needed fixing
       <table> cells          BROKEN in dark, fixed above
       inline <code>          BROKEN in dark, fixed below
       <dd>                   structure lost, fixed below
       <h5>                   larger than <h4>, fixed below
       <pre>                  indistinguishable from the canvas in dark, fixed below

   Sanctioned by "we can modify look & feel as long as the actual content does not change" -- these
   change how an article looks, which the earlier freeze on customer-facing screens did not permit
   and the later instruction does. Nothing here alters a single character of content. */

/* Inline code was the second-worst find after the table cells: dark navy ink on the navy canvas,
   measured 1.60:1. The bundle gives inline <code> a light-mode treatment (dark text on a pale
   chip) and dark mode repainted the chip navy without repainting the text. Dark only -- the light
   rendering is correct and familiar. */
[data-bs-theme="dark"] .article-body :not(pre) > code {
    background-color: var(--surface-code-bg, rgba(255, 255, 255, .08)) !important;
    color: var(--accent2, #7dd4f8) !important;
}

/* A code block whose background is var(--navy) sits on a canvas that IS var(--navy) in dark, so
   the block stopped looking like a block -- only the hairline border said otherwise. Lifted off
   the canvas instead. Dark only, so the light rendering is untouched. */
[data-bs-theme="dark"] .article-body pre,
[data-bs-theme="dark"] .article-body pre.ql-syntax {
    background-color: rgba(255, 255, 255, .05);
}

/* Bootstrap resets `dd { margin-left: 0 }`, which flattens a definition list into alternating
   bold and plain paragraphs -- the term/definition relationship is gone. Restoring the indent is
   restoring meaning, not decoration, so it applies in both themes. */
.article-body dd {
    margin-left: 1.5rem;
    margin-bottom: .5rem;
}

.article-body dt:not(:first-child) {
    margin-top: .75rem;
}

/* h5 rendered at 20px and h4 at 17.6px, so a sub-subheading was LARGER than its parent and the
   document outline read backwards. Only h5 is moved, to sit between the two it belongs between
   (h4 17.6px > h5 16.8px > h6 16px) -- the smallest change that fixes the ordering. */
.article-body h5 {
    font-size: 1.05rem;
}

/* align="left|right" floats correctly but leaves prose touching the image edge. */
.article-body img[align="right"] { margin: 0 0 1rem 1.25rem; }
.article-body img[align="left"]  { margin: 0 1.25rem 1rem 0; }

/* ── Structural leftovers ─────────────────────────────────────────────────────────────────
   A <div> used where a paragraph belonged gets a paragraph's spacing, so imported prose is not
   one solid block. Kept narrow: a div that contains block content is left alone. */

.article-body > div:not([class]) { margin-bottom: 1rem; }

/* Word paste leaves empty paragraphs behind as vertical filler. Two articles, but they are the
   ones that look broken. */
.article-body p:empty,
.article-body p > span:only-child:empty { display: none; }

/* ── Shared article chrome (issue #147) ────────────────────────────────────────────────────
   Docs, the Knowledge Base and Vis-U each had their own class family for the same two controls
   — .article-edit-link, .visu-suggest-link, and unstyled. One family now.

   The suggest-edit invitation gets its OWN class rather than borrowing .article-edit-link from the
   admin toolbar. That borrowing was the fault reported after #147 merged: toolbar links are actions
   an admin came to perform and are styled to be found, so a customer-facing invitation inherited a
   primary-control treatment and a full question ("Did we miss something?") in the middle of the
   page. Vis-U had it right at 0.78rem in muted grey — present, quiet, ignorable.

   Reproduced here from the old .visu-suggest-link, with the literal #94a3b8 swapped for the muted
   token so it follows the theme, which the hardcoded grey never did. */

.article-suggest-edit {
    text-align: center;
    margin: 2.5rem 0 0;
}

/* In the footer it is one item in a flex row beside "Last updated", not a centred block under the
   article, so the block spacing has to come off or it drops out of the row. */
.visu-article-footer .article-suggest-edit {
    margin: 0;
}

/* "Last updated" is the same size as the invitation and sits immediately beside it, but the bundle
   gives it a hardcoded #94a3b8 — a DIFFERENT grey, and 2.34:1 on the light canvas, which fails the
   4.5:1 floor for text this small. Two mismatched greys in one row is exactly the kind of drift this
   issue is about, and it only became visible once the two were put side by side.
   The same literal the old .visu-suggest-link used; it takes the same token. */
.visu-article-footer .visu-article-meta {
    color: var(--surface-muted, #526880);
}

/* The footer's own top border is a hardcoded #dde3ea, so in dark mode it draws a near-white hairline
   across the navy canvas. Not a readability fault — the opposite, it is far too visible — but the
   footer is now on Documentation as well as Vis-U, so it is on every article page in both themes. */
.visu-article-footer {
    border-top-color: var(--surface-rule, #dde3ea);
}

.article-suggest-link,
.visu-suggest-link { /* the Vis-U class stays styled so any remaining markup cannot diverge */
    display: inline-flex;
    align-items: center;
    font-size: .78rem;
    color: var(--surface-muted, #526880);
    text-decoration: none;
    transition: color .15s;
}

.article-suggest-link:hover,
.visu-suggest-link:hover {
    color: var(--surface-link, #0055a0);
    text-decoration: underline;
}

/* ── Link contrast in dark mode ────────────────────────────────────────────────────────────
   The bundle sets `.article-body a { color: #0077a8 }` and theme-dark.css never overrides it, so
   an article link stayed that blue on the navy canvas: measured 3.72:1, below the 4.5:1 body-text
   floor. Now 8.29:1. Found by measuring both themes on a real article, not by reading the file.

   Dark only. The light value is what every reader already knows, and #0077a8 is fine on white;
   the fault is one theme, so the fix is one theme. --surface-link resolves to --accent here,
   which is what every other link on a dark surface uses.

   Also catches the styled-link rule above, which forced --surface-link with !important: without
   this, a link with an inline style was MORE readable in dark mode than a plain one. */

[data-bs-theme="dark"] .article-body a,
[data-bs-theme="dark"] .article-body a font {
    color: var(--surface-link) !important;
}

[data-bs-theme="dark"] .article-body a:hover {
    color: var(--surface-link-hover, var(--accent2)) !important;
}

/* ── Table cells in dark mode (1,497 articles — 84% of the corpus) ─────────────────────────
   The worst defect this file fixes, and it was invisible from the source.

   Markdig's UseBootstrap extension stamps class="table" on every table it renders, which opts
   article tables into Bootstrap's variable-driven table styling. Bootstrap's own `.table` block
   sets --bs-table-bg to white. Our theme correctly supplies the dark ink through --bs-body-color,
   so a cell ended up light text ON WHITE: measured 1.09:1, which is not "hard to read", it is
   text you cannot see at all. The zebra rows were fine (10.57:1) because their background comes
   from our own --surface-zebra, which is why the fault looked like banding rather than breakage.

   admin-industrial.css already fixes this the idiomatic way, but scoped to `.admin-table.table`
   and `.admin-panel .table`. An article table is `.table` inside `.article-body` and matches
   neither, so it never got the treatment.

   Setting the variables rather than the cell background keeps Bootstrap's striping, hover and
   border machinery working -- it just gives it themed values to work with. `.article-body table`
   is (0,1,1) and the theme prefix makes it (0,2,1), so it outranks the plain `.table` (0,1,0)
   that declares the white without needing !important.

   DARK ONLY, deliberately. In light mode these cells are white today and white is correct on the
   light canvas; changing it would alter a customer-facing screen, which is out of bounds. The
   fault is one theme, so the fix is one theme -- same reasoning as the link colour above. */

[data-bs-theme="dark"] .article-body table,
[data-bs-theme="dark"] .article-body table.table {
    --bs-table-bg: transparent;
    --bs-table-color: var(--surface-ink);
    --bs-table-striped-bg: var(--surface-zebra);
    --bs-table-striped-color: var(--surface-ink);
    --bs-table-border-color: var(--surface-rule);
    --bs-table-hover-bg: var(--surface-hover);
    --bs-table-hover-color: var(--surface-ink);
}

/* A cell carrying its own bgcolor= or inline background is the other half of the same problem:
   a hardcoded light fill with themed ink over it. Neutralised in dark mode only, so the light
   rendering of a deliberately shaded cell is preserved. th keeps its navy chrome (rule above). */
[data-bs-theme="dark"] .article-body td[bgcolor],
[data-bs-theme="dark"] .article-body tr[bgcolor],
[data-bs-theme="dark"] .article-body table[bgcolor],
[data-bs-theme="dark"] .article-body td[style*="background"] {
    background-color: transparent !important;
}