/* OVERNIGHT BATCH, SECTION B -- the public visual polish.
   app/nightpolish.py gates it; `night_polish` is OFF by default and this file
   is not even requested while it is. Loaded AFTER every other sheet, so a rule
   here beats the one it corrects on order alone and needs no `!important`
   except where it is fighting an inline style or a theme rule of equal weight
   -- and where that happens the rule says so.

   SECTIONED BY ITEM NUMBER. Every section says what was measured. */

/* ===================================================================== *
 * ITEM 6 -- the share bar and the diet badges at 54% ground.
 *
 * MEASURED, in static/site/recipe-v3.css:
 *     .share        { background:#fff }            line 446
 *     .h-diets span { background:#fff }            line 445
 * Both sit ON the hero photograph -- `.share` is absolutely positioned into
 * the hero's top-right corner and the diet pills over its lower edge -- so a
 * solid white ground is two opaque shapes punched out of Tom's picture.
 *
 * OPACITY OF THE GROUND, NOT OF THE ELEMENT. `opacity:.54` on the box would
 * have taken the TEXT and the share icons down with it; the item says the
 * design is unchanged and only the opacity moves, and illegible labels are a
 * design change. So it is the background colour that gains an alpha and
 * nothing else: same size, same radius, same padding, same type, same colour.
 *
 * NOT `.nut-diets span`. That is the SAME diet pill drawn again inside the
 * nutrition panel (recipe-v3.css line 620), and it sits on the panel's cream
 * ground rather than on a photograph. At 54% it would show cream through
 * white and read as a dirty pill -- a design change, which this item forbids.
 * Written down because "diet-tag badge bgs" could mean either, and this is
 * the half where translucency is the point.
 * ===================================================================== */
.share{ background:rgba(255,255,255,.54) }
.h-diets span{ background:rgba(255,255,255,.54) }

/* ===================================================================== *
 * ITEM 7 -- the Comments/Share bar, lifted ABOVE the column's intro
 * banner and coloured to match it.
 *
 * THE FAULT, MEASURED on /a-guide-to-soy-sauce-light-dark-and-more/ with the
 * banner scrolled level with the bar. The bar is `position:fixed; z-index:60`
 * and the theme's intro banner is `position:relative; z-index:200` -- so the
 * banner wins, and `document.elementFromPoint()` at the BAR'S OWN CENTRE
 * returns the banner's children rather than the bar:
 *
 *     width   bar x..x+w     banner x..x+w    overlap   on top at the bar
 *      1440    0..79          78..1034           0 px   BUTTON        (ok)
 *      1280    0..79          30..923           49 px   DIV.content   (under)
 *      1100   1020..1099      20..1080          59 px   DIV.img       (under)
 *      1024    944..1023      20..1004          59 px   DIV.img       (under)
 *       900    858..900       20..880           22 px   DIV.img       (under)
 *       768    726..768       20..748           22 px   DIV.content   (under)
 *       600    550..599       20..580           29 px   DIV.img       (under)
 *       390    340..389       20..370           29 px   DIV.content   (under)
 *
 * So at EVERY width but 1440 the buttons are not merely behind the banner,
 * they are not clickable where it covers them. 300 clears the banner's 200
 * with room for the theme to add something at 250; the popup keeps its
 * one-above-the-bar relationship.
 *
 * THE COLOUR. "match that column's intro-banner colour" -- the banner is
 * `.bgcolor-article`, #ac9fee, which the THEME defines
 * (wp-content/.../acf-blocks/intro.min.css). All 7 published columns use that
 * one class; the `:has()` scoping means the bar is only recoloured on a page
 * that really carries an article banner, and a column given a different
 * `.bgcolor-` class later is one line here. A browser without `:has()` keeps
 * the maroon bar and still gets the z-index fix, which is the half that
 * matters.
 *
 * AND THE LABELS GO DARK, which is the one place this does not copy the
 * banner. MEASURED: the bar's own #fffeec on #ac9fee is 2.35:1 and FAILS AA.
 * #1d2327 on #ac9fee is 6.77:1 and passes. The item asks for the bar's COLOUR
 * to match the banner, and it does, exactly; making its labels unreadable is
 * not part of that.
 *
 * FOR TOM, NOT CHANGED HERE: the banner's OWN heading and link are #ffffff on
 * #ac9fee -- the same 2.35:1 -- and that is live today on all seven columns.
 * It is his design and not one of the 41 items, so it is reported, not fixed.
 * ===================================================================== */
