/* netword-app/brands/default/skin.css
   ---------------------------------------------------------------------------
   THE DEFAULT BRAND'S SKIN. A brand's skin.css is the only file in the App
   where a colour may be written, and this is the one every hostname without a
   brand of its own wears.

   A skin is TOKENS PLUS ASSETS, nothing else. Every colour the
   chrome wears, the chrome's font and its radii, and the logo's address are
   declared here as custom properties; css/app.css references them and names no
   colour at all. A new skin is therefore this one file plus one logo file —
   zero markup changes, zero logic changes — and that claim is not a hope: it is
   enforced by test/skinScan.test.js, which reads every sheet in css/ and
   brands/ except a brand's own skin.css — the folders, so a sheet added
   tomorrow is policed on the day it is added
   — and refuses any colour literal, and any colour-bearing declaration that
   names a colour instead of reading a token, with a seeded control per class
   proving the scan can go red.

   THE VOCABULARY IS CHECKED IN BOTH DIRECTIONS, and that is worth a sentence.
   Every `--skin-*` app.css reads must be declared here, or the chrome silently
   loses a colour and nothing throws — an undeclared custom property is not an
   error in CSS, it is an empty value. And every token declared here must be read
   by app.css, so this file cannot accumulate tokens that dress nothing and
   promise a skin author control they do not have.

   THE BOUNDARY: NO SELECTOR IN THIS FILE MAY NAME
   `.reading-view`, any `.role-*` class, or any `.element-*` class — that half is
   untouched, and it is what makes the map a MAP rather than a second stylesheet
   for the reading view. This file hands the view a set of values; the platform
   sheet decides which declaration each value lands in. Both vocabularies are
   scoped to `:root` because custom properties must cascade — `--skin-*` to the
   chrome, `--reading-*` inward to the reading view — and the two prefixes are
   what keep the boundary readable at a glance and checkable by test.

   WHY EVERY TOKEN IS NAMED FOR ITS JOB AND NOT FOR ITS COLOUR
   `--skin-bar-surface`, never `--skin-warm-grey`. A skin that renamed the
   greys would have to rename them in app.css too, which is the coupling the
   whole arrangement exists to prevent. A token names the thing it dresses.

   THE DESTINY — skin administration belongs to
   the Hub — upload a logo, edit these tokens, per deployment and one day per
   tenant. Until then a skin is a static file in a brand's folder, chosen by the
   hostname the page is opened at (js/brandLoad.js), and this is the default's.
   --------------------------------------------------------------------------- */

