/* ClipSAT Calculator — app chrome (site tokens) + two device skins
   (TI-84 Plus CE / Casio fx-991 ClassWiz). See public/js/calculator.js for
   the engine + UI this styles. Hand-maintained directly (not part of the
   src/styles/main.css → build.js minify pipeline) — a self-contained,
   opt-in feature stylesheet, same pattern as the site treating
   cloud-sync.js/teacher-view.js as their own passthrough files. */

/* ── Floating launcher ──
   Bottom-LEFT deliberately, not bottom-right: the site's own "Ask Mr.
   Mohamed" chat FAB (main.css .chat-fab, z-index 9998, plus its 384×564px
   .chat-panel when open) already owns the entire bottom-right corner on
   every page — a launcher placed there would sit underneath it, unclickable,
   confirmed live (Playwright: chatFab "intercepts pointer events" at that
   spot). Bottom-left is otherwise unused (the formula-sidebar toggle is a
   vertically-centered right-edge tab, not a bottom corner). */
.cc-launcher-btn {
  position: fixed;
  left: 18px;
  bottom: 18px;
  z-index: 195; /* below the whiteboard toolbar (200) and modals, above the rail (180) */
  width: 52px;
  height: 52px;
  border-radius: 50%;
  border: none;
  background: var(--indigo-500, #2B5BA8);
  color: #fff;
  font-size: 1.5rem;
  line-height: 1;
  cursor: pointer;
  box-shadow: 0 4px 14px rgba(20, 30, 50, .28);
  display: flex;
  align-items: center;
  justify-content: center;
}
.cc-launcher-btn:hover { filter: brightness(1.08); }
/* Deliberately NOT flipped for body.rtl: the chat-fab itself doesn't mirror
   in RTL either (still bottom-right, main.css has no such override) — this
   launcher needs to stay wherever chat-fab isn't, in both directions. */

/* ── Modal wrapper ── */
.cc-modal-overlay {
  display: none;
  position: fixed;
  inset: 0;
  z-index: 500;
  background: rgba(10, 14, 24, .55);
  align-items: center;
  justify-content: center;
  padding: 16px;
}
.cc-modal-overlay.show { display: flex; }
/* Width and height both hug their content (fit-content) instead of a
   fixed box: calculator.js's fitKeypad() computes a key size that makes
   the whole calculator fit the viewport and sets .cc-app's own
   max-width from it, so the box should just wrap that — a fixed box
   size here would either leave dead space around a calculator sized
   for a small screen, or reintroduce it on a large one. max-height is
   a safety net only (fitKeypad() aims to never need it): if some edge
   case still overflows it, the box scrolls instead of clipping. */
.cc-modal-box {
  width: fit-content;
  max-width: 96vw;
  max-height: 94vh;
  overflow-y: auto;
  overflow-x: hidden;
  border-radius: var(--r-lg, 14px);
  box-shadow: 0 20px 60px rgba(0, 0, 0, .35);
}

/* ── App shell (shared by modal + standalone mount) ──
   max-width is set from JS (calculator.js's fitKeypad(), called on
   mount, on window resize, and whenever the modal opens) rather than a
   fixed value here — the right size for a phone, a tablet, a laptop,
   and a classroom smartboard are all different, and none of them is a
   single CSS breakpoint. The 420px below is only the pre-JS/first-paint
   fallback. Centering + hugging the keypad's own width (not stretching
   to fill whatever wide container it's dropped into) is what keeps the
   skin's fixed body color from showing as bare, unused bars down both
   sides — same reasoning as a real handheld's fixed-size case. */
.cc-app {
  /* The site's own reset already sets this globally, but calculator.css
     is meant to be self-contained (loaded standalone too) — and
     fitNonCalcScreen()/fitKeypad() in calculator.js set max-height/
     max-width expecting them to bound the OUTER box (padding + border
     included, same as the width budget already adds bodyPad/appPad/
     appBorder into its total) rather than just the content box. */
  box-sizing: border-box;
  position: relative; /* anchors .cc-overlay-menu (MATH/CALC popups) to the calculator itself, not the page */
  display: flex;
  flex-direction: column;
  width: 100%;
  max-width: 420px;
  margin: 0 auto;
  font-family: var(--sans, system-ui, sans-serif);
  direction: ltr; /* a calculator keypad stays LTR even in Arabic locale/RTL pages — matches every real device */
  background: var(--surface-1, #fff);
  border: 1px solid var(--border, #DDE2EC);
  border-radius: var(--r-lg, 14px);
  overflow: hidden;
}

/* Two fixed rows — tabs, then controls — rather than one flex-wrap row
   that reflowed unpredictably (tabs and controls interleaving,
   wrapping mid-group) depending on exactly how much width happened to
   be left over. A deterministic two-row shape reads as designed at
   every size instead of "scrambled".
   Colors below are the pre-skin fallback only — every one of .cc-app/
   .cc-topbar/.cc-tab/.cc-angle-btn/.cc-skin-btn/.cc-close-btn is
   recolored per skin further down (the "TI-84 Plus CE skin"/"Casio
   fx-991 ClassWiz skin" sections), same reasoning as the screen itself:
   a real calculator's case and keys don't restyle themselves when the
   room lights change, so the device chrome stays fixed regardless of
   the SITE's light/dark theme — only the surrounding page does that. */
.cc-topbar {
  display: flex;
  flex-direction: column;
  gap: 4px;
  padding: 6px 8px;
  background: var(--surface-2, #F0F3F8);
  border-bottom: 1px solid var(--border, #DDE2EC);
}
.cc-tabs { display: flex; gap: 4px; flex-wrap: wrap; }
.cc-topbar-controls { display: flex; align-items: center; justify-content: space-between; gap: 6px; flex-wrap: wrap; }
/* Tabs/angle/skin buttons scale with --cc-key too (clamped, not
   linearly — they're short labels, not keycap digits, so they don't
   need to grow or shrink as aggressively as the keypad does): on a
   phone-sized fit, smaller controls wrap into fewer rows, leaving more
   of fitKeypad()'s height budget for the keys themselves; on a
   smartboard-sized one, they scale up to match rather than staying
   tiny next to a much bigger keypad. */
.cc-tab {
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-1, #fff);
  color: var(--text-2, #4F5C6E);
  border-radius: 8px;
  padding: clamp(3px, calc(var(--cc-key, 64px) * .06), 6px) clamp(5px, calc(var(--cc-key, 64px) * .11), 10px);
  font-size: clamp(.68rem, calc(var(--cc-key, 64px) * .17), .95rem);
  cursor: pointer;
}
.cc-tab.on { background: var(--indigo-500, #2B5BA8); border-color: var(--indigo-500, #2B5BA8); color: #fff; }
.cc-angle-btn {
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-1, #fff);
  color: var(--text-1, #0D1826);
  border-radius: 8px;
  padding: clamp(3px, calc(var(--cc-key, 64px) * .06), 6px) clamp(4px, calc(var(--cc-key, 64px) * .09), 8px);
  font-size: clamp(.62rem, calc(var(--cc-key, 64px) * .15), .8rem);
  font-family: var(--mono, monospace);
  cursor: pointer;
  min-width: clamp(32px, calc(var(--cc-key, 64px) * .55), 48px);
}
.cc-skintoggle { display: flex; gap: 4px; }
.cc-skin-btn {
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-1, #fff);
  color: var(--text-2, #4F5C6E);
  border-radius: 8px;
  padding: clamp(3px, calc(var(--cc-key, 64px) * .06), 6px) clamp(4px, calc(var(--cc-key, 64px) * .09), 8px);
  font-size: clamp(.62rem, calc(var(--cc-key, 64px) * .15), .78rem);
  cursor: pointer;
  white-space: nowrap;
}
.cc-skin-btn.on { background: var(--text-1, #0D1826); border-color: var(--text-1, #0D1826); color: var(--surface-1, #fff); }
.cc-close-btn {
  border: none;
  background: transparent;
  color: var(--text-2, #4F5C6E);
  font-size: 1rem;
  cursor: pointer;
  padding: 4px 8px;
}

/* min-height:0 overrides the flex default (min-height:auto, which
   refuses to shrink a flex item below its content's natural size) —
   without it, capping .cc-app's height from JS (fitKeypad()'s Calc-
   screen math, or fitNonCalcScreen() for Graph/Matrix/Solver below)
   would have no effect: .cc-body would just keep growing to fit its
   content instead of respecting the cap and scrolling internally. */
.cc-body { flex: 1; min-height: 0; overflow: auto; padding: 10px; }

/* ── Calc screen ──
   Portrait (default): screen (history + input) stacks ABOVE the
   keypad, like every real handheld — the keypad itself is never
   reshuffled between orientations, only the screen's position relative
   to it changes. Landscape (.cc-app.landscape, toggled by
   calculator.js's fitKeypad() from the real viewport, not a CSS
   breakpoint guessing at it independently): the screen moves BESIDE
   the keypad instead. That's not just cosmetic — stacking on a wide-
   but-short screen (any laptop/desktop is exactly this shape) was
   forcing the keypad to share its already-scarce vertical room with a
   screen block above it, shrinking keys far more than the width ever
   needed to. Side by side, the keypad's available height is just the
   topbar's, so keys can be their full size, and the screen column gets
   real width instead of being squeezed to the keypad's minimum. */
.cc-calc { display: flex; flex-direction: column; gap: 8px; height: 100%; }
/* .cc-screen IS the physical screen now — one continuous bordered/
   backgrounded LCD panel (background/border/color set per skin below),
   holding history, the natural-math preview, and the entry line as
   plain internal sections with only thin dividers between them, not
   three separate boxes with gaps — a real calculator has exactly one
   screen, not a stack of them. */
.cc-screen {
  display: flex;
  flex-direction: column;
  background: var(--cc-screen-bg, #fff);
  border: 1px solid var(--border, #DDE2EC);
  border-radius: 8px;
  overflow: hidden;
}
.cc-app.landscape .cc-calc { flex-direction: row; align-items: stretch; }
.cc-app.landscape .cc-screen { flex: 0 0 auto; } /* width set by fitKeypad() */
.cc-app.landscape .cc-keypad { flex: 1 1 auto; margin-top: 0; }
.cc-app.landscape .cc-history { flex: 1; max-height: none; } /* the screen column's spare height goes to history, not dead space */
/* History + input's own footprint counts against fitKeypad()'s height
   budget just like the keypad does — trimmed down from the original
   90px/160px/10px-padding so a short viewport (a phone in landscape, a
   split-screen window) has more room left for the keys themselves. */
.cc-history {
  min-height: 54px;
  max-height: 120px;
  overflow-y: auto;
  font-family: var(--mono, monospace);
  font-size: 1.05rem;
  padding: 6px 8px;
  border-bottom: 1px dashed currentColor;
  opacity: .92; /* history reads a hair quieter than the live entry line below it, same idea as a real screen's scrolled-up lines */
}
.cc-hist-row { padding: 3px 0; border-bottom: 1px dashed currentColor; opacity: .5; }
.cc-hist-row:last-child { border-bottom: none; }
.cc-hist-expr {
  font-family: var(--serif-body, Georgia, 'Times New Roman', serif);
  max-width: 100%;
  overflow-x: auto;
}
.cc-hist-res { font-weight: 600; text-align: right; }

/* The entry area — a read-only natural-math preview line (.cc-preview)
   on top of the real editable text line (.cc-inputrow > .cc-expr-input),
   like a MathPrint/CAS display actually shows: typeset math above, a
   plain edit cursor below. Both are plain sections of .cc-screen now —
   no background/border of their own. */
.cc-entry-lcd { display: flex; flex-direction: column; }
.cc-preview {
  min-height: 1.5em;
  max-height: 3rem;
  overflow: auto;
  padding: 5px 10px 3px;
  font-family: var(--serif-body, Georgia, 'Times New Roman', serif);
  font-size: 1.15rem;
  line-height: 1.4;
  border-bottom: 1px dashed currentColor;
  opacity: .8;
}
.cc-preview.empty { opacity: .35; }
.cc-inputrow { display: flex; }
.cc-expr-input {
  flex: 1;
  font-family: var(--mono, monospace);
  font-size: 1.35rem;
  padding: 7px 10px;
  border: none;
  background: transparent;
  color: inherit;
}

/* ── Natural ("CAS style") math rendering ──
   Read-only re-typesetting of the same expression string the plain
   .cc-expr-input holds — used for .cc-preview above and for each
   .cc-hist-expr entry. See mRender()/mathPreviewFrag() in calculator.js
   (PART 4b) for how these get built; nothing here is interactive. */
.cc-app sup, .cc-app sub { font-size: .68em; line-height: 0; }
.cc-mvar { font-style: italic; }
.cc-mconst, .cc-mfn { font-style: normal; }
.cc-mplaceholder { opacity: .55; }
.cc-mfrac {
  display: inline-flex;
  flex-direction: column;
  align-items: center;
  vertical-align: middle;
  margin: 0 .14em;
  font-size: .88em;
  line-height: 1.15;
}
.cc-mfrac .cc-mnum { padding: 0 .15em .05em; border-bottom: 1.5px solid currentColor; }
.cc-mfrac .cc-mden { padding: .05em .15em 0; }
.cc-msqrt { display: inline-flex; align-items: flex-start; white-space: nowrap; }
.cc-msqrt-rad { font-size: 1.05em; transform: scaleY(1.1); margin-right: -.03em; }
.cc-msqrt-n { font-size: .6em; vertical-align: super; position: relative; top: -.25em; margin-right: -.2em; }
.cc-msqrt-content { border-top: 1.5px solid currentColor; padding: 0 .12em 0 .1em; margin-top: .12em; }
.cc-msup { font-size: .68em; vertical-align: super; line-height: 0; }
.cc-msub { font-size: .68em; vertical-align: sub; line-height: 0; }

/* .cc-key is shared by two very different things: the actual keypad
   grid buttons below (built by keyBtn()/insKey() into a .cc-keyrow) AND
   a bunch of unrelated action buttons elsewhere reusing the same class
   for its colors — the graph screen's Zoom In/Zoom Out/ZStandard, the
   matrix screen's A+B/det(A)/etc. ops row, the equation solver's mode
   tabs and Solve button. Only the FIRST group should be square with
   giant keycap text; naively making .cc-key itself square + huge-font
   turned every one of those other buttons into an oversized square with
   wrapped, overflowing text. So: shared chrome (colors, border, cursor)
   lives on bare .cc-key with a modest font bump; the square, big-text
   "physical key" treatment is scoped to .cc-keyrow .cc-key only. */
.cc-key {
  display: flex;
  align-items: center;
  justify-content: center;
  padding: 9px 12px;
  border-radius: 10px;
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-2, #F0F3F8);
  color: var(--text-1, #0D1826);
  font-size: 1.05rem;
  font-weight: 500;
  line-height: 1.2;
  cursor: pointer;
  font-family: var(--mono, monospace);
}
.cc-key:active { filter: brightness(.94); }

/* Keys are square by default (aspect-ratio:1 — the row's own column width
   sets the height too, so every ordinary key is a clean square touch
   target instead of the old short, wide bar). .cc-key.wide (currently
   just the "0" key, the standard wide-zero convention every phone/OS
   calculator uses) gets a 2:1 column + a matching 2/1 aspect-ratio, so
   it reads as two squares side by side at the SAME height as its
   neighbors.
   The key SIZE itself (.cc-keypad's width, in px) is set by
   calculator.js's fitKeypad() — computed from the real viewport so the
   whole calculator fits on one screen with no internal scrolling,
   whether that screen is a phone, a tablet, a laptop, or a classroom
   smartboard, rather than one fixed size with a handful of @media
   breakpoints in between. --cc-key (also set by fitKeypad(), one key's
   pixel size) drives face-text size here as a fraction of that — keys
   read as compact touch targets with LARGE, legible text on them, not
   big buttons with small print. The 64px fallback below is only the
   pre-JS/first-paint default. */
.cc-keypad { display: flex; flex-direction: column; gap: 4px; margin-top: 4px; }
/* minmax(0, 1fr), not bare 1fr: a plain `1fr` track has an implicit
   min-width of its content's min-content size, so a long label ("ENTER",
   "STO▸M") could force that one column wider than its 1/5 share —
   pushing the whole row past .cc-app's edge to be sliced off by its
   overflow:hidden. minmax(0, 1fr) caps every track at its fair share no
   matter what the label needs, so a too-long label wraps inside its own
   key instead of blowing out the grid. */
/* .cc-keyrow's own column count is set per-row from JS now (however many
   keys are actually in it — 3, 5, 6, whatever the real device has there)
   instead of a blanket 5 here; this is just the pre-JS fallback. */
.cc-keyrow { display: grid; grid-template-columns: repeat(5, minmax(0, 1fr)); gap: 4px; }
/* Keys are a fixed HEIGHT (not an aspect-ratio square) because rows no
   longer all have the same column count — a real keypad doesn't either
   (the fx-991EX's a-b/c…10ˣ row packs 6 keys into the same row height
   the 5-key rows above and below it use, so those 6 keys read narrower,
   not shorter). Squaring every key to ITS OWN column's width would make
   that 6-key row visibly shorter than its neighbors; a fixed height
   keeps every row reading as one continuous grid the way the real
   device does, and .cc-keyrow-cluster (the D-pad rows) sizes itself off
   the same variable so it lines up too. --cc-key (set by fitKeypad(),
   computed from the real viewport) is that height; the 64px fallback
   below is only the pre-JS/first-paint default. */
.cc-keyrow .cc-key {
  height: var(--cc-key, 64px);
  padding: 2px;
  font-size: calc(var(--cc-key, 64px) * .44);
  line-height: 1.05;
  text-align: center;
  overflow-wrap: anywhere; /* belt-and-suspenders: a label minmax(0,1fr) still can't shrink enough for (e.g. a narrow phone) wraps instead of overflowing its key */
  position: relative; /* anchors .cc-key-shiftlabel/.cc-key-alphalabel below */
}
/* Longer labels ("CLEAR", "ENTER", "STO▸M", …) at a smaller face size so
   they read on one line instead of an ugly mid-word wrap — see keyBtn()
   in calculator.js, which adds this class by label length. */
.cc-keyrow .cc-key.cc-key-sm { font-size: calc(var(--cc-key, 64px) * .23); }
.cc-key.fn { background: var(--cc-fn-bg, #E4E9F5); color: var(--cc-fn-color, #1E3A6E); }
.cc-key.op { background: var(--cc-op-bg, #FFDFA6); color: var(--cc-op-color, #7A4B00); font-weight: 600; }
.cc-key.enter { background: var(--indigo-500, #2B5BA8); border-color: var(--indigo-500, #2B5BA8); color: #fff; }
.cc-key.noop { visibility: hidden; pointer-events: none; }

/* ── D-pad + its cluster row (2ND/SHIFT+ALPHA … MENU/ON) ──
   .cc-keyrow-cluster sits in .cc-keypad exactly like a plain .cc-keyrow
   (fitKeypad() in calculator.js counts it as 2 key-heights tall, since
   its own two stacked rows share the D-pad's height) but is a flex row
   of up to 3 parts — a keys column, the circular D-pad, and (Casio
   only) a second keys column on the D-pad's other side — instead of a
   single grid. */
.cc-keyrow-cluster { display: flex; gap: 4px; align-items: stretch; }
.cc-cluster-keys { flex: 1 1 0; min-width: 0; display: flex; flex-direction: column; gap: 4px; }
.cc-cluster-keys .cc-keyrow { flex: 1; }
.cc-dpad {
  flex: 0 0 auto;
  position: relative;
  height: calc(var(--cc-key, 64px) * 2 + 4px); /* 2 stacked key-rows + the gap between them */
  aspect-ratio: 1 / 1;
  border-radius: 50%;
  background: linear-gradient(155deg, #f4f4f2, #a8adb2);
  border: 1px solid #8b9096;
  box-shadow: 0 2px 4px rgba(0, 0, 0, .35), inset 0 1px 2px rgba(255, 255, 255, .8);
}
.cc-dp {
  position: absolute;
  border: none;
  background: transparent;
  color: #33363b;
  font-size: calc(var(--cc-key, 64px) * .26);
  line-height: 1;
  cursor: pointer;
  padding: 0;
}
.cc-dp:active { color: #000; }
.cc-dp-up { top: 6%; left: 50%; transform: translateX(-50%); }
.cc-dp-down { bottom: 6%; left: 50%; transform: translateX(-50%); }
.cc-dp-left { left: 6%; top: 50%; transform: translateY(-50%); }
.cc-dp-right { right: 6%; top: 50%; transform: translateY(-50%); }
.cc-dp-center {
  position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%);
  width: 34%; height: 34%; border-radius: 50%;
  background: linear-gradient(155deg, #e2e4e2, #b7bcc0);
  box-shadow: inset 0 1px 2px rgba(0, 0, 0, .25);
  border: 1px solid #8b9096;
  padding: 0;
}
button.cc-dp-center { cursor: pointer; } /* the fx-991EX's D-pad has a clickable center (OK/=); the TI-84's is a plain <div>, not a <button> — see buildDpad() */

/* ── 2ND/SHIFT + ALPHA modifier keys and their shift/alpha legends ──
   Real per-skin colors below (TI: 2ND blue, ALPHA green; Casio: SHIFT
   yellow, ALPHA red) — see modKey()/buildModKeys() in calculator.js.
   .active is the "armed, waiting for the next key" lit-up state. */
.cc-key.mod { font-weight: 700; }
.cc-key.mod.active { box-shadow: 0 0 0 2px #fff inset; filter: brightness(1.15); }
/* Capped to a bit under half the key's width (not just left/right:3px
   with nothing else) and allowed to wrap onto a 2nd short line, so a
   longer legend ("RECALL", "catalog", "MATRIX") wraps within its own
   corner instead of overflowing past the key's edge or running into
   the other corner's label — both were happening before ("REGALL"
   overlapping the STO key's own face). */
.cc-key-shiftlabel,
.cc-key-alphalabel {
  position: absolute;
  top: 2px;
  max-width: calc(50% - 5px);
  font-size: calc(var(--cc-key, 64px) * .13);
  font-weight: 700;
  line-height: 1.05;
  overflow-wrap: break-word;
  pointer-events: none;
}
.cc-key-shiftlabel { left: 3px; text-align: left; }
.cc-key-alphalabel { right: 3px; text-align: right; }
/* Selected-state for a .cc-key used as a mode toggle (the equation solver's
   mode row) rather than a one-shot action — a plain .fn key otherwise has
   no visual "currently selected" state at all. */
.cc-key.fn.on { background: var(--indigo-500, #2B5BA8); border-color: var(--indigo-500, #2B5BA8); color: #fff; }

/* TI-84 Plus CE skin — matched to the real device photo: a rose-gold
   case, a near-black bezel/keyboard faceplate, white number keys, and
   near-black function/operator keys with light text (the real unit's
   sin/cos/x²/÷/× etc. are all dark keys with white print — only the
   number pad and ENTER read as visually distinct). Operators keep a
   warm amber glyph color (not literally photo-accurate — the real keys
   are plain white-on-black like the function keys — kept anyway so
   +/−/×/÷ stay a glance easier to find, same reasoning as the original
   palette this replaces). */
.skin-ti84 {
  --cc-screen-bg: #F4F1E7;
  padding: 6px; /* lets the case color show as a real bezel around the topbar/body, not just a 1px edge — kept modest so the extreme landscape-phone floor (fitKeypad()'s appPad) still fits with no scroll */
  background: linear-gradient(155deg, #e6bd94 0%, #d1a077 45%, #b17e57 100%);
  border-color: #8a6242;
}
.skin-ti84 .cc-topbar { background: #14161b; border-bottom-color: #0a0b0e; border-radius: 8px 8px 0 0; }
.skin-ti84 .cc-tab { background: #20232b; border-color: #0a0b0e; color: #b9c2d6; }
.skin-ti84 .cc-tab.on { background: #2f6fed; border-color: #2f6fed; color: #fff; }
.skin-ti84 .cc-angle-btn { background: #20232b; border-color: #0a0b0e; color: #e7ebf5; }
.skin-ti84 .cc-skin-btn { background: #20232b; border-color: #0a0b0e; color: #b9c2d6; }
.skin-ti84 .cc-skin-btn.on { background: #e7ebf5; border-color: #e7ebf5; color: #14161b; }
.skin-ti84 .cc-close-btn { color: #b9c2d6; }
.skin-ti84 .cc-body { background: #101217; border-radius: 0 0 8px 8px; } /* the dark faceplate the screen + every key sit on */
.skin-ti84 .cc-key { background: #F5F3EE; color: #16171C; border-color: #CFC9BA; } /* the number pad — white keys, black digits */
.skin-ti84 .cc-key.fn { background: #1C1E24; color: #F4F6FB; border-color: #0D0E12; }
.skin-ti84 .cc-key.op { background: #1C1E24; color: #FFCF6B; border-color: #0D0E12; }
.skin-ti84 .cc-key.enter { background: #1A7A43; border-color: #145C33; color: #fff; }
/* The screen itself (entry panel + history) is a fixed off-white LCD —
   the CE's actual color screen, not the older monochrome-green look —
   its text color must stay fixed dark ink too, NOT the site's --text-1
   (which flips to near-white in dark mode and would put pale text on a
   pale screen, unreadable in either theme). */
.skin-ti84 .cc-screen { background: #F4F1E7; color: #202020; border-color: #2A2D35; }
.skin-ti84 .cc-expr-input::placeholder { color: #7a7568; opacity: 1; }
.skin-ti84 .cc-hist-expr { color: #55524a; }
.skin-ti84 .cc-hist-res { color: #14151a; }
.skin-ti84 .cc-yeditor,
.skin-ti84 .cc-winrow,
.skin-ti84 .cc-mat-box,
.skin-ti84 .cc-eqn-modes { color: #e7ebf5; }
.skin-ti84 .cc-mat-title { color: #9db8ff; }
.skin-ti84 .cc-key.fn.on { background: #FFCF6B; color: #1C1E24; } /* equation-solver mode selector's "currently selected" state */
.skin-ti84 .cc-key.mod-shift { background: #2f6fed; color: #fff; border-color: #1f4fbd; }
.skin-ti84 .cc-key.mod-alpha { background: #1f9d55; color: #fff; border-color: #157a41; }
.skin-ti84 .cc-key-shiftlabel { color: #6fa8ff; } /* 2ND's own blue, printed on the near-black function keys */

/* Casio fx-991EX ClassWiz skin — matched to the real device photo: a
   silver/brushed-aluminum case, white number keys, and — the specific
   ask this palette is built around — function keys (√, x², sin, log,
   nCr, …) printed in red, the same color the real unit prints its
   SHIFT-reached functions in. DEL/AC get their own blue accent (see
   'clr' in buildCasioKeypad()); the remaining "op" keys (parens,
   +−×÷, comma) stay plain white/black like the real device's ordinary
   keys — this replaces the previous pale-blue treatment. */
.skin-casio {
  --cc-screen-bg: #1b1f19;
  padding: 6px; /* lets the case color show as a real bezel around the topbar/body, not just a 1px edge — kept modest so the extreme landscape-phone floor (fitKeypad()'s appPad) still fits with no scroll */
  background: linear-gradient(160deg, #f2f3f0 0%, #dde0da 50%, #c5c9c0 100%);
  border-color: #9aa096;
}
.skin-casio .cc-topbar { background: #e6e8e2; border-bottom-color: #b9beb2; border-radius: 8px 8px 0 0; }
.skin-casio .cc-tab { background: #fbfbf9; border-color: #b9beb2; color: #33362f; }
.skin-casio .cc-tab.on { background: #1E2A66; border-color: #1E2A66; color: #fff; }
.skin-casio .cc-angle-btn { background: #fbfbf9; border-color: #b9beb2; color: #22241f; }
.skin-casio .cc-skin-btn { background: #fbfbf9; border-color: #b9beb2; color: #33362f; }
.skin-casio .cc-skin-btn.on { background: #22241f; border-color: #22241f; color: #fff; }
.skin-casio .cc-close-btn { color: #33362f; }
.skin-casio .cc-body { background: #dadecf; border-radius: 0 0 8px 8px; }
.skin-casio .cc-key { background: #FBFBF9; color: #1B1E19; border-color: #C3C8BD; } /* the number pad — white keys, black digits */
/* Primary (unshifted) function labels are dark ink, same family as the
   digit/op keys — matches the real fx-991EX (sin/cos/log/etc. are
   printed in black on the key itself) and, just as importantly, gives
   the red SHIFT/ALPHA corner legends below actual contrast to read
   against. Making these red too (the previous color here) meant the
   primary label and both corner legends were all the identical red —
   nothing stood out, everything just read as a single red smear. */
.skin-casio .cc-key.fn { background: #F7F5F0; color: #24261F; border-color: #C3C8BD; font-weight: 700; }
.skin-casio .cc-key.op { background: #FBFBF9; color: #1B1E19; border-color: #C3C8BD; font-weight: 600; }
.skin-casio .cc-key.clr { background: #2F6FED; color: #fff; border-color: #1F4FBD; font-weight: 700; } /* DEL/AC — the real unit's blue keys */
.skin-casio .cc-key.enter { background: #1E2A66; border-color: #1E2A66; color: #fff; }
/* Same fixed-screen-color reasoning as the TI skin above, mirrored for the
   Casio's dark LCD: the input line was missing its own `color` and was
   falling back to the site's --text-1, which is dark ink in light mode —
   dark-on-dark, unreadable until the site theme happened to be dark. */
.skin-casio .cc-screen { background: #1b1f19; color: #CFE8CF; border-color: #C3C8BD; }
.skin-casio .cc-expr-input::placeholder { color: #6f9b72; opacity: 1; }
.skin-casio .cc-hist-expr { color: #9FD79F; }
.skin-casio .cc-hist-res { color: #E9FFE9; }
.skin-casio .cc-key.fn.on { background: #1E2A66; color: #fff; } /* equation-solver mode selector's "currently selected" state */
.skin-casio .cc-key.mod-shift { background: #F5C518; color: #1B1E19; border-color: #C9A100; } /* the real unit's yellow SHIFT key */
.skin-casio .cc-key.mod-alpha { background: #C41E3A; color: #fff; border-color: #9A1730; } /* the real unit's red ALPHA key */
.skin-casio .cc-key-shiftlabel { color: #C41E3A; } /* same red the real unit prints its shift-functions in */
.skin-casio .cc-key-alphalabel { color: #C41E3A; }

/* ── Graph screen ── */
.cc-graph { display: flex; flex-direction: column; gap: 8px; }
.cc-yeditor { display: flex; flex-direction: column; gap: 4px; }
.cc-yrow { display: flex; align-items: center; gap: 6px; }
.cc-yswatch { width: 10px; height: 10px; border-radius: 50%; flex-shrink: 0; }
.cc-ylabel { font-family: var(--mono, monospace); font-size: .92rem; color: var(--text-2, #4F5C6E); flex-shrink: 0; }
.cc-yrel {
  font-family: var(--mono, monospace);
  font-size: .95rem;
  font-weight: 600;
  padding: 4px 3px;
  border-radius: 6px;
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-1, #fff);
  color: var(--text-1, #0D1826);
  flex-shrink: 0;
}
.cc-graph-hint { font-size: .74rem; color: var(--text-2, #4F5C6E); }
.cc-yinput {
  flex: 1;
  font-family: var(--mono, monospace);
  font-size: 1rem;
  padding: 5px 8px;
  border-radius: 6px;
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-1, #fff);
  color: var(--text-1, #0D1826);
  min-width: 0;
}
.cc-winrow { display: flex; align-items: center; gap: 8px; flex-wrap: wrap; }
.cc-winfield { display: flex; align-items: center; font-size: .76rem; color: var(--text-2, #4F5C6E); gap: 3px; }
.cc-winfield input { width: 58px; padding: 4px 5px; border-radius: 6px; border: 1px solid var(--border, #DDE2EC); background: var(--surface-1, #fff); color: var(--text-1, #0D1826); }
.cc-canvaswrap { position: relative; border: 1px solid var(--border, #DDE2EC); border-radius: 8px; overflow: hidden; }
.cc-graph-canvas { display: block; width: 100%; touch-action: none; cursor: crosshair; }
.cc-trace-label {
  position: absolute; top: 6px; left: 8px;
  background: rgba(20, 24, 36, .78); color: #fff;
  font-family: var(--mono, monospace); font-size: .72rem;
  padding: 3px 7px; border-radius: 6px; pointer-events: none;
}

/* ── Matrix screen ── */
.cc-matrix { display: flex; flex-direction: column; gap: 10px; }
.cc-mat-editors { display: flex; gap: 12px; flex-wrap: wrap; }
.cc-mat-box { min-width: 150px; }
.cc-mat-title { font-size: .95rem; font-weight: 600; color: var(--text-1, #0D1826); margin-bottom: 4px; }
.cc-mat-dims { display: flex; align-items: center; gap: 4px; margin-bottom: 6px; }
.cc-mat-dims input { width: 40px; padding: 3px 4px; border-radius: 6px; border: 1px solid var(--border, #DDE2EC); }
.cc-mat-grid { display: grid; gap: 4px; }
.cc-mat-grid input { width: 44px; padding: 4px; border-radius: 6px; border: 1px solid var(--border, #DDE2EC); background: var(--surface-1, #fff); color: var(--text-1, #0D1826); }
.cc-mat-ops { display: flex; gap: 6px; flex-wrap: wrap; }
.cc-mat-result { font-family: var(--mono, monospace); font-size: .85rem; padding: 8px; border: 1px solid var(--border, #DDE2EC); border-radius: 8px; min-height: 32px; background: var(--surface-2, #F0F3F8); color: var(--text-1, #0D1826); overflow-x: auto; }
.cc-mat-result-table td { padding: 3px 8px; text-align: right; }

/* ── Equation solver screen ── */
.cc-eqn { display: flex; flex-direction: column; gap: 10px; }
.cc-eqn-modes { display: flex; gap: 6px; flex-wrap: wrap; }
.cc-eqn-panel { display: flex; flex-direction: column; gap: 8px; }
.cc-eqn-row { display: flex; align-items: center; gap: 6px; flex-wrap: wrap; }
.cc-eqn-row input { width: 64px; padding: 5px 6px; border-radius: 6px; border: 1px solid var(--border, #DDE2EC); background: var(--surface-1, #fff); color: var(--text-1, #0D1826); }
.cc-eqn-var { font-family: var(--mono, monospace); font-size: 1rem; color: var(--text-2, #4F5C6E); }
.cc-eqn-poly input { width: 56px; }
.cc-eqn-out { font-family: var(--mono, monospace); font-size: 1.05rem; padding: 8px; border-radius: 8px; background: var(--surface-2, #F0F3F8); border: 1px solid var(--border, #DDE2EC); color: var(--text-1, #0D1826); min-height: 24px; }

/* ── Stats screen (1-Var/2-Var stats + probability distributions) ──
   Reuses .cc-eqn-modes/.cc-eqn-panel/.cc-eqn-row/.cc-eqn-var/.cc-eqn-out
   above wholesale (same mode-row + dynamic-panel + result-box shape as
   the equation solver) — only the L1/L2 list editor and the
   distribution picker below are new. */
.cc-stat { display: flex; flex-direction: column; gap: 10px; }
.cc-stat-grid { display: flex; flex-direction: column; gap: 4px; max-height: 220px; overflow-y: auto; padding-right: 2px; }
.cc-stat-row { display: flex; align-items: center; gap: 6px; }
.cc-stat-row input { flex: 1; min-width: 0; padding: 5px 6px; border-radius: 6px; border: 1px solid var(--border, #DDE2EC); background: var(--surface-1, #fff); color: var(--text-1, #0D1826); font-family: var(--mono, monospace); }
.cc-stat-head { font-size: .78rem; font-weight: 600; color: var(--text-2, #4F5C6E); }
.cc-stat-cell { flex: 1; }
.cc-stat-rm { flex: 0 0 auto; width: 30px; padding: 4px 0; font-size: .85rem; }
.cc-stat-out { line-height: 1.55; }
.cc-stat-distr-pick { display: flex; }
.cc-stat-select { flex: 1; padding: 6px 8px; border-radius: 6px; border: 1px solid var(--border, #DDE2EC); background: var(--surface-1, #fff); color: var(--text-1, #0D1826); font-size: .95rem; }
.cc-stat-distr-params { padding: 0; }

/* ── MATH / CALC popups ──
   Two small in-app menus (openMathMenu()'s nCr/nPr/!/rand/randInt/∛/ⁿ√
   picker for TI's MATH key, and runCalcPrompt()'s per-variable value
   form for Casio's CALC key) — both built the same way: a full-bleed
   .cc-overlay-menu backdrop over just the calculator (.cc-app above is
   the positioned ancestor, so this never covers the rest of the page)
   with a centered .cc-popup-menu card. Site-level surface/text tokens,
   not a per-skin color, since this is app chrome floating above the
   device skin rather than part of the simulated device itself. */
.cc-overlay-menu {
  position: absolute; inset: 0;
  display: flex; align-items: center; justify-content: center;
  background: rgba(10, 12, 18, .55);
  padding: 12px;
  z-index: 20;
}
.cc-popup-menu {
  display: flex; flex-direction: column; gap: 8px;
  width: 100%; max-width: 260px;
  background: var(--surface-1, #fff);
  border: 1px solid var(--border, #DDE2EC);
  border-radius: var(--r-lg, 14px);
  padding: 14px;
  box-shadow: 0 12px 32px rgba(0, 0, 0, .3);
}
.cc-popup-title { font-weight: 700; font-size: .95rem; color: var(--text-1, #0D1826); text-align: center; margin-bottom: 2px; }
.cc-popup-btn {
  padding: 8px 10px;
  border-radius: 8px;
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-2, #F0F3F8);
  color: var(--text-1, #0D1826);
  font-weight: 600; font-size: .9rem;
  cursor: pointer;
}
.cc-popup-btn:hover { filter: brightness(.97); }
.cc-popup-btn.active { background: var(--indigo-500, #2B5BA8); border-color: var(--indigo-500, #2B5BA8); color: #fff; }
.cc-popup-close {
  padding: 8px 10px;
  border-radius: 8px;
  border: 1px solid var(--border, #DDE2EC);
  background: transparent;
  color: var(--text-2, #4F5C6E);
  font-size: .9rem;
  cursor: pointer;
}
.cc-popup-row { display: flex; align-items: center; gap: 8px; }
.cc-popup-row .cc-popup-btn, .cc-popup-row .cc-popup-close { flex: 1; }
.cc-popup-label { font-family: var(--mono, monospace); font-size: .95rem; color: var(--text-1, #0D1826); min-width: 44px; }
.cc-popup-input {
  flex: 1; min-width: 0;
  padding: 6px 8px;
  border-radius: 6px;
  border: 1px solid var(--border, #DDE2EC);
  background: var(--surface-1, #fff);
  color: var(--text-1, #0D1826);
  font-family: var(--mono, monospace);
}

/* No "Dark mode" section: every calculator color (case, topbar, keys,
   screen) is set per-skin above and stays fixed regardless of the
   site's light/dark theme — see the note above .cc-app. */

/* ── Small screens: stack topbar rows ──
   Key sizing itself no longer needs a breakpoint here — fitKeypad() in
   calculator.js measures the real viewport (however small or large)
   and sets --cc-key accordingly, so a phone gets a correctly-scaled
   keypad the same way a desktop or a smartboard does. */
@media (max-width: 480px) {
  .cc-winfield input { width: 50px; }
}