/* ── Reading mode ──────────────────────────────────────────────
   Used by About, Articles, Projects, Offerings, and future Courses.
   Optimised for reading: a comfortable ~70–75 character measure
   and a looser line-height than the default body copy. Apply
   `.reading` to whatever wraps the long-form content; the pattern
   composes with `.detail` on a single-entity detail page or wraps
   a whole page's worth of sections (e.g. the About page).

   Studio mode is the other typography context - see studio.css.
   Both share the same font family; only sizing and spacing differ.
*/
.reading {
    max-width: 72ch;
}

.reading, .body {
    line-height: var(--type-reading-line-height);
}

/* ── Detail page chrome (project / article / offering) ────────── */

/* Two-column layout for a detail page with a table of contents
   (components/toc.css) - sidebar + content, content keeps its own
   `.reading` measure regardless of the sidebar's width. Below the
   `.toc` component's own desktop breakpoint, this collapses to a
   single column (the `.toc` becomes its collapsible mobile form). */
.detail-layout {
    display: grid;
    gap: var(--space-8);
}

/* Grid items default to min-width: auto (their content's intrinsic
   width) - so a non-wrapping child (a fenced code block's long line)
   stretches the whole grid track past the viewport instead of
   triggering that child's own overflow-x: auto (components/code.css).
   min-width: 0 lets the track respect the container's actual width. */
.detail-layout > * {
    min-width: 0;
}

@media (min-width: 641px) {
    .detail-layout {
        grid-template-columns: 220px minmax(0, 1fr);
        align-items: start;
    }
}

/* ── Page header ───────────────────────────────────────────────
   The shared "title (+ intro/subtitle), then breathing room, then
   the first content block" boundary - every public page that opens
   with a title and optional lede wraps that block in this, right
   down to the page's own `.section`/`.container-content` (a list
   page's `<h1>` + one intro `<p>`, or a single-entity detail page's
   `<h1>` + `.subtitle`/`.summary`). One rule, one value, instead of
   a page-specific margin wherever this pattern recurs. */
.page-header {
    margin-bottom: var(--space-6);
}

.subtitle {
    color: var(--color-text-muted);
    font-size: var(--type-heading-m-size);
    margin-bottom: var(--space-3);
}

/* ── Page introduction - a page's own contextual copy (apps.pages'
   PageContent: Projects today, Articles/About/Work With Me and future
   pages as they adopt the same capability) ────────────────────────
   Supporting prose, not a second headline: sized down from body copy
   and muted so it reads as context the h1 introduces rather than
   content competing with it or with the cards/list below. Sits inside
   `.page-header` as the last element after the `<h1>` - its own
   margin-top keeps it close to the heading it belongs to, and its
   margin-bottom collapses with `.page-header`'s to open up generous
   room before the page's actual content starts. Deliberately no
   border/background/padding - it stays plain running text on the
   page's own white canvas, never a boxed/card-like component. Reuses
   `.markdown-content`'s vertical rhythm for its own paragraphs (apply
   both classes together), so multi-paragraph intros still space
   themselves out consistently with every other rendered-Markdown
   field in the system. */
.page-intro {
    max-width: 72ch;
    margin-top: var(--space-3);
    margin-bottom: var(--space-8);
    font-size: var(--type-small-size);
    line-height: var(--type-small-line-height);
    color: var(--color-text-muted);
}

.detail-meta {
    display: flex;
    gap: var(--space-4);
    flex-wrap: wrap;
    margin-top: var(--space-2);
    align-items: center;
}

/* Interactive blue, not brand orange (Issue 45 revision) - .summary is
   shared reading-mode chrome (Project/Article/Offering detail headers
   alike), so its accent bar stays a neutral structural marker rather
   than implying one content family's identity. */
.summary {
    font-size: var(--type-heading-m-size);
    color: var(--color-text-muted);
    margin-bottom: var(--space-6);
    border-left: 3px solid var(--color-interactive);
    padding-left: var(--space-4);
}

/* ── Offering hero - narrative + a scannable practical-facts panel ──
   Deliberately its own component, not a reuse of `.hero` (page.css) -
   that one's h1 is set to the Display scale, reserved for the home
   page's single largest mark. An Offering's h1 stays at the ordinary
   heading-xl size every other detail page uses; only the layout (an
   asymmetric two-column grid pairing narrative with a structured facts
   list) is the same idea, proven first on the home page hero. */
.offering-hero {
    display: grid;
    gap: var(--space-6);
    margin-bottom: var(--space-8);
}

.offering-hero > * {
    min-width: 0;
}

@media (min-width: 641px) {
    .offering-hero {
        grid-template-columns: 3fr 2fr;
        align-items: start;
    }
}

.offering-hero-facts {
    display: flex;
    flex-direction: column;
    background: var(--color-background);
    border: 1px solid var(--color-border);
    border-radius: var(--radius-md);
    padding: var(--space-2) var(--space-5);
}

.offering-hero-fact {
    display: flex;
    justify-content: space-between;
    align-items: baseline;
    gap: var(--space-3);
    padding: var(--space-3) 0;
}

.offering-hero-fact + .offering-hero-fact {
    border-top: 1px solid var(--color-border);
}

.offering-hero-fact-label {
    font-size: var(--type-small-size);
    font-weight: var(--type-label-weight);
    color: var(--color-text-muted);
    text-transform: uppercase;
    letter-spacing: 0.04em;
}

.offering-hero-fact-value {
    font-size: var(--type-small-size);
    color: var(--color-heading);
    text-align: right;
}