:root {
  /* ── The logo, by reference ────────────────────────────────────────────────
     One asset address. Changing the logo is changing this line, and the markup
     carries no filename at all — pages/app.html gives the chrome bar an empty
     element and app.css fills it from here. The alternative was an <img> with a
     src in the HTML, which would have made "a new skin" mean "a markup edit".
     Served from this brand's own folder through the /brands/ prefix. On a
     page js/brandLoad.js also sets this token on the root element, with the
     App's base in front, so a bundle served under a sub-path finds the same
     file; this declaration is what a sheet read without the script sees.

     The logo's ACCESSIBLE NAME is not here, and the omission is deliberate: CSS
     cannot set one, so the name is the brand's `name` in brand.json, written
     by the shell as an `aria-label`. Inventing a `--skin-logo-alt` token would
     be a token nothing is able to read. */
  --skin-logo: url('./NetWord.png');

  /* The icon, by reference, for the same reason: the splash in pages/app.html
     shows it centred on the page while the shelf opens, and js/brandLoad.js
     sets this token from the brand's `icon` the way it sets the logo's. */
  --skin-icon: url('./favicon.ico');

  /* ── Chrome type ──────────────────────────────────────────────────────────
     SYSTEM FONTS ONLY: a web font is a download
     before first paint on a constrained network, and the audience is low-end
     Android phones. The stack names Android's Roboto by its generic first so no
     file is ever fetched. The reading identity chooses its own faces in
     reading.css and does not read this. */
  --skin-chrome-font: system-ui, -apple-system, 'Segoe UI', Roboto, sans-serif;
  --skin-chrome-size: 15px;
  --skin-chrome-size-small: 13px;
  --skin-chrome-weight: 500;
  --skin-locator-weight: 600;

  /* ── Radii ────────────────────────────────────────────────────────────────
     Chrome only. A skin that wanted square corners changes these two numbers. */
  --skin-radius: 6px;
  --skin-radius-pill: 999px;

  /* ── Density ──────────────────────────────────────────────────────────────
     THE CHROME'S SPACING, AND IT IS HERE FOR THE REASON THE RADII ARE. Density
     is a look — two skins can disagree about how tight a menu should read the
     way they disagree about how round a chip is — so it lives where looks live.
     The gutters of the READING paper are not here and must not come
     here: `--reading-pad-*` are declared on `.window__content` in app.css and
     are that home because a gutter is a fact about the
     container rather than a choice about dress.

     THE FLOOR IS A TOKEN AND NOT A CONVENTION REMEMBERED. `--skin-tap-min` is
     the least height of every control the thumb meets: the picker's chips, the
     icon buttons, the study window's lids and the popup's head and foot all read
     it, so lowering it tightens them all at once. test/densityScan.test.js holds
     the chapter grid's track floor to the same number.

     Bands: the chrome bar and the nav bar are ONE number, which is what makes
     "the search band equals the header band" a fact about the sheet instead of
     two literals that happen to agree today. `.settings-host` hangs the menu
     off the same token rather than repeating it. The value governs only while
     the tallest child plus the border fits inside it — at 32px + 1px it does,
     with 15px to spare, and the equality test is what notices if that stops
     being true. */
  --skin-band-height: 48px;
  --skin-tap-min: 32px;

  /* Panels: the picker's head, and the menu that wears the picker's dress. */
  --skin-panel-head-pad-block: 6px;

  /* The menu's own three. The breadcrumb's TOP is the one Nathan's phone walk
     named out loud, and it was the largest single number in the panel. */
  --skin-menu-path-pad-block: 6px;
  --skin-menu-row-pad-block: 4px;
  --skin-menu-body-pad-end: 8px;

  /* The picker's grid. The gap is not only whitespace: at 360px, taking it from
     6px to 4px is what fits a SEVENTH chapter column, so the tighter number
     returns more than it spends. */
  --skin-grid-pad: 8px;
  --skin-grid-gap: 4px;

  /* The study's outline steps in by this twice: its numbered points stand
     this far in from its lettered headings, and a point's opened verses this
     far in from the point. */
  --skin-study-indent: 16px;

  /* ── Surfaces ─────────────────────────────────────────────────────────────
     Three tiers, darkest at the top of the screen: the chrome bar carries the
     brand, the navigation bar sits under it, and the two reading windows are
     the page itself. */
  --skin-chrome-surface: #1f2a37;
  --skin-chrome-ink: #f4f6f8;
  /* The hairline under the chrome bar. Here it is the bar's own surface, so the
     line is drawn and not seen; a skin with a white bar gives it a grey. */
  --skin-chrome-rule: #1f2a37;

  --skin-nav-surface: #f2f4f7;
  --skin-nav-ink: #2b3440;
  --skin-nav-ink-dim: #6b7684;

  --skin-window-surface: #ffffff;
  --skin-window-ink: #1b1f24;

  /* The locator bars, which belong to their windows and read as their labels. */
  --skin-locator-surface: #e8ebf0;
  --skin-locator-ink: #3a4250;

  /* ── Lines ────────────────────────────────────────────────────────────────
     One hairline colour for every border in the chrome. Separate from the
     divider, which is furniture a finger grabs and not a line. */
  --skin-rule: #d4d9e0;

  /* ── The divider ──────────────────────────────────────────────────────────
     A control, so it gets its own three states. --skin-divider-grip is the
     short bar drawn in the middle of it: the affordance that says "drag me" on
     a touch screen with no cursor to change shape. */
  --skin-divider-surface: #dfe3e9;
  --skin-divider-grip: #98a3b3;
  --skin-divider-active: #6b7684;

  /* ── Controls: the icon buttons and the search field ──────────────────────
     ICONS ARE `currentColor` AND FOLLOW THE SKIN FOR FREE. The four SVGs
     in netword-shared/assets/icons/ declare no colour of their own, so an icon
     button's `color` is the whole of its appearance and no token here addresses
     the file. That is why a new skin needs no new icons. */
  --skin-control-ink: #f4f6f8;
  --skin-control-ink-dim: #7f8b99;
  --skin-control-hover: #2c3947;
  --skin-nav-control-ink: #3a4250;
  --skin-nav-control-hover: #e2e6ec;

  --skin-field-surface: #ffffff;
  --skin-field-ink: #2b3440;
  --skin-field-placeholder: #8b95a3;

  /* ── Focus ────────────────────────────────────────────────────────────────
     Its own token and never the brand colour: a focus ring must stay visible
     against every surface a skin might choose, and a skin author who reads only
     the surface tokens would take this one with them by accident. */
  --skin-focus: #2f6fd0;

  /* ── The credit under the verse ──────────────────────────────────────────
     The footer discharges an attribution obligation, so it has to be READABLE —
     it may not be dimmed to the point where a publisher's name is decoration.
     It also may not compete with the note above it, which is the thing the
     reader came for. Hence ink that is quieter than the window's but nowhere
     near the placeholder grey the nav uses for a disabled control, and a rule
     that is the page's own rather than a second one invented for this line.

     The credit's quiet ink is permanent and distinct from any notice surface. */
  --skin-credit-ink: #5b6472;
  --skin-credit-rule: #e4e8ee;

  /* ── The selected verse ────────────────────────────────────────────────────
     The verse the study window is showing, marked in the reading pane by
     css/app/shell.css: its text in this ink over this faint tint, and nothing
     else about it changed. They follow the brand's accent, so a reader sees
     the same family of colour on the verse, on the note's lead-in and on a
     reference. NOT the highlight tokens: a highlight is a publisher's mark on
     the text and this is the reader's finger on it, and the two may stand on
     one verse at once. */
  --skin-selected-ink: #6b4f2a;
  --skin-selected-tint: #f3ecdd;

  /* ── The study window's two voices ────────────────────────────────────────
     Commentary in the chrome's sans, scripture in the reading serif, one quiet
     section label between them; css/app/study.css draws them and reads these.
     The note's ink, the label's and the quoted verse's are the same in every
     brand; a reference follows the brand's accent, like the selected verse. */
  --skin-note-ink: #1f2933;
  --skin-label-ink: #6b7785;
  --skin-label-rule: #d9d5ca;
  --skin-reference-ink: #6b4f2a;
  --skin-quote-ink: #2a2a2a;
  --skin-quote-rule: #dde4ee;

  /* ── The lock block ────────────────────────────────────────────────────────
     Where a book's notes are behind an access code, css/app/study.css draws a
     block in the note's place: a soft surface a shade off the paper, and one
     button that is the only filled control in the study window. The code
     screen's button wears the same two tokens. */
  --skin-lock-surface: #f5f7fa;
  --skin-lock-button-surface: #101e2d;
  --skin-lock-button-ink: #ffffff;

  /* ── The demo band ─────────────────────────────────────────────────────────
     While notes stand open by the master code, css/app/chrome.css draws one
     quiet line under the chrome bar saying when they lock again: the lock
     block's soft surface, a label's ink, and a hairline under it. */
  --skin-demo-band-surface: #f5f7fa;
  --skin-demo-band-ink: #4a5a6e;
  --skin-demo-band-rule: #dde4ee;

  /* ── The book picker ───────────────────────────────────────────────────────
     The panel drops OVER the reading rather than replacing it, which is what
     makes these four tokens a set of their own instead of reuses of the nav's.
     Something drawn on top of text has to read as a LAYER, and a layer is told
     apart from the page by its own surface and its own shadow — a panel in the
     window's white with no shadow would look like the reading had been edited.

     The shadow is rgba and not a hex on purpose: it falls on whatever the skin
     put underneath it, so it must tint rather than cover. A skin author who
     swapped it for an opaque grey would get a grey bar hanging over the text on
     every skin but the one they were looking at. */
  --skin-picker-surface: #f7f8fa;
  --skin-picker-ink: #1b1f24;
  --skin-picker-shadow: rgba(27, 31, 36, 0.18);

  /* The chips. `--current` is where the reader IS, and it is the locator's own
     surface rather than a new colour: the bar and the chip are saying the same
     thing about the same book, and one colour for one meaning is the rule the
     mark token above was split out to keep. */
  --skin-picker-chip-surface: #ffffff;
  --skin-picker-chip-shade: #eef2f7;
  --skin-picker-chip-hover: #e8ebf0;
  --skin-picker-chip-current: #e8ebf0;
  --skin-picker-chip-current-rule: #98a3b3;

  /* ── The edition popup ────────────────────────────────────────────────────
     Three tokens holding the same values as the picker's three above, and they
     are SEPARATE TOKENS ON PURPOSE rather than an oversight waiting to be
     collapsed. The values agree today because both surfaces are the same kind
     of thing — a layer drawn over the reading — and a skin that made them
     disagree would look like two unrelated products. But the popup is not the
     picker: one is a destination a reader navigates inside, the other is three
     lines about the edition, and a skin author who wanted to tint one of them
     must be able to reach it without reaching the other. `--skin-picker-*` used
     on a non-picker element would be a token name that lies, which is the one
     thing the token arrangement depends on not happening.

     The shadow falls DOWNWARD here where the picker's falls up, so it is the
     same rgba tint against a different offset — see the picker's note on why it
     tints rather than covers. */
  --skin-info-surface: #f7f8fa;
  --skin-info-ink: #1b1f24;
  --skin-info-shadow: rgba(27, 31, 36, 0.18);

  /* The scrim a reference's modal stands over: the same ink as the shadows,
     thicker, so the study window stays in sight behind it and reads as set
     aside rather than gone. */
  --skin-scrim: rgba(27, 31, 36, 0.45);

  /* ═══ THE BIBLE VIEW'S STYLEMAP ════════════════════════════════════════════

     Everything below this line is the App's reading surface answering, for its
     own view, the question the platform sheet asks: given that the letter says
     THIS SPAN IS A RANK-2 HEADING, how does a rank-2 heading look here?

     THIRTY-NINE ANSWERS AND NO FALLBACKS — the map is forty-two, and the other
     three are the `--reading-pad-*` gutters, which live on `.window__content`
     in css/app.css where the media query that widens them already lives.
     `netword-shared/css/reading.css` consumes every one of these with a bare
     `var()` and declares none of them itself. That is not thrift: a custom
     property inherits, and a declaration ON an element beats a value inherited
     INTO it, so a platform default on `.reading-view` would sit between a home
     and its own map and win. Every view must be taught the whole map or draw
     undressed. `netword-shared/test/readingSpacing.test.js` asserts every home
     declares every token, making "undressed" a red suite rather than a
     reader's discovery. */
  --reading-ink: #1a1a18;
  --reading-ink-soft: #55534e;
  --reading-paper: #fdfcf9;
  --reading-rule: #e0ddd4;
  /* A highlight is the one colour on this page that must survive the dark
     scheme as a highlight rather than as a stain. */
  --reading-mark: #f6e7a8;
  --reading-accent: #6b4f2a;

  /* ── The three faces ──────────────────────────────────────────────────────
     A serif for what a publisher wrote, a sans for what the view drew around it
     — headings, verse numbers, table headings, task boxes — and a monospace for
     the one place whitespace is content. The split is the view's whole argument
     about what is text and what is apparatus, which is why it is three tokens
     and not one. */
  --reading-face: Georgia, "Iowan Old Style", "Times New Roman", serif;
  --reading-display-face: system-ui, "Segoe UI", sans-serif;
  --reading-mono-face: ui-monospace, "Cascadia Mono", Consolas, monospace;

  /* SCRIPTURE'S FACE, TAKEN HERE AT THE ROOT. A custom property's var() is
     resolved where it is declared, so this holds the serif above for every
     element below, including the study window, whose pane points
     `--reading-face` at the chrome's sans. The quotations there read this one,
     and so stay in the serif the reading pane is set in. */
  --skin-scripture-face: var(--reading-face);

  /* ── The body's scale ─────────────────────────────────────────────────────
     The MEASURE is not here and is not the view's: `max-width: 34rem` stays in
     the platform sheet, because sixty-six characters is a fact about the eye and
     not a look this surface chose. Size and leading are the view's — a phone
     held at arm's length is not a desk at a desktop width. */
  --reading-size: 1.0625rem;
  --reading-leading: 1.7;
  /* The space after a paragraph, in the paragraph's own em. */
  --reading-paragraph-gap: 1.1em;

  /* ── The heading dress, shared by every rank ──────────────────────────────
     Four tokens carried by all six ranks AND by the two headers the App itself
     draws: the book heading, the chapter header and the publisher's own headings
     share one set of values and cannot be dressed differently by accident. */
  --reading-heading-face: system-ui, "Segoe UI", sans-serif;
  --reading-heading-weight: 600;
  /* Headings in an imported document are frequently shouted in the source.
     Drawing them a touch open rather than reproducing the shouting keeps the
     page calm without editing anybody's text. */
  --reading-heading-tracking: 0.02em;
  --reading-heading-color: #6b4f2a;
  /* Tighter than the body's leading, because a heading that wraps should read as
     one thing wrapped rather than as two lines. */
  --reading-heading-leading: 1.25;

  /* ── The ranks ────────────────────────────────────────────────────────────
     RANK 1 IS THE BOOK, and this view centres it. The App synthesises a
     rank-1-shaped header for a letter that carries none (the IKJV draws no
     headings at all), a study letter that opens with its own rank-1 keeps it,
     and both take these values. */
  --reading-heading-1-size: 1.6rem;
  --reading-heading-1-align: center;
  /* RANK 2 IS THE SECTION — the DSB's "WRITER" class (source style `Header 1`,
     role `heading-2`). The chapter header the App draws reads this same token,
     so a chapter header and a section heading are one answer by construction. */
  --reading-heading-2-size: 1.3rem;
  --reading-heading-3-size: 1.1rem;
  /* Rank four stops getting smaller and starts getting quieter: a heading
     smaller than what it heads stops looking like a heading. */
  --reading-heading-4-size: 1rem;
  --reading-heading-4-color: #55534e;
  --reading-heading-4-tracking: 0.08em;
  --reading-heading-4-transform: uppercase;
  /* Ranks five and six are ranks a document can meet and can never assert — the
     role vocabulary names four and the language draws six. */
  --reading-heading-5-size: 1rem;
  --reading-heading-5-color: #55534e;
  --reading-heading-5-tracking: 0.04em;
  --reading-heading-6-style: italic;
  --reading-heading-6-weight: 500;

  /* THE SECTION HEADING between verses, the IKJV's own: centred, slanted,
     lighter and a step smaller than rank three, so it reads as a signpost in
     the text and not as a heading over it. Same face as every rank. */
  --reading-section-align: center;
  --reading-section-style: italic;
  --reading-section-weight: 400;
  --reading-section-size: 1rem;

  /* SCRIPTURE CARRIED IN THE RUN OF THE COMMENTARY, whose whole difference from
     the body is this one value. The block form beside it needs no token: it is
     drawn by indent and by a colour the map already answers, and an indent is
     not a look R35 moved. Deliberately NOT `--reading-strong-weight`: scripture
     is not emphasis, and a view that wanted its scripture lighter than its bold
     could not say so if the two shared one answer. */
  --reading-scripture-weight: 600;

  /* ── The inline roles ─────────────────────────────────────────────────────
     The class names fix WHICH property each of these lands in; they do not fix
     the value, which is why the value is here. A view that drew emphasis by
     tracking rather than by slope would still be drawing emphasis. */
  --reading-strong-weight: 700;
  /* Bold keeps the ink around it; a home that wants a lead-in in a colour of
     its own overrides this where the lead-in is. It is the lead-in's colour
     whichever mark the lead-in wears: `strong` on the books the old converter
     wrote, `sq` — drawn medium italic by the shared sheet, the one look
     everywhere — on every book born since. */
  --reading-strong-color: currentColor;
  --reading-emphasis-style: italic;
  --reading-smallcaps-variant: small-caps;

  /* ── The secondary scales ─────────────────────────────────────────────────
     `--reading-label-weight` dresses the two things that are labels rather than
     headings: a table's column heading and a definition list's term. */
  --reading-label-weight: 600;
  --reading-code-size: 0.875rem;
  --reading-code-leading: 1.5;
  --reading-code-inline-size: 0.875em;
  --reading-table-size: 0.9375rem;
  --reading-notes-size: 0.9375rem;
  /* One size for everything raised or lowered off the line — superscript,
     subscript, footnote reference, verse number — so a verse number and a
     footnote marker sitting in one line never disagree about how small small
     is. */
  --reading-super-size: 0.75em;
}

