/* ---- the pill peek popup (js/dvpeek.js) --------------------------------------
   Ported 2026-08-02 from the first edition, where these rules lived in an inline
   <style> block on Compare.aspx (its own comment said it was "written to move
   there unchanged"); here they are the one canonical copy, linked per page by
   whichever page binds the peek. Every rule is gated on ".peekon", the class the
   script adds, so with JavaScript off none of it exists and the pill is the plain
   anchor it always was.

   SIZING. .pkpop sets its own font-size in REM, so the A-/A+ control and the
   browser's own text size both scale it; everything inside is in EM, so the whole
   panel grows in proportion instead of a fixed box strangling text that grew. The
   width is min(24em, viewport minus a margin), which is what keeps it inside the
   screen at 200% text where 24em alone would be wider than the window. It takes its
   own max-height and its own scroller (set in px by the script against the live
   viewport height), because overflow clipping hides overwide content with no
   scrollbar and no sign anything is missing, and a popup that silently lost its
   right hand side or its last two lines would be worse than no popup.

   No transition and no transform anywhere: nothing here animates, so there is
   nothing for a vestibular or photosensitive reader to reduce.

   2026-08-06 fixed the two shapes that were eating the action row on a phone: the
   sticky foot was resting at a negative offset (see the note below .pkacts) and the
   script was sizing the scroller from the layout viewport instead of the visual one
   (see viewportH in js/dvpeek.js). Both are the sizing and the scroll mechanism; this
   line is the third leg, added 2026-08-07 to match the momentum-scroll property every
   other internally-scrolling region on the site already carries (site.css's mobile
   menu and the Compare grid wrapper): without it, older iOS Safari can scroll this
   panel only a step at a time under a finger instead of with momentum, which reads as
   "stuck" even though the content is technically reachable.

   2026-08-07, SIXTH PASS: every var(--token) used for background, border-color,
   color or box-shadow below now carries a literal fallback (see the long note just
   above .pkpop). Not a geometry change; the panel was rendering transparent, not
   misplaced, on the one page (/peekdiag.aspx) that loads this file without also
   loading site.css. Nothing changes on a page that defines the real tokens. */
/* PADDING HAS NO BOTTOM VALUE, ON PURPOSE, since 2026-08-07. See the note
   above .pkacts: the sticky action row supplies its OWN trailing space now,
   so that space is part of the sticky element's own box (always visible
   whenever the row itself is) rather than container padding a sticky child
   can be made to sit in front of. */
/* FALLBACK VALUES ON EVERY PAINT PROPERTY BELOW (background, border-color, color,
   box-shadow), ADDED 2026-08-07, SIXTH PASS, AND THIS IS NOT DECORATIVE.
   /peekdiag.aspx is EnableTheming="false" with no MasterPageFile by its own design
   (see its header comment: standalone on purpose), so it never loads site.css and
   never gets Site.master's automatic per-theme stylesheet injection either. Every
   --panel/--edge2/--ink/--shadow/--panel2/--edge/--muted/--faint/--gold custom
   property this file has always relied on is UNDEFINED there, which is a fact
   about that one page: nowhere else in the codebase links dvpeek.css directly or
   omits Site.master while using it (grepped; OpenQuestions.aspx, Entity.aspx and
   Compare.aspx all carry MasterPageFile and so all load site.css normally, and
   nothing changes for them below, since a var() fallback only engages when the
   referenced property does not resolve at all -- an already-defined custom
   property always wins over its own fallback argument).

   THIS IS WHAT A SCREENSHOT FROM TESTING SHOWS. A var() with no fallback
   that fails to resolve does not error; CSS treats the whole declaration as
   "unset", which for a non-inherited property (background-color, border-color,
   box-shadow) computes to that property's INITIAL value -- transparent, for
   background -- while the box itself keeps every geometric property (position,
   size, radius) that sheet mode sets with ordinary literals. So the panel was
   never mispositioned or mis-sized on that screenshot: it was rendering exactly
   where and how big the sheet CSS says, painted with a transparent fill, which is
   why the page's own underlined pill link showed through the Significator text
   sitting in front of it. The same missing tokens hit the sticky action row and
   its three buttons below (.pkacts / .pkacts>* / .pkclose, further down this
   file), which is the likelier reading of a separate "still cut off"
   report: not a second geometry bug, but the reader unable to SEE where an
   invisible action row's buttons are, on the one page built to test this that
   accidentally stripped its own paint.

   The literal values are this theme's base (dark) tokens, site.css's un-overridden
   :root block, matching the fixed dark presentation peekdiag.aspx's own inline
   styles already assume. */