/* ── Detail page composition (Issue 31) ─────────────────────────
   One stable two-column content area below the hero, reusing the
   hero's own 3fr:2fr ratio so the page holds a single rhythm rather
   than switching grids per section: a main narrative column (plain
   stacked `.section`s) beside a supporting decision-support rail
   (Programme Facts, Availability). Each child of `.detail-columns`
   just stacks its own sections via normal block flow - no further
   grid/flex needed inside either column. */
.detail-columns {
    display: grid;
    gap: var(--space-8);
    margin-bottom: var(--space-8);
}

.detail-columns > * {
    min-width: 0;
}

@media (min-width: 641px) {
    .detail-columns {
        grid-template-columns: 3fr 2fr;
        align-items: start;
    }
}

/* The two-column content area sits inside `.detail-columns` (below),
   so its own column track already governs its width - no standalone
   "wider than .reading" tier is needed here. */
.detail-columns .section {
    margin-bottom: var(--space-6);
}

/* Label/value facts panel - the same visual pattern as the hero's
   own facts panel (`.offering-hero-fact*`), reused under a generic
   name for the Programme Facts section so a plain comma-separated
   list of facts becomes a structured, scannable panel instead. */
.offering-hero-facts,
.fact-list {
    display: flex;
    flex-direction: column;
    background: var(--color-background);
    border: 1px solid var(--color-border);
    border-radius: var(--radius-md);
    padding: var(--space-2) var(--space-5);
}

.offering-hero-fact,
.fact-row {
    display: flex;
    justify-content: space-between;
    align-items: baseline;
    gap: var(--space-3);
    padding: var(--space-3) 0;
}

.offering-hero-fact + .offering-hero-fact,
.fact-row + .fact-row {
    border-top: 1px solid var(--color-border);
}

.offering-hero-fact-label,
.fact-label {
    font-size: var(--type-small-size);
    font-weight: var(--type-label-weight);
    color: var(--color-text-muted);
    text-transform: uppercase;
    letter-spacing: 0.04em;
}

.offering-hero-fact-value,
.fact-value {
    font-size: var(--type-body-size);
    color: var(--color-heading);
    text-align: right;
}

/* The apply section sits outside `<article>` (it's not part of the
   reading flow, it's the call to action), so it never inherited
   `.reading`'s width - it defaulted to the full container instead,
   jumping from a ~72ch narrative column to an ~1120px form. Give it
   the same baseline measure as `.reading` by default; a template
   that composes a wider page (Mentorship) can opt into matching its
   own wider rhythm via `.apply-wide`. */
#apply {
    max-width: 72ch;
    margin-bottom: var(--space-6);
}

/* On Mentorship, the apply section is the final full-width action
   area below the two-column content, not a narrower reading column -
   it should span the same width as the hero and `.detail-columns`
   above it, not introduce its own odd-width tier. */
.apply-wide #apply {
    max-width: none;
}

/* `.cta-block` (Issue 31) has no opinion on textarea height - fine for
   a single-field form, but three stacked long-text fields (current
   background, goals, message) is real cumulative weight even before
   any content is typed. Scoped to `#apply` only: Contact and General
   Request each carry a single textarea and are unaffected. */
#apply textarea {
    min-height: 4.5rem;
}

.body p + p {
    margin-top: var(--space-4);
}

/* ── Rendered Markdown vertical rhythm ────────────────────────────
   Every long-form field renders through apps.core.markdown into a
   `.markdown-content` wrapper - About sections, Project/Article/
   Offering bodies, Philosophy/Brand Strategy, and the Studio's own
   live preview (.content-editor-preview-body carries this class too,
   so authors see the same spacing they'll get publicly). One shared
   rule set here fixes vertical rhythm everywhere; no template should
   ever add its own paragraph/heading spacing on top of this.

   The output of render_markdown is a flat sequence of sibling block
   elements (p, h1–h6, ul/ol, blockquote, the code-block/table-responsive
   wrapper divs, img) - direct-child selectors are enough to reach all
   of them without knowing which one comes next. */
.markdown-content > :first-child {
    margin-top: 0;
}

.markdown-content > * + * {
    margin-top: var(--space-4);
}

/* Anchored headings (table-of-contents / direct fragment links) must
   clear the sticky site header, not just the bare viewport top.
   --header-height is kept in sync with the header's real rendered
   height by back-to-top.js; --space-6 is the no-JS fallback. */
.markdown-content :is(h1, h2, h3, h4, h5, h6) {
    scroll-margin-top: calc(var(--header-height, var(--space-6)) + var(--space-4));
}

/* Content immediately under its own heading sits a little closer to
   it than the general rhythm, so the heading still reads as "in
   charge of" what follows. */
.markdown-content > :is(h1, h2, h3, h4, h5, h6) + * {
    margin-top: var(--space-3);
}

/* A heading must never look attached to the end of the paragraph
   before it - give it more room than the general rhythm, not less. */
.markdown-content > * + :is(h1, h2, h3, h4, h5, h6) {
    margin-top: var(--space-8);
}

.markdown-content ul,
.markdown-content ol {
    padding-left: var(--space-5);
}

.markdown-content li + li {
    margin-top: var(--space-2);
}

.markdown-content blockquote {
    padding-left: var(--space-4);
    border-left: 3px solid var(--color-border);
    color: var(--color-text-muted);
}

.markdown-content img {
    border-radius: var(--radius-md);
}

.project-links {
    display: flex;
    gap: var(--space-3);
    margin-top: var(--space-6);
    flex-wrap: wrap;
}

/* ── Comments ──────────────────────────────────────────────── */
.comments-section {
    border-top: 1px solid var(--color-border);
    padding-top: var(--space-6);
    margin-top: var(--space-8);
}

.comment {
    padding: var(--space-4) 0;
    border-bottom: 1px solid var(--color-border);
}

.comment strong {
    margin-right: var(--space-2);
}