/* ── The IKJV's italics are plain, and this one rule is the whole of it ──────
   The 19,898 spans a King James edition traditionally sets in italic RENDER
   PLAIN here, with the reader's toggle a later feature. They reach the page as
   the `emphasis` role so the toggle can flip this one declaration rather than
   re-importing 66 books.

   NOT EVERY ONE OF THEM IS A SUPPLIED WORD, and this comment once said so. The
   edition also sets quoted Old Testament text in italic — ROM1:17, 1PE3:12,
   ROM7:7 and NUM26:4 each carry such a quotation — and the role does not tell
   the two apart. The rule is unchanged by that: both kinds render plain here,
   and telling them apart is the toggle's question on the day it comes.

   The span is emitted, named and counted; only the SLOPE is withheld, in the
   view, where the values live. The class fixes the property, the view supplies
   the value.

   THIS IS SAFE ONLY BECAUSE THE CORPUS SAYS SO, and the measurement is the
   reason it is written down: the IKJV source contains ZERO asterisks across all
   31,102 verses, so there is no author's emphasis in the Bible for this to
   flatten. A publication that did carry both would need `inferred` as a role of
   its own — which is a second name in the vocabulary and Nathan's to rule.

   THE QUOTED VERSE UNDER A NOTE IS SCRIPTURE TOO, and takes the same upright:
   the same renderer draws it with the same role, in the study window, where the
   DSB's own italics are real emphasis and keep their slope. The second selector
   reaches the quotation and nothing else in that window. */
