/* ---- settings menu ---- */
.tools-menu__overlay {
  position: absolute; z-index: 999; list-style: none; margin: 0; padding: 0;
  background-color: #fff; color: #000; border: 1px solid black;
  box-sizing: border-box; width: 190px;
}
/* reference/itd-inline.css:2604 — html.white-on-black .tools-menu__overlay
   {background-color:black;border:1px solid white}. Plain white border, not
   the cyan accent token: an earlier round invented --dark-accent here. */
html.white-on-black .tools-menu__overlay { background-color: black; color: #fff; border: 1px solid #fff; }
.tools-menu__overlay[hidden] { display: none; }
/* The top-level menu hangs off #toolsAnchor (js/app.js), a zero-width point
   pinned to InfoPanelFrameID's own right:8px. With no edge declared here it
   would inherit that anchor's left position and render mostly off the right
   side of the viewport; right:0 instead grows the 190px panel leftward from
   the anchor, under the Settings button, the way the driver's own dropdown
   opens. Scoped to the id, not the shared .tools-menu__overlay class, so it
   does not disturb the nested Resize Text/Color Theme submenus below, which
   position off their own trigger via `left: 100%` instead. */
#tools-menu1 { right: 0; }
.tools-menu__item {
  box-sizing: border-box; cursor: pointer; display: block; font-size: .875rem;
  width: 100%; font-weight: normal; margin: 3px 0 0; height: 25px; line-height: 25px;
  text-align: left; padding: 0 10px; position: relative; white-space: nowrap;
}
.tools-menu__item:first-child { margin-top: 6px; }
.tools-menu__item:last-child  { margin-bottom: 6px; }
/* reference/itd-inline.css:2223-2231 (html.default .tools-menu__item:hover ...
   {font-weight:700;} / {background-color:#d2d2d2;}) — light grey with bold
   text, not the chrome-blue/white an earlier round invented. Scoped to
   html.default, matching the reference's own selector exactly: a bare
   .tools-menu__item:hover here would leak its background-color into dark
   theme too, since the html.white-on-black rule below only adds
   font-weight and sets no background of its own to override it with. */
html.default .tools-menu__item:hover { font-weight: 700; background-color: #d2d2d2; }
/* reference/itd-inline.css:2594 — html.white-on-black
   li.tools-menu__item[role^="menuitem"]:hover {font-weight:700;} only. No
   background-color at all in dark theme (an earlier round invented one). */
html.white-on-black .tools-menu__item:hover { font-weight: 700; }
.tools-menu__item.active { font-weight: bold; }
.tools-menu__item .submenu-caret { position: absolute; right: 8px; }
.tools-menu__item .submenu-caret svg { width: 10px; height: 10px; fill: currentColor; }
/* Opens to the LEFT of its trigger (right:100%), not the right (left:100%
   would be the more usual dropdown-submenu direction): #tools-menu1 itself
   is right-anchored flush against the header's right edge (see #tools-menu1
   above), so a submenu that grew further rightward from "Resize Text" or
   "Color Theme" would run off the same edge the outer menu was just pulled
   back from. */
.tools-menu__item > .tools-menu__overlay { right: 100%; left: auto; top: -1px; }

/* ---- dialogs ----
   Measured from the driver's live calculator and notes panels
   (reference/itd-panels.txt, PARENT COMPUTED STYLES): both render as a
   #d6dcec panel inside a 3px #004976 border with a 5px radius, and their
   close button is a 25x25 chrome-filled square, not a 20x20 one. */
.dialog {
  position: fixed; z-index: 1000;
  background-color: #d6dcec; color: #000;
  border: 3px solid var(--chrome); border-radius: 5px; min-width: 240px;
}
html.white-on-black .dialog { background-color: #000; color: #fff; border-color: #fff; }
.dialog[hidden] { display: none; }
.dialog .handle { cursor: move; position: relative; }
.dialog .handle h2 { font-size: 13px; margin: 0 8px; padding-top: 4px; }
.dialog .closeButton {
  position: absolute; right: 15px; top: 6px;
  width: 25px; height: 25px; padding: 1px; border-radius: 5px; cursor: pointer;
  border: 1px solid var(--chrome); background-color: var(--chrome); color: #fff;
  font-family: var(--font-button); font-size: 13.3333px; text-align: center;
}
.dialog .closeButton svg { width: 21px; height: 21px; fill: #fff; }
.dialog .closeButton:focus { outline: 2px dotted #fff; outline-offset: 2px; }
.dialog .closeButton:hover svg { fill: var(--chrome); stroke: #fff; }
/* reference/itd-inline.css:2557-2563 — dark-theme close-button chrome,
   shared by every .dialog (Notes is the first one built; Calculator/Help
   pick this up too). Task 10 shipped the light-mode closeButton above with
   no dark counterpart yet; this fills that in from the driver's own rule
   rather than leaving Notes' close button chrome-blue against a black
   dialog. Omits the driver's redundant `border-color:white` on the inner
   svg (itd-inline.css:2552) — the svg itself has no border in this build,
   so that sub-declaration would be a no-op either way. */
html.white-on-black .dialog .closeButton {
  border: 1px solid #fff; background-color: #000; color: #fff;
}
html.white-on-black .dialog .closeButton svg { fill: #fff; }
html.white-on-black .dialog .closeButton:hover,
html.white-on-black .dialog .closeButton:focus {
  outline: 2px dotted #fff; outline-offset: 2px;
  background-color: #000; color: #fff;
}
.modal-dialog { padding: 10px; }

/* No #scrim rule: the driver's own tool dialogs (calculator/notes/
   sessionstatus/timestatus — reference/itd-dom.html:85,139,161,547, all
   `.dialog.modal-dialog-container`, plus #helpContainer at :218) are
   floating, draggable panels with no backdrop sibling in the DOM and no
   dimming visible behind them in the reference captures (e.g.
   reference/step1-new-dark-calc.png shows the Calculator open over a fully
   undimmed exam question). The only backdrop rule in the whole reference/
   corpus is `.viewer-backdrop { background-color: rgba(0,0,0,.95) }`
   (reference/itd-panels.txt:1592-1594), but that belongs to a different,
   unrelated component — a Viewer.js-style full-screen image/media-gallery
   lightbox (paired with .viewer-open/.viewer-show/.viewer-hide, and the
   "Media Gallery" markup in reference/itd-item-frame.txt), not the tool
   dialogs Task 15 builds. An earlier round invented a scrim here with no
   reference basis; removed rather than kept for Task 15 to build on. */

/* ---- notes dialog (js/notes.js) ----
   reference/itd-dom.html:138-149 is the driver's real Notes markup: id="Note"
   toggles #notesContainer > #notes (class="dialog modal-dialog-container
   notes"), and inside #notes the .handle, .modal-dialog and the two action
   buttons are plain siblings — no wrapping flex row around the buttons
   exists in the driver, so this build's markup mirrors that structure
   directly rather than inventing a `.noteActions` container.

   All geometry/colour below is reference/itd-panels.txt:10228-10283 (PARENT
   COMPUTED STYLES) unless separately cited; #notes itself already inherits
   .dialog's shared background/border/radius above. */
#notes {
  top: 70px; right: 24px; /* placement only, not driver-measured: the real
    dialog is user-draggable from an initial JS-computed position we have no
    equivalent for. Pinned top-right so it never covers the item stem. */
  width: 381px; height: 191px; /* :10228's OUTER 381x191 used directly: this
    project's global `* { box-sizing: border-box }` (shell.css:1) makes a
    declared width/height the outer size, not content-box, so 375x185 here
    would render 6px short in both dimensions. border-box then derives the
    content box back down to 375x185 automatically via the shared .dialog's
    3px border, matching the reference's own content-box figure. */
}

/* reference/itd-dom.html:140 — Notes' own h2 carries ITS-visually-hidden
   (unlike Help's plain visible <h2>, itd-dom.html:219, which the generic
   `.dialog .handle h2` rule above is for). reference/itd-panels.txt:10239
   measures #notes .handle at 375x0 — it must contribute no height, so this
   collapses the heading with the standard clip-to-1px sr-only technique
   (kept in the accessibility tree, unlike display:none) instead of the
   visible style above, which is Help's alone. #notes here (an ID selector)
   outranks the bare-class rule regardless of source order, so this does not
   have to touch that shared rule to win. */
#notes .handle h2 {
  position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0;
  overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0;
}

/* reference/itd-inline.css:757 (`.modal-dialog{}` — no padding of its own
   in the driver) plus :141's inline `style="margin-top:40px"` and :535
   (`#notesContainer #popup-msg{padding: 0 10px}`, folded directly into this
   wrapper instead of adding a #popup-msg div with no other job). Overrides
   the generic `.modal-dialog{padding:10px}` above, which would push
   #noteBox and the two buttons below it out past #notes's own fixed 185px
   height. */
#notes .modal-dialog { margin-top: 40px; padding: 0 10px; }

/* reference/itd-panels.txt:10247 — outer 354x106, content 348x100. Width/
   height are the OUTER 354x106 for the same border-box reason as #notes
   above (shell.css:1) — border-box then subtracts the 1px border + 2px
   padding on each side to land the content box at exactly 348x100. The
   monospace font-family and the #767676 border are both real computed
   values in the driver (the browser's own default form-control border
   colour there, not a stylesheet literal) rather than invented choices —
   reproduced explicitly here since nothing guarantees an unset border
   renders identically across browsers/engines. */
#noteBox {
  display: block; width: 354px; height: 106px; resize: none; overflow: auto;
  background-color: #fff; color: #000;
  font-family: monospace; font-size: 13.3333px;
  border: 1px solid #767676; padding: 2px;
}
html.default #noteBox:focus { outline: 1px solid var(--chrome); } /* itd-inline.css:542 */
html.white-on-black #noteBox { background-color: #000; color: #fff; } /* itd-inline.css:543 */

/* reference/itd-inline.css:544-557 — ONE shared rule for both
   `#notesContainer .saveandclose, #notesContainer .deletenote`: the driver
   does not give Delete Note a different colour scheme (no white/chrome
   swap), confirmed by reference/itd-panels.txt:10258-10283 measuring
   identical background/colour/border/font for both buttons. box-sizing:
   border-box makes the declared 120x27 the OUTER size directly, matching
   the computed 120x27 without depending on the browser's unstated default
   box-sizing for <button>. */
#notes .saveandclose, #notes .deletenote {
  box-sizing: border-box; position: absolute; width: 120px; height: 27px;
  margin-top: 5px; padding: 5px; cursor: pointer;
  background-color: #f0f0f0; color: #000;
  font-family: var(--font-button); font-size: 13.3333px; font-weight: 700;
  border: 1px solid var(--chrome); border-radius: 5px;
}
#notes .saveandclose { left: 12px; } /* itd-inline.css:565 */
#notes .deletenote { right: 12px; } /* itd-inline.css:569 */
/* itd-inline.css:560 — `#notesContainer button:not([disabled]):hover{background-color:lightgray;}` */
#notes button:not(:disabled):hover { background-color: lightgray; }
/* No driver dark-theme rule found for .saveandclose/.deletenote (searched
   reference/itd-inline.css for white-on-black + saveandclose/deletenote/
   notesContainer: no match — the only hit is #noteBox above). They are NOT
   descendants of .modal-dialog (real markup has them as #notes's direct
   children, siblings of .modal-dialog — itd-dom.html:144-145), so the
   driver's `html.white-on-black .modal-dialog button` rule (itd-inline.css:
   2519) does not reach them either. Left unstyled for dark theme rather
   than inventing a swap: they keep the same #f0f0f0/black/chrome-border
   look against the dialog's own dark background. Flagged, not fixed. */

/* ---- calculator dialog (js/calculator.js) ----
   Every value below is lifted from the driver's own calculator iframe —
   reference/itd-panels.txt, FRAME calcFrame (lines 3054-3116) — not
   invented: this task originally had no ground truth and its first pass
   was replaced once the real capture came in. Per-key classes (operator/
   command/clear-all/equals/number/decimal) match the driver's own button
   classes verbatim (reference/itd-panels.txt:3172-3292); this build's own
   `.calcKey`/`.calcRow` wrapper names do not need to match the driver's
   `.calcButton`/`.keys`, only the per-key class list does. #calculator
   itself already inherits .dialog's shared background/border/radius from
   Task 12 above. */
/* reference/itd-panels.txt PARENT COMPUTED STYLES — #calculator [256x301 @
   1013,452]: width 249.891px + height 295px, each +6px for the shared
   .dialog's 3px border (Task 12). This project's global
   `* { box-sizing: border-box }` (shell.css:1) makes a declared width/
   height the OUTER size directly, so 256x301 here (not the driver's own
   249.891x295 content-box figures) is what reproduces that capture; see
   #notes above for the identical reasoning. right/bottom are placement
   only (the capture's x,y is wherever that draggable dialog happened to be
   sitting, not a fixed anchor) and are unaffected by this box-sizing note. */
#calculator { width: 256px; height: 301px; right: 24px; bottom: 70px; }
.calculator { background: #d6dcec; } /* reference/itd-panels.txt:3067 */

/* reference/itd-panels.txt:3058 (font/size/alignment) + :3068
   (background/border/color) — driver selector is `.calculator .top
   .output`, applied here to the single #calcDisplay element this build
   uses in its place. */
/* box-sizing:content-box is load-bearing, and is the FINDINGS.md box-sizing
   trap firing again. The driver has no `* { box-sizing: border-box }` reset,
   so its `height: 1.7rem` (27.2px) is the CONTENT height and the element
   measures 33.2px outer once its 2px padding and 2px border are added. Under
   this project's global border-box reset the same declaration made 27.2px the
   OUTER height, leaving a 21.2px content box for a 24px font whose line box
   is 29px — so `overflow: hidden` cut 7.8px off the bottom of every digit
   (measured). Restoring content-box gives the line box a 27.2px well to sit
   in, which is what reference/step1-new-dark-calc.png shows: the "0" floats
   clear of both borders.

   display/flex-direction/align-items/letter-spacing are the driver's own
   (reference/itd-panels.txt:3058) and had been dropped in favour of a plain
   `display:block; text-align:right`. row-reverse is what right-aligns the
   value in a flex row, and align-items:flex-end is what seats the digits on
   the display's floor instead of hanging them from its ceiling — with 1.8px
   of leading left over, that is the difference between clipping the tops of
   the numerals and clipping nothing visible.

   Not adopted from :3058: `margin-top: 30px`. In the driver the calculator
   body is its own iframe and the dialog's close button lives OUTSIDE it, so
   that margin is clearance for chrome we render INSIDE #calculator as a real
   title bar. Copying it would double the gap. */
#calcDisplay {
  box-sizing: content-box;
  display: flex; flex-direction: row-reverse; align-items: flex-end;
  font-family: "Segoe UI Light", "Open Sans", Verdana, sans-serif; font-size: 1.5rem;
  letter-spacing: 1px;
  background: #fff; border: 1px solid #000; color: #000;
  height: 1.7rem; padding: 2px 0.625rem; margin: .25rem; overflow: hidden;
}
/* reference/itd-panels.txt:3090-3098 — driver's `.top, .keys` flex row and
   `.keys > div` layout, reused here for `.calcRow`/`.calcRow > div`; the
   zero key's wrapping div keeps the driver's own calc0-container name and
   its :3098 flex-grow: 1.5. */
.calcRow { display: flex; flex-direction: row; justify-content: space-between;
           align-items: stretch; width: 100%; padding: 2px 0; }
.calcRow > div { flex: 1 1; text-align: center; align-self: stretch; }
.calcRow > div.calc0-container { flex-grow: 1.5; }

/* reference/itd-panels.txt:3061 — `.calculator .keys button` base chrome,
   applied to `.calcKey`. Gradient/colour rules below are :3069-3073
   (light theme) and :3077-3081 (dark theme). */
.calcKey {
  width: calc(100% - .5rem); cursor: pointer;
  border-radius: 3px; border: 1px solid var(--chrome); color: #000;
  font-family: var(--font-shell); font-weight: bold; padding: 5px 8px; text-align: center;
  background: linear-gradient(#BBB 44%, #EEE); /* :3069 */
}
.calcKey.operator  { background: linear-gradient(#A7B7F5, #7999F8); } /* :3070 */
.calcKey.command   { background: linear-gradient(#C286D6, #D4C9E8); } /* :3071 */
.calcKey.equals,
.calcKey.clear-all { background: linear-gradient(#D8C26D, #F7DB7F); } /* :3072 */
.calcKey:hover     { background: linear-gradient(#C286D6, #D4C9E8); } /* :3073 */

html.white-on-black .calculator            { background: #000; } /* :3077 */
html.white-on-black #calcDisplay           { background: #000; color: #fff; border: 1px solid #fff; } /* :3079 */
html.white-on-black .calcKey,
html.white-on-black .calcKey.operator,
html.white-on-black .calcKey.command       { background: #000; color: #fff; border: 1px solid #fff; } /* :3080-3081 */
html.white-on-black .calcKey:hover         { background: #fff; color: #000; } /* :3084 */
/* No driver dark-theme rule for .calcKey.equals specifically (:3083 is an
   empty override) — the shared `.calcKey` dark rule above already covers
   it, matching the driver's own no-op there. Its :hover neighbour is NOT
   empty though (:3085 — `.calculator .keys button.equals:hover {background:
   #abb850;color:#ffffff}`, olive, not the shared white/black swap above):
   the extra .equals class outranks the bare `.calcKey:hover` rule so this
   wins without needing !important or reordering. */
html.white-on-black .calcKey.equals:hover  { background: #abb850; color: #fff; } /* :3085 */
html.white-on-black .calcKey:focus         { outline: 2px solid cornflowerblue; }

/* ---- lab values panel ----
   Values below come from the driver's lab-values iframe —
   reference/itd-panels.txt, FRAME ExhibitFrame (lines 3307-7096). The pane
   split percentage and the dialog's own placement are ours, unverified. */

/* #MainContainerID and #itemPane base layout live in css/item.css (Task 7).
   #itemPane is NOT a direct child of #MainContainerID — it sits two levels
   down, inside #ElementDisplayFrameID — and #MainContainerID is not a flex
   container for its children (see css/item.css's own comment on that). A
   bare `#MainContainerID.labsOpen #itemPane { flex: 0 0 62% }` would
   therefore be inert: flex-basis only does anything on an actual flex item.
   #ElementDisplayFrameID is the real direct child, so it gets both the
   `display: flex` that turns #MainContainerID into a flex row and the
   69.8% flex-basis; #itemPane (display:block, height:100% of that frame)
   narrows along with it for free.

   The item column does NOT narrow with it any more. .ITSStemText's cap is
   now an absolute calc() off --item-vw (css/item.css), not a percentage of
   the pane, because that is what the driver's `vw` is. The driver has its
   own rule for this case — `html.labActive .ITSStemText, .optionOutline
   {max-width:80vw !important}`, reference/itd-item-frame.txt:2572-2575 — and
   it is deliberately NOT implemented, because the one capture of the state
   contradicts it: reference/step1-new-labs.png's stem wraps at 569-577px
   (measured from its line breaks by the method in test/item-geometry.test.
   mjs), and 80vw cannot produce that at any frame width readable off the
   screenshot. The split itself is measurable, however: the same capture
   puts the divider at x=925 in the 1174px-wide #MainContainerID, and the
   driver's own rule says `html.labActive #contentCover { width:69.8% }`
   (reference/itd-inline.css:3051). */
#MainContainerID.labsOpen {
  display: flex;
  /* Keep the driver's deliberate 905px middle band at 1280x1024. Without
     an explicit cross-axis size, the lab table's min-content height grows
     this flex item to ~1227px and pushes the footer entirely off screen. */
  flex: 0 0 calc(100vh - var(--header-h) - var(--footer-h) + 2px);
  height: calc(100vh - var(--header-h) - var(--footer-h) + 2px);
  min-height: 0; overflow: hidden;
}
#MainContainerID.labsOpen #ElementDisplayFrameID { flex: 0 0 69.8%; min-width: 0; }

/* ---- the panel itself ----
   Everything from here to the end of the Lab Values rules is the driver's
   own stylesheet for this frame, carried over rule for rule and scoped
   under #labsPane, with js/labs.js emitting the frame's own element
   structure. It was arrived at by REBUILDING the frame — the captured
   stylesheet plus the captured DOM, rendered at the frame's size — and
   comparing every box with this panel's; test/labs-driver.test.mjs does
   that comparison on every run. An earlier version restated the rules by
   hand and drifted: a different typeface, a 15px line box where the
   driver's is 15.68px, indents lost to a more specific padding rule.

   Three nested boxes, as in the driver:
     #labsPane  = .exhibitScrollWrapper — white, 1px black border
                  (reference/itd-inline.css:2183). In reference/
                  step1-new-labs.png the border is at x=925 and x=1278,
                  y=62 and y=965. The 1px right margin is the driver's
                  1281px #mainUI overhanging the viewport, same as the
                  header's (css/shell.css). The top is 2px because the
                  content band's own top rule at y=61 runs on above the
                  wrapper in the capture, and this pane starts at y=61.
     .labFrame  = the iframe (`.frame { width: 99.7% }`, itd-inline.css:440
                  — 351px here, leaving the 1px white strip at x=1277) and
                  its <body>: margin 20px 20px 20px 0, 12pt/1.4 text.
     #labBody   = .container, taken out of flow below the header block. */
#labsPane {
  flex: 1 1 30.2%; min-width: 0; min-height: 0;
  box-sizing: border-box; height: 100%; margin: 0 1px 0 0;
  border: 1px solid #000; border-top-width: 2px; background: #fff; overflow: hidden;
}
#labsPane[hidden] { display: none; }
html.white-on-black #labsPane {
  /* itd-inline.css:2490 — only top and bottom are drawn in this theme. */
  background: #000; border-color: var(--dark-accent) transparent;
}

/* The driver ships no box-sizing reset; this project does (css/shell.css:1).
   Undo it inside the panel so the driver's widths and paddings mean what
   they meant there. Buttons and checkboxes are border-box in every browser's
   own stylesheet, so they stay that way; so does #labsPane itself, whose
   height has to include its border to end where the capture's does. */
#labsPane * { box-sizing: content-box; }
#labsPane button, #labsPane input[type="checkbox"] { box-sizing: border-box; }

.labFrame {
  position: relative; width: 99.7%; height: 100%; overflow: hidden;
  container: labs / inline-size;
  background: #fff; color: #000; text-align: left;
  font: normal normal normal 12pt/1.4 "Arial Unicode MS", Arial_for_NBME, Arial, Helvetica, "Lucida Sans Unicode", "Trebuchet MS", sans-serif;
}
html.white-on-black .labFrame { background: #000; color: #fff; }

.toppanel { margin: 20px 20px 0 0; background: #fff; }
html.white-on-black .toppanel { background: transparent; }
.labCloseRow { text-align: right; padding-bottom: 25px; }
#labsClose {
  position: absolute; top: 6px; right: 15px; z-index: 997;
  width: 25px; height: 25px; margin: 0; padding: 1px;
  border: 1px solid var(--chrome); border-radius: 5px;
  background: var(--chrome); color: #fff; cursor: pointer;
}
#labsClose svg { display: block; width: 21px; height: 21px; fill: #fff; }
#labsClose:hover svg { fill: var(--chrome); stroke: #fff; }
#labsClose:focus { outline: 2px dotted var(--chrome); outline-offset: 2px; }
html.white-on-black #labsClose { background: #000; border-color: #fff; }
html.white-on-black #labsClose svg { fill: #fff; }
html.white-on-black #labsClose:focus { outline-color: #fff; }

.search-wrapper { position: relative; padding: 10px; width: 200px; margin: 0; display: inline-block; }
/* The captured input carries no class, so the stylesheet's `.search-box`
   pill never applies: it is the browser's own text field, untouched. Revert
   to exactly that rather than restating it. */
#labSearch { all: revert; }
/* reference/itd-panels.txt — html.white-on-black #searchText. */
html.white-on-black #labSearch { background: #000; color: #fff; border: 1px solid #fff; }
.close-icon {
  position: absolute; padding: 10px; margin-left: -30px;
  border: 1px solid transparent; background-color: transparent;
  display: none; vertical-align: middle; outline: 0; cursor: pointer;
}
.close-icon:after {
  content: "X"; display: block; width: 15px; height: 15px;
  position: absolute; z-index: 1; top: 2px; bottom: 0; margin: auto; padding: 2px;
  border-radius: 50%; text-align: center; color: #000;
  font-weight: normal; font-size: 12px; cursor: pointer;
}
#labsPane.hasSearch .close-icon { display: inline-block; }
html.white-on-black .close-icon:after { color: #fff; }

/* The frame's stylesheet makes this a block at `max-width: 380px` — which is
   the frame's own width, so a container query here, not a media query. At
   1280 the frame is 351px and the checkbox sits on its own line. */
#labSI { white-space: nowrap; display: block; }
#labSIBox { all: revert; }
#labSI label { font-size: .7em; }
#labBody { height: calc(100% - 150px); }
@container labs (min-width: 380.01px) {
  #labSI { display: inline; }
  #labBody { height: calc(100% - 129px); }
}


/* ---- modals (js/modals.js): End Block, Lock, Time Expired, Help ----
   #modal itself inherits .dialog's shared background/border/radius
   (measured in Task 12, cited at the top of this file) — no separate
   chrome invented here. See js/modals.js's own file-level comment for why
   these all share ONE visual system instead of the driver's actual
   two-system split. */
#modal {
  top: 50%; left: 50%; transform: translate(-50%, -50%); max-width: 420px;
}
#modal .modal-dialog { padding: 14px 16px; }
/* reference/itd-inline.css:1806 — `#endblock #alerttext p{text-align:
   center}` (End Block/Time Expired only; Lock/Help read as left-aligned
   body copy, which is what the shared `.modal-dialog p` rule above
   already gives them for free). */
#modal.center .modal-dialog p { text-align: center; }

/* Handle colours, all independently measured per kind (see js/modals.js):
   reference/itd-inline.css:1891/1894 (--dialog-head, End Block/complete),
   :1890 (--alert, End Block/incomplete), :2133 (var(--chrome), Help). Lock
   gets no headClass and keeps the plain, uncoloured handle Notes/
   Calculator already use — no citation for a Lock-screen handle exists. */
#modal.head-complete .handle  { background: var(--dialog-head); color: #fff; }
#modal.head-incomplete .handle { background: var(--alert); color: #fff; }
#modal.head-help .handle      { background: var(--chrome); color: #fff; }
html.white-on-black #modal.head-complete .handle,
html.white-on-black #modal.head-incomplete .handle,
html.white-on-black #modal.head-help .handle { color: #fff; }

#modal .modalButtons { display: flex; gap: 10px; justify-content: center; margin-top: 4px; }
/* Close/Unlock/OK — same bordered-chrome button already measured for
   Notes' Save/Delete (reference/itd-inline.css:544-557, css/panels.css's
   #notes .saveandclose above), reused rather than inventing a third
   button style. */
#modal .modalButtons button {
  box-sizing: border-box; padding: 5px 14px; cursor: pointer;
  background-color: #f0f0f0; color: #000;
  font-family: var(--font-button); font-size: 13.3333px; font-weight: 700;
  border: 1px solid var(--chrome); border-radius: 5px;
}
#modal .modalButtons button:not(:disabled):hover { background-color: lightgray; }
#modal .modalButtons button:disabled { cursor: wait; opacity: .72; }
#modal .modalSubmitError {
  margin: 10px 0 6px;
  color: #8b0000;
  font-weight: 700;
  text-align: center;
}
html.white-on-black #modal .modalSubmitError { color: #ff9b9b; }
/* Yes/No confirm gradients — borrowed, as disclosed in js/modals.js, from
   the driver's alert-family styling for these exact buttons:
   reference/itd-inline.css:1792 (Yes, blue) / :1797 (Yes:hover) / :1800
   (No/"remain in block", brown-orange) / :1802 (No:hover). */
#modal .yesBtn { background: linear-gradient(#5490CC, #004976); color: #fff; border: none; }
#modal .yesBtn:hover { background: linear-gradient(#004976, #5490CC); }
#modal .noBtn  { background: linear-gradient(#804600, #ad5f01); color: #fff; border: none; }
#modal .noBtn:hover  { background: linear-gradient(#ad5f01, #804600); }
html.white-on-black #modal .modalButtons button:not(.yesBtn):not(.noBtn) {
  background-color: #000; color: #fff;
}
html.white-on-black #modal .modalButtons button:not(.yesBtn):not(.noBtn):hover {
  background-color: #222;
}

/* ---- unauthorizedbreak: fullscreen, not `.dialog` at all ----
   reference/itd-inline.css:1871-1880 (`#unauthorizedbreak{width:100%;
   height:100%;top:0;left:0;margin:0}`, header/handle hidden, h1 18pt
   bold), :1880-1886 (`div[data-hasbtns]{background-color:red;height:100%;
   width:100%;color:white}`), :1902-1904 (`#alerttext{text-align:center;
   margin-top:25vh}`). Verified against reference/step1-new-break.png. */
#modal.fullscreen {
  position: fixed; inset: 0; top: 0; left: 0; transform: none;
  width: 100%; height: 100%; max-width: none;
  background: red; border: none; border-radius: 0; box-shadow: none;
  color: #fff; z-index: 2000;
}
#modal.fullscreen .modal-dialog { text-align: center; margin-top: 25vh; padding: 0; }
#modal.fullscreen .breakTitle { font-size: 18pt; font-weight: bold; margin: 0 0 10px; }
#modal.fullscreen .breakWarn { margin: 0 0 8px; letter-spacing: .05em; }
#modal.fullscreen .modalButtons button {
  background-color: #fff; color: #000; border: 3px solid #000;
}
#modal.fullscreen .modalButtons button:hover { background-color: #eee; }

/* End-of-block replacement content (js/modals.js's endBlock()). Not
   measured against any reference — the real driver navigates to the NEXT
   block instead of showing a static page, which this single-block replica
   has no equivalent of. */
/* The ended-block panel COVERS the item frame rather than replacing the
   container's contents — see js/modals.js. #ElementDisplayFrameID sets an
   explicit display, so [hidden] needs help to win against it. */
#blockEnded { padding: 60px; text-align: center; flex: 1 1 auto; }
/* The panel can be taller than the window now that it carries the answer key.
   Its container is a flex item that would otherwise grow with it and push the
   footer off the screen, so while the panel is up the container scrolls. */
#MainContainerID:has(> #blockEnded) { min-height: 0; overflow: auto; }

/* The answer key under the score (js/modals.js's answerKeyMarkup()). Like the
   panel it sits in, it has no counterpart in the driver. A 40-question block
   makes 40 rows, which is why the container above scrolls. */
.answerKey {
  margin: 26px auto 30px; border-collapse: collapse; text-align: left;
  max-width: 880px; font-size: .94em;
}
.answerKey caption { font-weight: bold; padding-bottom: 8px; }
.answerKey th, .answerKey td {
  padding: 5px 16px; border-bottom: 1px solid #bbc; vertical-align: top;
}
.answerKey thead th { border-bottom: 1px solid var(--chrome); white-space: nowrap; }
.answerKey tbody th { text-align: right; font-weight: normal; }
/* Room for an option's wording, so a two-word answer is not broken in two. */
.answerKey td:nth-child(2), .answerKey td:nth-child(3) { min-width: 11em; }
.answerKey td:last-child { white-space: nowrap; }
.answerKey .keyNone { font-style: italic; }
.answerKey .keyWrong td:last-child { font-weight: bold; }
html.white-on-black .answerKey th, html.white-on-black .answerKey td { border-bottom-color: #fff; }
#ElementDisplayFrameID[hidden] { display: none; }

/* The tab strip is the frame's own <ul>, not the outer driver's larger
   Exhibit Tabs component. The 4px gaps are the whitespace between the
   inline-flex items, as in the capture — js/labs.js emits it. */
#labTabs {
  list-style: none; color: #000; display: block; white-space: nowrap;
  margin: 16px 0 0; padding: 0 0 0 9px;
}
.labTab {
  font-size: .7em; display: inline-flex; border: 1px solid #bbc; border-collapse: collapse;
  padding: 2px 5px; border-top-left-radius: 5px; border-top-right-radius: 5px; cursor: pointer;
}
/* Bold, per the stylesheet — and drawn regular wherever "Arial Unicode MS"
   is installed, because that family has no bold face. The capture shows the
   regular weight for exactly that reason. */
.labTab.active { font-weight: bold; background-color: #d7dced; }
html.white-on-black .labTab { background-color: #000; color: #fff; }
html.white-on-black .labTab.active { background-color: #fff; color: #000; }

/* `.container { position: fixed; width: 100%; overflow: auto }` in the frame:
   out of flow, so it starts where the header block ends but spans the full
   frame width, past the body's 20px right margin. */
#labBody { position: absolute; left: 0; width: 100%; overflow: auto; background-color: #d7dced; }
html.white-on-black #labBody { background-color: transparent; }

/* The capture was taken with classic scrollbars, which is also what the
   testing-centre workstations draw: a 15px gutter that narrows the table to
   336px and decides where every value wraps. An overlay scrollbar (the macOS
   default) would give the table those 15px back and re-wrap it, so the
   gutter is drawn here rather than left to the OS. Colours and insets read
   off reference/step1-new-labs.png at x=1262..1276. */
#labBody::-webkit-scrollbar { width: 15px; height: 15px; }
#labBody::-webkit-scrollbar-track {
  background: #fafafa; border-left: 1px solid #e8e8e8; border-right: 1px solid #ededed;
}
#labBody::-webkit-scrollbar-thumb {
  background: #c1c1c1; background-clip: padding-box;
  border: solid transparent; border-width: 3px 3px 3px 4px; border-radius: 7px;
}
html.white-on-black #labBody::-webkit-scrollbar-track { background: #2b2b2b; border-color: #3d3d3d; }
html.white-on-black #labBody::-webkit-scrollbar-thumb { background-color: #6b6b6b; }

/* No width: the driver's table is shrink-to-fit and only fills the frame
   because its longest values do. cellspacing/cellpadding come from the
   table's own attributes (data/labvalues.js) — only Serum has them, so the
   other three tabs keep the browser's 2px cell spacing, as in the driver. */
#labTable { background-color: #d7dced; border-collapse: separate; }
/* No dark-theme background of its own in the frame (the rule is scoped to
   html.default), so the black page shows through. */
html.white-on-black #labTable { background-color: transparent; }

#labTable td { padding: 2px; }
.table-cell-header  { font-size: .7em; font-weight: bold; width: 200px; vertical-align: top; padding-left: 3px; }
.table-cell-header2 { font-size: .7em; font-weight: bold; text-align: center; vertical-align: top; }
.table-cell-header3 { font-size: .7em; font-weight: bold; text-align: center; vertical-align: top; }
.table-cell-1 { font-size: .7em; width: 200px; vertical-align: top; padding-left: 3px; }
.table-cell-2 { font-size: .7em; vertical-align: top; }
.table-cell-3 { font-size: .7em; vertical-align: top; }
/* These two must out-rank `#labTable td { padding: 2px }` above the way they
   do in the driver, where that rule is a bare `td` — at plain class
   specificity the indent was silently overridden and every sub-row sat
   flush left. */
#labTable .table-cell-1.table-cell-1 { padding-left: 3px; }
#labTable .table-cell-header.table-cell-header { padding-left: 3px; }
#labTable .table-cell-1-indent1,
#labTable .table-cell-2-indent1 { font-size: .7em; padding-left: 20px; vertical-align: top; }
#labTable td { border-top: 1px solid #bbc; }
html.white-on-black #labTable td { border-top-color: #fff; }

/* The SI column is present in every row but hidden until #intervals is
   checked. */
#labTable tr td:nth-child(3), #labTable tr th:nth-child(3) { display: none; }
#labTable tr td:nth-child(3).isVisible,
#labTable tr th:nth-child(3).isVisible { display: block; }

/* Ionic charges and exponents: the driver's inline style, verbatim
   (`font-size:7pt;left:1pt;font-family:Arial, Verdana, 'MS Sans Serif';
   position:relative;top:-3pt`, +3pt for subscripts). */
.labRaised, .labLowered {
  font-size: 7pt; left: 1pt; font-family: Arial, Verdana, 'MS Sans Serif'; position: relative;
}
.labRaised { top: -3pt; }
.labLowered { top: 3pt; }

/* Search marks matches in place; it never removes rows. */
.searched { text-decoration: yellow underline; text-decoration-thickness: 4px; }