/* ============================================================ MVP Algebra 1 — Floating Panel styles (shared) © 2026 Alondra Delgado. All rights reserved. Part of the MVP Algebra 1 platform. Phase 2 — Pass C / Batch C.2 (floating-panel infrastructure split). Extracted VERBATIM from drill.html (the .eoc-panel base chrome, pre-Pass-C lines 287-384). "Refactoring is a MOVE, not a REDESIGN" (CLAUDE.md §12.2): no value (color, size, shadow, z-index, resize glyph) is changed during extraction. The one ADDITION is the cascade-positioning documentation block at the end (see below). WHAT THIS FILE IS The reusable visual half of the generic floating-panel system. It styles the draggable / resizable / fullscreen-able panel chrome used by the EOC Tools (calculator + reference sheet, via shared/eoc_tools.js) and by any future MVP Math panel anywhere on the platform. The behavioral half (drag, resize, fullscreen, cascade, lazy content) lives in shared/floating_panel.js. Identical chrome everywhere is deliberate: students build muscle memory once and it transfers to every tile (CLAUDE.md §4.15 — investor-worthy, consistent UX). Loaded via a in each consuming page's . HISTORICAL CLASS NAME (.eoc-panel) The base class is named `.eoc-panel` — its original drill.html name — rather than a generic `.floating-panel`. The name is retained on purpose for behavior equivalence and strict scope (CLAUDE.md §4.14, Pass C Option P): drill.html's hint panel layers theme-aware overrides via `.hint-panel .eoc-panel-header` / `.eoc-panel-body` selectors, so renaming the base would force churn across working CSS for zero UX gain. The MODULE and API names ARE generic (floating_panel.{css,js}, createPanel). The misleading base-class name (generic module, EOC- flavored class) is flagged as a §17.13 candidate for a future dedicated rename pass — NOT addressed in Pass C. THEME INDEPENDENCE (why no canonical theme vars here) The base panel chrome is intentionally fixed-white (#ffffff surface, #2a3a55 border, #1a2b40 text) in EVERY theme, mirroring the official Florida B.E.S.T. EOC test interface — the calculator and reference sheet must look the same regardless of the student's chosen theme. Substituting theme_engine.css variables (var(--panel), var(--text), ...) would re-tint the panels per theme — a visible REDESIGN that breaks the Pass C behavior-equivalence invariant. Theme-awareness is therefore NOT baked into the base; it remains an opt-in CONSUMER override (e.g. drill.html's `.hint-panel-body { background: var(--bg-2) }`), layered on top of this chrome in the consuming page. That is the correct seam: generic chrome here, per-panel theming where a panel wants it. NOT included here (kept in the consuming page): the topbar tool-button chrome (.eoc-tool-btn), help-button states, and drill's hint-panel overrides (.hint-panel*). Those are drill-specific, not panel chrome. Refs: CLAUDE.md §17.3 (Phase 2 shared-module refactor), §4.14 (build for now / existing-code-wins), §4.15 (investor-worthy code standard), §12.2 (move-not-redesign extraction policy). ============================================================ */ /* ============ FLOATING PANEL CHROME (floating, draggable, resizable) ============ */ /* Verbatim from drill.html pre-Pass-C lines 287-384. */ .eoc-panel { display: none; position: fixed; top: 50%; right: 24px; width: 420px; height: 540px; transform: translateY(-50%); background: #ffffff; border: 1px solid #2a3a55; border-radius: 12px; box-shadow: 0 20px 50px rgba(0, 0, 0, 0.45), 0 0 0 1px rgba(255, 255, 255, 0.1) inset; z-index: 9000; overflow: hidden; flex-direction: column; } .eoc-panel.open { display: flex; } .eoc-panel.fullscreen { top: 16px !important; left: 16px !important; right: 16px !important; bottom: 16px !important; width: auto !important; height: auto !important; transform: none !important; } .eoc-panel-header { display: flex; align-items: center; background: #ffffff; color: #1a2b40; padding: 12px 16px; border-bottom: 2px solid #2a3a55; cursor: move; user-select: none; } .eoc-panel-title { flex: 1; font-family: 'Outfit', sans-serif; font-weight: 800; font-size: 1.05rem; letter-spacing: 0.01em; } .eoc-panel-btn { background: transparent; border: none; color: #1a2b40; font-size: 1.05rem; cursor: pointer; padding: 4px 10px; margin-left: 4px; border-radius: 6px; transition: background 0.15s; font-weight: 700; } /* ---- TOUCH HOVER GUARD (23 Sept 2026) ---- Every :hover rule in this file is wrapped in @media (hover: hover). WHY. On iOS and Android the browser leaves :hover applied to whatever was last tapped, and it does not clear until something else is tapped. In the drill that produced a real bug: a student taps choice B, the next question renders new choices in the same place under their finger, and the new B lights up cyan as though they had already answered it. Alondra's students were reading a highlight that meant nothing. The options are rebuilt from scratch each question, so this was never a stale class -- it is the hover state itself. Gating hover behind a device that actually HAS a hover pointer is the fix. IF YOU ADD A :hover RULE, PUT IT INSIDE ONE OF THESE BLOCKS. tools/audit_hover.mjs fails the build on any unguarded :hover. */ @media (hover: hover) and (pointer: fine) { .eoc-panel-btn:hover { background: rgba(0, 0, 0, 0.08); } } .eoc-panel-body { flex: 1; overflow: auto; background: #ffffff; color: #1a2b40; position: relative; } .eoc-panel-body iframe { width: 100%; height: 100%; border: none; display: block; background: #ffffff; } .eoc-panel-fallback { display: none; position: absolute; inset: 0; align-items: center; justify-content: center; background: #ffffff; } .eoc-panel-fallback.show { display: flex; } .eoc-panel-resize { position: absolute; right: 0; bottom: 0; width: 22px; height: 22px; cursor: nwse-resize; background: linear-gradient(135deg, transparent 0%, transparent 50%, #2a3a55 50%, #2a3a55 60%, transparent 60%, transparent 70%, #2a3a55 70%, #2a3a55 80%, transparent 80%); z-index: 5; } .eoc-panel.fullscreen .eoc-panel-resize { display: none; } /* ============ CASCADE POSITIONING (multi-panel stacking) — NEW in Pass C ============ When more than one panel is open at once, each successive panel is offset from the previous so they don't completely cover one another. Offset step: 35px down AND 35px right per slot — chosen in the documented 25-45px range: large enough that the header of the panel beneath stays visible and tappable, small enough that a third/fourth panel still lands fully on-screen. MECHANISM (important): the actual translation is applied by shared/floating_panel.js, NOT by the rules below. On open, floating_panel.js counts how many panels are currently visible, assigns the new panel a 1-based cascade slot, sets data-cascade="{slot}" on it, and positions it via inline left/top. Inline left/top is used — rather than a CSS transform — because the base .eoc-panel centers itself with `transform: translateY(-50%)` and dragging switches the panel to inline left/top; a CSS transform-based cascade would fight both. Closing a panel releases its slot. The --fp-cascade-step value below is the SINGLE DOCUMENTED SOURCE of the per-step offset distance; floating_panel.js mirrors it as the CASCADE_STEP_PX constant. The [data-cascade] selectors are retained as inspectable styling hooks (debugging, future per-slot theming) and as documentation of the slot model — their bodies are intentionally empty because JS owns the positioning. */ .eoc-panel { --fp-cascade-step: 35px; } .eoc-panel[data-cascade="1"] { /* slot 1 — base position, no offset */ } .eoc-panel[data-cascade="2"] { /* slot 2 — JS applies 1x step (~35px down/right) */ } .eoc-panel[data-cascade="3"] { /* slot 3 — JS applies 2x step (~70px down/right) */ } .eoc-panel[data-cascade="4"] { /* slot 4 — JS applies 3x step (~105px down/right) */ }