.ttc-fbar{ z-index:300 }
.ttc-fbar-pop{ z-index:301 }

body:has(section.gt-block.intro.bgcolor-article) .ttc-fbar{
  background:#ac9fee;
  box-shadow:0 3px 16px rgba(78,66,140,.38);
}
body:has(section.gt-block.intro.bgcolor-article) .ttc-fbar button{ color:#1d2327 }
body:has(section.gt-block.intro.bgcolor-article) .ttc-fbar .lab{ color:#1d2327 }
body:has(section.gt-block.intro.bgcolor-article) .ttc-fbar svg{ stroke:#1d2327 }
body:has(section.gt-block.intro.bgcolor-article) .ttc-fbar button + button{
  border-top-color:rgba(29,35,39,.22);
}
/* The hover had to move with the ground: #6a0b19 is a lighter maroon on a
   maroon bar, and on lavender it is a dark blot. This is #ac9fee stepped the
   same direction the maroon hover steps -- lighter, by the same ~8% -- so the
   gesture reads the same on both. */
body:has(section.gt-block.intro.bgcolor-article) .ttc-fbar button:hover{
  background:#bdb2f1;
}
body:has(section.gt-block.intro.bgcolor-article) .ttc-fbar button:focus-visible{
  outline-color:#1d2327;
}

/* ===================================================================== *
 * ITEM 25 -- the ingredient lines, normalised to the tight style.
 *
 * THE CAUSE, MEASURED, AND IT IS NOT WHAT IT LOOKS LIKE. The ingredient
 * LINES are already identical on both recipes Tom named. Every `.li` on
 * /recipes/easy-salsa/ and on /recipes/zemlovka-apple-bread-pudding/ has
 * margin 0, padding 0, line-height 28px, and the measured gap between two
 * consecutive lines is ZERO on both:
 *
 *     Salsa      gaps  0 0 0 0 0 0 0 0 22 0
 *     Zemlovka   gaps  0 22 0 0 0 0 0 22 0 22 0 0 0 0 0 22
 *
 * Every 22 is `.ing-cols .li.sec { margin-top:22px }` (recipe-v3.css:940) --
 * the space above an ingredient SECTION HEADING. Salsa has ONE titled
 * section, Zemlovka has EIGHT. So the "big gaps between ingredient lines" are
 * seven section breaks, and the two recipes differ in how many headings they
 * have rather than in how their lines are spaced.
 *
 * COUNTED ACROSS THE SITE: of 172 published recipes, 48 have no titled
 * section, 9 have one, and **115 have more than one** -- so 115 recipes show
 * at least one of these gaps and 57 cannot.
 *
 * 22px -> 10px, AND NOT TO ZERO. Zero runs a bold heading flush against the
 * last line of the section above it, which is a different fault and a worse
 * one. 10px keeps the break visible -- the heading is already bolder and
 * larger than a line (`--ingsec-size`, `--ingsec-weight`) -- while the column
 * reads as one tight list, which is what Salsa looks like and what the item
 * asked for. `:first-child` stays 0, as it already was.
 * ===================================================================== */
.ing-cols .li.sec{ margin-top:10px }
.ing-cols .li.sec:first-child{ margin-top:0 }

/* ===================================================================== *
 * ITEM 36 -- each mention in the site's standard box.
 *
 * THE STANDARD BOX, MEASURED rather than designed: on /press-info/ and
 * /partners/ the theme's own content box is
 *     section.gt-block.text  { background:rgb(248,248,248); border-radius:30.72px }
 * with its inner `.content` supplying a 38.4px side inset. Those three numbers
 * are what is used below -- #f8f8f8, 30.72px and 38.4px -- so a mention card
 * sits on exactly the ground, corner and inset every other box on the site
 * does, and reads as a card against the page's white.
 *
 * NOTHING ABOUT THE CONTENT CHANGES. The headline, the outlet - date line,
 * the extract and the "Read it at X" button are the markup
 * app/mentions.render_list already writes; this is appearance only, so a
 * mention Tom approves tomorrow is in a box without anybody touching Python.
 *
 * WHY THE WRAPPER LOSES ITS GROUND. The list sits inside
 * `section.gt-block.text.without-box`, which is transparent -- so the cards
 * are drawn on the page itself and the gap between them is page, not a
 * second grey on grey.
 * ===================================================================== */
.ttc-mentions{ display:flex; flex-direction:column; gap:24px }
.ttc-mentions article.mention{
  background:#f8f8f8;
  border-radius:30.72px;
  padding:32px 38.4px 34px;
  margin:0;
}
.ttc-mentions article.mention > h3{ margin:0 0 6px }
.ttc-mentions article.mention > h3 a{ text-decoration:none }
.ttc-mentions article.mention > h3 a:hover,
.ttc-mentions article.mention > h3 a:focus-visible{ text-decoration:underline }
/* The outlet and the date are the card's quiet line: the same --body grey the
   rest of the site gives secondary text, one step down in size. */
.ttc-mentions .mention__meta{
  margin:0 0 14px;
  font-size:14px;
  line-height:22px;
  color:#4e5155;
}
.ttc-mentions article.mention > p{ margin:0 0 18px }
.ttc-mentions .mention__more{ margin:0 }
@media (max-width:600px){
  .ttc-mentions{ gap:18px }
  .ttc-mentions article.mention{ padding:24px 22px 26px; border-radius:22px }
}

/* ===================================================================== *
 * ITEM 32 -- the "Note:" body text, normalised. Headlines NOT touched.
 *
 * THE FAULT, AND IT TOOK TWO GOES TO SEE IT. On Zemlovka the custard note is
 * stored as
 *     <p><strong>Note: </strong></p><ul><li>Custard will not be cooked.</li>
 *                                        <li>The sliced burger buns...</li></ul>
 * so the note's BODY is an <li>, in a <ul> no rule on this site matches. It
 * falls back to the browser's default and renders at **13.824px with
 * line-height `normal`**. The meringue note is
 *     <p><strong>Note:</strong> Start the meringue layer when ...</p>
 * which `.ttc-v2 .card.step .sbody > p` catches at 17px / 26px. That is
 * exactly Tom's "small on custard, normal on meringue", and the two notes are
 * four inches apart on one page.
 *
 * AUDITED ACROSS ALL 172 PUBLISHED RECIPES (tools/night_note_audit.py): 281
 * note runs, of which **10 in the directions are 13.824px** and 264 are 17px.
 * The 10 are on five recipes -- bobalky-with-poppyseeds-and-honey,
 * bobalky-with-sauerkraut, brie-grilled-cheese,
 * little-buns-with-vanilla-pudding-buchticky and zemlovka -- and every one of
 * them is an <li> under a Note label.
 *   (The first version of that audit reported "0 of 144 differ", because it
 *   only matched runs BEGINNING with the word "Note" and the <li> bodies do
 *   not contain the word at all. It follows a label to its body now.)
 *
 * THE FIX IS THE RULE THAT WAS MISSING, not a new size: the same
 * `--step-size` / `--step-line` / `--step-weight` / `--step-color` that
 * `.sbody > p` and `.slist > div` already take, extended to the list a step
 * body can also contain. Nothing that is 17px today moves.
 *
 * THE REMAINING 7 AT 14px ARE `.ing-notes` -- the asterisk footnotes under the
 * INGREDIENTS -- and they are LEFT ALONE. They are not in the directions,
 * which is what this item names, and a footnote set smaller than the body is
 * a deliberate typographic choice rather than a fault.
 *
 * AND NO HEADLINE MOVES. Every selector below ends at a `li` or at a `ul`/`ol`
 * inside a step body; an h2/h3/h4 cannot match any of them. The item is
 * explicit that the box and section headlines are intentionally bigger.
 * ===================================================================== */
.ttc-v2 .card.step .sbody ul,
.ttc-v2 .card.step .sbody ol,
.ttc-v2 .card.step .slist ul,
.ttc-v2 .card.step .slist ol{
  margin:10px 0 0;
  padding-left:22px;
}
.ttc-v2 .card.step .sbody li,
.ttc-v2 .card.step .slist li{
  font-size:var(--step-size);
  line-height:var(--step-line);
  font-weight:var(--step-weight);
  color:var(--step-color);
  font-family:var(--font);
  margin:0 0 6px;
}
.ttc-v2 .card.step .sbody li:last-child,
.ttc-v2 .card.step .slist li:last-child{ margin-bottom:0 }

/* ===================================================================== *
 * ITEM 16a -- "Popular questions": under the SEO text, and a different,
 * lighter colour. The MOVE is in templates/recipe_v3.html; this is the colour.
 *
 * WHAT IT WAS: `--cream` #fffeec with a #e8dfae edge -- the nutrition panel's
 * ground, which the questions block, the related-recipes block and the
 * nutrition panel all share. Three blocks of one colour down one page.
 *
 * WHY WHITE AND NOT A PALER CREAM. #fffeec is already at the top of its
 * range: its relative luminance is 0.985, so "lighter" has almost nowhere to
 * go inside the same hue -- a #fffdf5 would be a change nobody could see, and
 * a change nobody can see is not what was asked for. #ffffff is unambiguously
 * lighter than the cream AND unambiguously lighter than the #f7f7f7 the step
 * cards use, so the block is now the lightest thing in that column and
 * distinct from both of its neighbours.
 *
 * THE EDGE STAYS #e8dfae, so it still reads as one of this page's boxes
 * rather than as a hole in the page. Nothing else about the block moves: same
 * radius, same inset, same type, same <details> behaviour.
 *
 * CONTRAST: the heading is --maroon #51010e and the questions are --dark
 * #1d2327; on #ffffff both go UP against their old ground, so nothing can
 * have got harder to read.
 *
 * THE SELECTOR IS `section#faq.ttc-faq` AND NOT `.ttc-faq`, and loading last
 * is not enough here. recipe-v3-faq.css is linked by the MARKUP, next to the
 * block itself, so it is a <link> in the BODY and therefore later in the
 * document than this sheet in the <head> -- a plain `.ttc-faq` here loses the
 * tie on order. An id plus a class plus a tag beats one class outright and
 * does not depend on which file the browser happened to parse second.
 * Measured: with `.ttc-faq` the block still rendered rgb(255,254,236).
 * ===================================================================== */
section#faq.ttc-faq{ background:#ffffff }

/* ===================================================================== *
 * ITEM 24 (a) -- the step photographs: one size, one clean gap.
 * The SHARED 30px is item 22's number, used here so the editor and the page
 * are spaced by the same rule rather than by two rules that agree today.
 *
 * TWO FAULTS, BOTH MEASURED on the served page at 1440.
 *
 * 1. NO GAP UNDERNEATH. `.ttc-v2 .pshots` is `margin: 26px 0 0` -- 26 above
 *    and ZERO below -- so a photograph group is flush against whatever follows
 *    it. That is the "crammed against the subtitle with no gap". Where two
 *    groups are adjacent the only thing between them is the next group's own
 *    21px, and where a sub-step follows there is nothing at all.
 *
 * 2. TWO DIFFERENT WIDTHS, on pages that should match. Measured:
 *        /recipes/czech-rolls-rohliky-recipe-2/   .pshots  756px
 *        /recipes/60-min-pan-pizza/               .pshots  756px
 *        /recipes/zemlovka-apple-bread-pudding/   .pshots  837px
 *    The cause is an omission rather than a disagreement: recipe-v3.css
 *    indents a step's own runs by `--num-gutter`
 *        .ttc-v2 .card.step > .sbody:not(.is-note) > p,
 *        .ttc-v2 .card.step > .sbody:not(.is-note) > .slist { margin-left: ... }
 *    and `.pshots` is not in that list. A group nested deeper inherits the
 *    indent from its parent and comes out 756; one that is a DIRECT child of
 *    `.sbody` is never indented and comes out 837 -- so the same photograph
 *    group is 81px wider on one recipe than on another, and sits 81px to the
 *    left of the words it illustrates.
 *
 * THE INDENT IS ADDED TO THE EXISTING LIST rather than a width being set.
 * Setting a width would have made the group a fixed size that stops agreeing
 * with the text the first time the gutter changes; joining the rule that
 * already positions the step's paragraphs means the photographs line up with
 * them by construction, at every width, for good.
 *
 * THE RATIOS ARE NOT TOUCHED. `--ratio-1/2/3` (2.38, 1.645, 1.75) are read off
 * Tom's own mockups and are what makes an n1 row taller than an n3 row on
 * purpose. "Consistent size" here means the GROUP is consistently placed and
 * consistently wide; the pictures inside it keep the proportions he drew.
 * ===================================================================== */
.ttc-v2 .pshots{ margin-top:var(--ttc-box-gap,30px);
                 margin-bottom:var(--ttc-box-gap,30px) }
/* Two groups back to back get one 30, not 60 -- sibling margins collapse, and
   this keeps the pair reading as one run of photographs. */
.ttc-v2 .pshots + .pshots{ margin-top:var(--ttc-box-gap,30px) }
.ttc-v2 .card.step > .sbody:not(.is-note) > .pshots{
  margin-left:var(--num-gutter);
}
@media (max-width:1023px){
  .ttc-v2 .card.step > .sbody:not(.is-note) > .pshots{
    margin-left:var(--num-gutter);
  }
}