.window--bible,
.study-xrefs__quote {
  --reading-emphasis-style: normal;
}

/* THE REFERENCE LAYER IS A HOME FOR THE READING VIEW, as the windows are: the
   verses a popup or a modal quotes stand in the view, so the shared sheet draws
   their marks. The layer is their paper, so the view takes its surface. */
.ref-layer {
  --reading-paper: var(--skin-info-surface);
}

/* ── The note's voice ───────────────────────────────────────────────────────
   The study window's commentary reads in the chrome's sans; its face, size,
   leading and ink are properties of the note's box and css/app/study.css sets
   them from the chrome's tokens. The three values the platform consumes on the
   note's OWN BLOCKS are overridden here, because a token is a home's to
   override and the App's sheets declare no reading dress: a tighter gap
   between paragraphs, a lead-in one step lighter than the reading's bold, and
   the lead-in's colour, which follows the brand's accent like the selected
   verse does. The colour reaches both lead-in marks, `strong` and `sq`; the
   weight reaches `strong` alone, because `sq`'s medium italic is one look on
   every surface and not a home's to change. */
/* ── In the study window only Scripture wears the serif ─────────────────────
   Everything the window draws is the edition's own words or the App's, and
   reads in the chrome's sans: a study's definition, its headings and points,
   a term's lines, the wider paragraphs, the commentary and every label. The
   view reads its face from `--reading-face`, so the pane points that token at
   the sans, and the one serif left is a quoted verse, which css/app/study.css
   sets in `--skin-scripture-face`. */