.peekon .pkpop{position:fixed;left:0;top:0;z-index:60;
  width:min(24em,calc(100vw - 1.5rem));max-width:calc(100vw - 1.5rem);
  overflow-y:auto;overscroll-behavior:contain;-webkit-overflow-scrolling:touch;
  background:var(--panel,#141731);border:1px solid var(--edge2,#3a3f6b);border-radius:12px;
  box-shadow:var(--shadow,0 12px 34px -14px rgba(0,0,0,.6));padding:.7em .85em 0;
  font-size:.92rem;line-height:1.5;color:var(--ink,#eae7f3)}
.peekon .pkpop[hidden]{display:none}
/* ---- PHONE: THE PEEK BECOMES A BOTTOM SHEET -----------------------------
   Decided after three same-day passes at the floating-panel
   arithmetic above (see js/dvpeek.js's place(), and its long comment) all
   failed a real-device repro in a row: the ceiling was computed
   from the layout viewport, then from the header's bottom, then from the
   panel's own computed top, then re-derived from read-back rects with
   visualViewport.offsetTop folded in, and every one of those is arithmetic
   against a coordinate system iOS Safari keeps moving. A bottom sheet does
   not compute a ceiling at all: it asks the browser for one, in DYNAMIC
   viewport units, which is Safari's own answer to "how tall is the visible
   area right now" and updates itself as the address bar comes and goes. It
   is also the better shape for a reader with reduced central vision: a panel
   that appears in the same
   place every time is easier to find than one that
   appears wherever the pill happened to be.

   760px is not invented for this. It is the site's own phone line: the same
   width where Site.master's notification, profile and display-settings
   panels already switch from an anchor-relative popup to a fixed panel
   pinned to the viewport (chrome.css, site.css), because a floating panel
   is exactly the shape that keeps overflowing a phone screen. This is that
   same family of fix, taken one step further to a full sheet.

   THE QUERY STRING MUST MATCH js/dvpeek.js's SHEET_MQ CONSTANT, BYTE FOR
   BYTE. The script detects this same branch with window.matchMedia so it
   can skip its own positioning arithmetic entirely and hand the panel to
   this rule alone; a query that drifts between the two files would leave
   the script fighting a CSS rule it no longer thinks is active, or leave a
   phone running the desktop arithmetic CSS has already overridden. If you
   change the number here, change it in dvpeek.js too, in the same commit.

   top:auto is not decorative. The base rule above sets top:0, and a fixed
   box with BOTH top and bottom pinned stretches to fill the space between
   them, which the browser then reconciles against max-height by dropping
   bottom instead, right when bottom is the one anchor this sheet needs.
   Clearing top lets bottom own the sheet's position and max-height own its
   height, exactly as a bottom sheet should. width:auto and max-width:none
   drop the 24em desktop cap the base rule sets, since left:0/right:0 already
   describe the sheet's whole width. overflow-y:auto is untouched, inherited
   from the base rule above, so the content keeps scrolling inside a height
   the browser bounds rather than a number JavaScript computed; the sticky
   action row (.pkacts, below) rides that same scroller and needs no change
   at all. The 80vh line runs first as the fallback for a browser with no
   dvh support; 80dvh overrides it everywhere that unit exists.

   BOTTOM:0 HERE IS THE FALLBACK, NOT THE ANCHOR. On iOS Safari a fixed
   bottom:0 resolves against
   the LAYOUT viewport, whose edge sits behind the browser's own bottom
   toolbar, so this alone still left the sticky action row unreachable
   exactly as found in testing. js/dvpeek.js's place() now overrides this
   with an inline pop.style.bottom computed from visualViewport, the exact
   height Safari is hiding, recomputed on every scroll and resize; this
   declaration is what is left in force on a browser with no visualViewport
   to compute that number from, where layout and visual already agree.

   PADDING-BOTTOM IS A REQUESTED SAFETY MARGIN, layered UNDER a
   sticky row that no longer tricks its own stick point (see .pkacts below).
   Because .pkacts is the scroller's last child, this trailing space is what
   is left to reveal once a reader scrolls all the way down: the sticky row
   settles into its normal-flow position, at the end of the content, and the
   padding trails visibly beneath it, past the buttons rather than flush
   against them. env(safe-area-inset-bottom) is the home-indicator band on a
   notched iPhone; the plain declaration first is the fallback for a browser
   that does not parse env() at all, never a value paired WITH it. */
@media (max-width:760px){
  .peekon .pkpop{
    position:fixed; top:auto; left:0; right:0; bottom:0;
    width:auto; max-width:none;
    max-height:80vh; max-height:80dvh;
    border-radius:12px 12px 0 0;
    padding-bottom:1.2em;
    padding-bottom:calc(1.2em + env(safe-area-inset-bottom, 0px));
    /* OVERRIDDEN BACK TO auto, found as a scroll-chaining
       regression on a real device: dragging inside the open sheet scrolled the
       PAGE behind it instead of the sheet's own content. overscroll-behavior:
       contain above (inherited, unset here on purpose so it stays in force) is
       verified still reaching this rule -- this media query does not touch it,
       and nothing else in the file redeclares it -- so it is not the cause by
       itself. -webkit-overflow-scrolling:touch, the base rule's own fix for an
       OLDER iOS Safari that could only scroll a step at a time, is a documented
       source of exactly this failure mode on newer engines: it is a no-op on
       modern iOS, momentum scrolling already works from plain overflow:auto
       without it, and it has a known history of fighting position:sticky
       children (this panel's own .pkacts action row) and nested scrollers on
       recent WebKit. It stays for whichever older device the base rule was
       written for, since that is outside this breakpoint's own devices; here,
       where the newest iOS is the one reporting the regression, it is turned
       back off rather than left to keep fighting the sticky footer. */
    -webkit-overflow-scrolling:auto;
  }

  /* THE ACTION ROW LEAVES THE SCROLL FLOW, a follow-up fix. The paragraph
     above ends "the sticky action row
     rides that same scroller and needs no change at all" -- true on
     /peekdiag.aspx, false on a real page once the frame-toolbar-gap fix
     (js/panel-anchor.js) actually raised the sheet's bottom into view. A
     sticky bottom:0 element can only stay pinned while there is still
     scrollable content BELOW its own natural position; .pkacts is the
     scroller's last child, so once a reader reaches the true end of the
     panel it settles into normal flow like anything else. Behind the toolbar
     that settling point was invisible and nobody could tell. Visible, it
     read exactly as described in testing: the action row stalled mid-panel
     with dead space and a stray trailing line ("1816") showing beneath it,
     which looks broken rather than designed.

     Scoped with :has(>.pkscroll) so ONLY dvpeek's own popup is affected.
     js/factwhy.js reuses this file's classes verbatim but builds pkhd/pkbody/
     pkacts as plain siblings with no wrapper (its own header comment lists
     exactly which classes it borrows), so it never matches this selector and
     keeps the untouched sticky behaviour above, in every mode, exactly as it
     did before tonight. */
  .peekon .pkpop:has(>.pkscroll){
    display:flex; flex-direction:column;
    overflow-y:hidden; /* pkscroll is the real scroller now */
    padding-bottom:0; /* .pkacts supplies its own trailing space below */
  }
  /* HIDDEN MUST WIN, and this is the
     actual defect a long earlier chase in this file was after blind. The base
     rule near the top of this file already says .peekon .pkpop[hidden]{
     display:none}, three selectors of equal weight (two classes, one
     attribute). The flex rule immediately above is ALSO three selectors of
     equal weight (:has() counts as its argument's own specificity, a single
     class), so the two rules tie, and a tie is decided by SOURCE ORDER: the
     flex rule, written later in this file, wins, and display:flex overrides
     display:none outright. close() was running correctly the whole time,
     setting pop.hidden = true every time, and the popup stayed on screen
     anyway, fully laid out as a flex column, because nothing in the cascade
     ever told it to stop.

     Proved from an instrumented run on a real device: the tap-click
     snapshot showed closeFired true and popHidden true in the SAME entry
     a simultaneous photo showed the sheet still open on screen, and even
     the tap-START snapshot (before any close ran) already read popHidden
     true while the panel was visibly rendering, which only makes sense if
     the hidden ATTRIBUTE was true throughout and simply never suppressed
     the box. Every desktop pass that read closeFired true and
     popHidden true and counted that as a visual close was reading a flag
     that had stopped being authoritative the moment the flex rule shipped,
     on every surface where a real pkscroll child makes it match.

     ONE MORE SELECTOR IS THE FIX, not reordering: adding [hidden] here
     raises this rule to four selectors of equal weight, which beats the
     flex rule's three regardless of which one comes first in the file, so
     the fix does not depend on anyone keeping these two rules in a
     particular order forever. */
  .peekon .pkpop:has(>.pkscroll)[hidden]{
    display:none;
  }
  /* PKHD LEAVES THE SCROLL FLOW TOO, another follow-up:
     the Close X stopped working once pkhd was the first child of
     a container a touch drag is allowed to start scrolling from. flex:0 0
     auto is the exact same treatment .pkacts already gets below, for the
     same reason, a control meant to be reachable at all times is not part of
     the region a finger may drag. */
  .peekon .pkpop:has(>.pkscroll)>.pkhd{
    flex:0 0 auto;
  }
  .peekon .pkpop:has(>.pkscroll)>.pkscroll{
    flex:1 1 auto; min-width:0; min-height:0;
    overflow-y:auto; overscroll-behavior:contain; -webkit-overflow-scrolling:auto;
  }
  /* NOT STICKY HERE: a flex sibling that sits OUTSIDE the scroller needs no
     stuck offset at all, it is simply always the last thing in the column,
     at the column's own bottom edge, which js/panel-anchor.js's sheet branch
     now keeps at the true visible line (framedGap, plus the same-night top
     clamp that stops the box outgrowing it upward). The safe-area trailing
     padding moves here from .pkpop above, onto the element that now actually
     owns the sheet's bottom edge. */
  .peekon .pkpop:has(>.pkscroll)>.pkacts{
    flex:0 0 auto;
    position:static;
    padding-bottom:1.2em;
    padding-bottom:calc(1.2em + env(safe-area-inset-bottom, 0px));
  }
}
.peekon .pkhd{margin:0 0 .3em;display:flex;align-items:center;gap:.5em}
/* The glyph beside the name: the entity's own monochrome line art, sized in em so
   it grows with the reader's text, currentColor so it holds in both themes. */
.peekon .pkglyph{flex:none;width:2.2em;height:2.2em;color:var(--gold-soft)}
.peekon .pkglyph svg{width:100%;height:100%;display:block}
.peekon .pkglyph[hidden]{display:none}
.peekon .pkname{font-family:var(--serif);font-weight:600;font-size:1.05em;color:var(--gold);
  overflow-wrap:anywhere;min-width:0}
/* CLOSE, top right. It used to sit at the foot beside the
   other two controls. margin-left:auto rather than absolute positioning, so it can
   never overlap a long entity name: the name has min-width:0 and wraps, and the
   button simply keeps its own column. 2.2em square matches the action row's control
   height, so it scales with the A-/A+ control and clears the 24px target floor at
   every text size instead of being the small corner target an icon close usually is.
   align-self:flex-start pins it to the top of a header row whose height is set by a
   2.2em glyph beside a name that may run to three lines. */
.peekon .pkclose{flex:none;margin-left:auto;align-self:flex-start;
  width:2.2em;height:2.2em;padding:0;
  display:inline-flex;align-items:center;justify-content:center;
  border-radius:.6em;border:1px solid var(--edge2,#3a3f6b);background:var(--panel2,#1b1f3d);
  color:var(--ink,#eae7f3);font:inherit;cursor:pointer}
.peekon .pkclose svg{width:1.1em;height:1.1em;display:block}
.peekon .pkclose:hover{border-color:var(--gold);color:var(--gold)}
.peekon .pkclose:focus-visible{outline:2px solid var(--gold);outline-offset:2px}
.peekon .pkbody>*{margin:0 0 .45em}
.peekon .pkbody>*:last-child{margin-bottom:0}
.peekon .pkkind{color:var(--faint);font-size:.82em;text-transform:uppercase;letter-spacing:.06em;
  overflow-wrap:anywhere}
/* w2144-catalogueprice, 2026-08-17, ruling 564: the third of the catalogue's
   three price-blind surfaces. Same gold/serif/tabular-nums treatment
   report.css's .tfrom already gives the identical concept on the listing
   card and the detail view, sized in em to match every other rule in this
   file rather than report.css's rem, since this panel scales as a unit with
   the A-/A+ control the same way its other lines already do. */
.peekon .pkprice{font-family:var(--serif);font-size:1.05em;color:var(--gold);
  font-variant-numeric:tabular-nums}
.peekon .pkdesc{color:var(--ink);overflow-wrap:break-word}
/* Provenance line, above the lead. Same principle as .pkst below: the SENTENCE
   carries the whole meaning and the left rule is decoration on top of it, so nothing
   is lost by a reader who cannot see the rule or the tint (WCAG 1.4.1). Sized in em
   inside a popup already sized in em, so it grows with the A-/A+ control; wraps
   normally and adds no fixed height, which matters because this panel scrolls
   internally at 200% text. */
.peekon .pkwarn{color:var(--muted);font-size:.85em;line-height:1.5;
  border-left:2px solid var(--edge2);padding-left:.6em;overflow-wrap:break-word}
.peekon .pkfacts{margin:.5em 0 0;padding:0}
.peekon .pkf{display:block;padding:.3em 0;border-top:1px solid var(--edge)}
.peekon .pkf dt{color:var(--faint);font-size:.78em;text-transform:uppercase;letter-spacing:.05em;
  overflow-wrap:anywhere}
.peekon .pkf dd{margin:0;font-size:.94em;overflow-wrap:break-word}
/* A contested claim says so IN WORDS. Never colour alone (WCAG 1.4.1); the colour
   here is decoration on top of a word that already carries the whole meaning. */
.peekon .pkst{color:var(--dark-c);font-size:.85em;font-weight:600;white-space:normal}
/* .pkdnote: the lead's own StatusNote, real text
   never a title attribute, widened onto the identical declaration a fact's
   own source line already uses rather than a third small-muted-note rule. */
.peekon .pkfsrc,.peekon .pksrc,.peekon .pkdnote{display:block;color:var(--faint);font-size:.78em;line-height:1.45;
  margin-top:.25em;overflow-wrap:break-word}
.peekon .pksrc{border-top:1px solid var(--edge);padding-top:.4em;margin-top:.5em}
.peekon .pkl{text-transform:uppercase;letter-spacing:.07em;font-weight:600;margin-right:.35em}
/* THE REPORT-SECTION PEEK'S OWN TWO BLOCKS (ReportSectionPeek.ashx only): an
   example excerpt and the approved reviews. Same shape as .pkfacts either
   side of them so the panel reads as one design rather than two, and the
   same border-top rhythm .pkf already uses to separate one block from the
   next without a rule that depends on colour to be seen. */
.peekon .pksamp{border-top:1px solid var(--edge);padding-top:.4em}
.peekon .pksamptext{color:var(--ink);font-style:italic;overflow-wrap:break-word}
.peekon .pkrevs{border-top:1px solid var(--edge);padding-top:.4em}
.peekon .pkrev{padding:.3em 0;border-top:1px solid var(--edge)}
.peekon .pkrev:first-of-type{border-top:none;padding-top:0}
.peekon .pkrevhd{color:var(--faint);font-size:.82em;font-weight:600;overflow-wrap:anywhere}
.peekon .pkrevtext{color:var(--ink);overflow-wrap:break-word}
/* THE SKIP-PREVIEWS CONTROL. Its own
   quiet row above the action row, muted and border-free so it reads as a
   secondary, once-in-a-while setting rather than a fourth peer of Read
   Aloud/Open/New Window (see the note over .pkacts below: three already
   risks two "open" variants reading as one smudge at low acuity, and this is
   not a control a reader reaches for on every visit). Still a real button
   clearing the 24px WCAG 2.5.8 floor, sized in em so it grows with the
   A-/A+ control exactly as everything else in this panel does. */
.peekon .pkskip{margin:.5em 0 0}
.peekon .pkskipbtn{display:inline-flex;align-items:center;min-height:2.2em;padding:.2em 0;
  background:none;border:0;color:var(--faint);font:inherit;font-size:.8em;text-decoration:underline;
  text-underline-offset:2px;cursor:pointer}
.peekon .pkskipbtn:hover{color:var(--gold)}
.peekon .pkskipbtn:focus-visible{outline:2px solid var(--gold);outline-offset:2px}
/* The action row wraps rather than compressing its buttons: at 200% text three
   controls in one line would otherwise squeeze each other under the target size.
   And it is STICKY to the foot of the panel, because at 200% the text alone fills
   the popup's own scroller and the controls would otherwise be below the fold of a
   panel the reader cannot see the bottom of.

   IT HELD THREE, THEN TWO, AND HOLDS THREE AGAIN. Close moved to an X in the header,
   and an open control beside the
   new-window one was added the same day, so the row is Read Aloud, Open, New Window: nothing leaves, this
   window moves, a second window appears. The sticky foot is what makes that safe at
   large text, and Close is deliberately not among them, because dismissal is the one
   thing a reader wants without travelling to the end of a scrolling panel.

   flex-wrap plus min-width:0 on the label rather than nowrap: three controls at 200%
   text wrap to two lines and one of them may wrap its own word, which is what a
   reader at that size wants. white-space:nowrap here would push the row wider than
   the panel and html{overflow-x:hidden} would clip it with no scrollbar and no sign
   anything had gone. */
/* STICKY TO ZERO, NEVER TO A NEGATIVE OFFSET IN EITHER DIRECTION. It read
   bottom:-.6em until 2026-08-06 and margin-bottom:-.6em from that date until
   2026-08-07, and BOTH were the same defect wearing a different property.
   The first comment written here claimed moving the negative value from
   bottom to margin-bottom "moves where it is DRAWN without moving where it
   STICKS." That was wrong: position:sticky computes its stuck offset
   against the element's MARGIN BOX, so a negative bottom MARGIN shifts the
   effective stick point down by exactly the same amount a negative bottom
   OFFSET did. Either way the row's last .6em was deliberately below the
   scrollport, a second defect found by reading this
   rule rather than by another repro: on a desktop that is only the row's
   own padding and nobody notices; on a phone it was one more reason the
   action row sat exactly where reports said it could not be reached.

   Clicking a pill on mobile to get the peek window did not
   allow scrolling far enough down to the buttons to open them. THE FLUSH
   LOOK IS KEPT, but by giving the row its OWN trailing padding rather than
   cancelling the panel's, which is why .pkpop above no longer carries any
   bottom padding of its own: that space now lives entirely inside .pkacts's
   box, which is the sticky element itself, so it can never be positioned
   somewhere the sticky rule's own offset does not also protect.

   STILL TRUE HERE, AND STILL WHAT js/factwhy.js's OWN PANEL RUNS ON IN EVERY
   MODE. A later rule overrides position and padding-bottom for
   dvpeek's OWN popup, in sheet mode only, scoped to
   .pkpop:has(>.pkscroll)>.pkacts a little further up this file: see that
   rule's own note for why sticky stopped being enough once the sheet's
   bottom actually reached the visible screen on a real page. */
.peekon .pkacts{display:flex;flex-wrap:wrap;gap:.4em;margin-top:.6em;
  border-top:1px solid var(--edge,#2b2f55);padding-top:.5em;
  position:sticky;bottom:0;background:var(--panel,#141731);
  padding-bottom:.6em}
/* 2.6em rather than 2.2em, because em here resolves against this element's OWN
   font-size, which the line below shrinks to .85em. At 2.2em these controls measured
   29 CSS px against the header Close's 34, so the panel had two target sizes in it.
   2.6 x .85 is 2.21em of the PANEL's font, which is what the Close is, so every
   control in the popup is now the same height at every text size and all of them
   clear the 24px floor (WCAG 2.5.8) by a wide margin. */
.peekon .pkacts>*{min-height:2.6em;min-width:2.6em;display:inline-flex;align-items:center;
  justify-content:center;gap:.45em;
  padding:.25em .7em;border-radius:.6em;border:1px solid var(--edge2,#3a3f6b);background:var(--panel2,#1b1f3d);
  color:var(--ink,#eae7f3);font:inherit;font-size:.85em;text-decoration:none;cursor:pointer}
.peekon .pkacts>*:hover{border-color:var(--gold);color:var(--gold)}
.peekon .pkacts>*:focus-visible{outline:2px solid var(--gold);outline-offset:2px}
/* ICON PLUS WORD, and the word is why the icons are usable at all. Icons
   replaced text buttons here; the labels stayed beside them because a
   reader with reduced central vision cannot identify a control by
   resolving a small shape, and two of the three icons mean a variety of "open". The
   icon is sized in em so it grows with the A-/A+ control, and flex:none so it is
   never the thing that shrinks when the label wraps. */
.peekon .pkico{width:1.15em;height:1.15em;flex:none;display:block}
/* The icon wrapper exists so the speak button can TOGGLE between two icons by hiding
   one rather than by replacing its own contents. See the long note in speakFace: an
   element removed from the document mid-press stops being the element the press landed
   on, and the panel then reads its own button as a click outside itself. [hidden] is
   spelled out here because the UA rule that honours it does not reach an <svg>. */
.peekon .pkicw{display:block;flex:none;line-height:0}
.peekon .pkicw[hidden]{display:none}
.peekon .pklbl{min-width:0}
.peekon .pkopen{font-weight:600}
/* The details button, added by the script only where the pointer cannot hover, so
   the pill's own tap keeps navigating to the entity page. 1.8em square with .25em
   of padding clears the 24px WCAG 2.5.8 floor at every text size, and grows with the
   reader's text rather than staying a fixed pixel box. */
.peekon .pkbtn{width:1.8em;height:1.8em;min-width:24px;min-height:24px;flex:none;padding:.25em;margin-left:-.25em;
  display:inline-flex;align-items:center;justify-content:center;vertical-align:middle;
  background:none;border:1px solid var(--edge2);border-radius:99px;color:var(--muted);cursor:pointer}
.peekon .pkbtn svg{width:100%;height:100%}
.peekon .pkbtn:focus-visible{outline:2px solid var(--gold);outline-offset:2px}
.peekon .pkbtn[aria-expanded="true"]{border-color:var(--gold);color:var(--gold)}

/* ---- the "why" panel for a debated, debunked or unknown fact --------------
   js/factwhy.js builds its own small panel reusing THIS FILE's classes verbatim
   (pkpop, pkhd, pkname, pkclose, pkbody, pkkind, pkdesc, pkst, pksrc, pkl,
   pkacts, pkspeak, pkico, pkicw, pklbl) on a wrapper carrying "peekon", the same
   gate class every rule above is written against. That is what makes it
   a similar peek window, like the entity peek popup:
   one stylesheet family, not a second copy of it. Everything above this
   comment (colours, REM/EM sizing, the 200%-text behaviour, the phone bottom
   sheet) already applies with no change. Only the open-question divider below
   is genuinely new CSS.

   THE DESKTOP POSITION RULE THAT USED TO LIVE HERE IS GONE,
   REMOVED RATHER THAN CHANGED. It read .peekon .pkwhy{left:50%;
   top:4rem;transform:translateX(-50%);max-height:calc(100vh - 6rem)}, a static
   centred position reasoned out when this panel was built: paragraph-depth
   prose reading better stable than jockeying for space beside a tiny badge.
   Found the same day work on a different feature was in
   this file's neighbourhood: a Well-attested click landed in the center of
   the page instead of next to the item like the peek does. That overrides the
   original reasoning outright rather than narrowing it, so the rule is deleted
   rather than left dormant behind a wider guard. js/factwhy.js now positions
   .pkwhy exactly as js/dvpeek.js positions its own .pkpop, through the shared
   window.DivPanelAnchor (js/panel-anchor.js): anchored beside the trigger
   button, flipping and clamping to the viewport, falling to the same phone
   bottom sheet below 760px the base .pkpop rule already gives every panel in
   this family. A left/top/transform rule declared here would only fight the
   inline styles that placement now sets, so nothing replaces it. */
/* The open-question block, unknown-status facts only: the same border-top-
   plus-padding divider .pksrc/.pksamp/.pkrevs already use above, so a third
   block in the same panel reads as one design rather than a new one. */
.peekon .pkwhyq{border-top:1px solid var(--edge);padding-top:.4em;margin-top:.5em}