.study-pane {
  --reading-face: var(--skin-chrome-font);
}

.study-note {
  --reading-paragraph-gap: 0.625rem;
  --reading-strong-weight: 600;
  --reading-strong-color: #6b4f2a;
}

/* ── The Bible view after dark ──────────────────────────────────────────────
   The palette values and nothing else: the faces, the scale and the ranks are
   the same page in either light, which is what makes this a scheme rather than
   a second skin. The selected verse's two tokens are here with them, because
   the verse is on the reading surface and takes the reading's dark.

   The App's CHROME has no dark scheme. Giving the chrome a scheme is a skin
   decision somebody makes on purpose. */
@media (prefers-color-scheme: dark) {
  :root {
    --reading-ink: #e8e4dc;
    --reading-ink-soft: #a09a8e;
    --reading-paper: #171614;
    --reading-rule: #35322c;
    --reading-accent: #c9a227;
    --reading-mark: #5a4a12;

    /* The two tokens that hold a palette value rather than a reference. CSS
       custom properties substitute at use, so `--reading-heading-color:
       var(--reading-accent)` would have worked and is deliberately not used:
       a token whose value is another token reads as an alias, and an alias is
       one more thing to keep true. A literal in both schemes is two lines a
       skin author can see and change. */
    --reading-heading-color: #c9a227;
    --reading-heading-4-color: #a09a8e;
    --reading-heading-5-color: #a09a8e;

    /* The selected verse after dark: the same family as the dark accent, the
       tint a shade above the dark paper. */
    --skin-selected-ink: #c9a227;
    --skin-selected-tint: #2f2a18;

    /* The two voices after dark. */
    --skin-note-ink: #d6dde5;
    --skin-label-ink: #8a96a3;
    --skin-label-rule: #2f3640;
    --skin-reference-ink: #c9a227;
    --skin-quote-ink: #d0d0d0;
    --skin-quote-rule: #2a3a50;

    /* The lock block after dark: a shade above the dark paper, and the button
       turned over so it is still the one filled control. */
    --skin-lock-surface: #23211e;
    --skin-lock-button-surface: #dfe6ef;
    --skin-lock-button-ink: #101e2d;

    /* The demo band after dark: the lock block's dark surface, still quiet. */
    --skin-demo-band-surface: #23211e;
    --skin-demo-band-ink: #8a96a3;
    --skin-demo-band-rule: #2f3640;
  }

  .study-note {
    --reading-strong-color: #c9a227;
  }
}