/* ═══════════════════════════════════════════════════════════════════════
Forms, modals & tables — v3
Loads after /assets/style.css (the compiled theme), before app.css.
WHAT CHANGED IN v3, AND WHY
---------------------------------------------------------------------
v2 was written for the SIDEBAR shell, and it was driven by erp-ui.js.
Both are gone. What was left behind was not neutral — it was actively
breaking two things:
1. THE PAGE LAYOUT. v2 §0 turned #content into its own scrollport
(max-height: 100dvh - var(--erp-shell-offset); overflow-y: auto),
because in the sidebar shell #content WAS the scroller. In the
top-nav shell the document scrolls and #content is an ordinary
block. app.css says so in a comment, but it only re-declared
max-width / margin / padding, so max-height and overflow-y survived
and nothing cancelled them.
Measured on a 40-row table at 1440x900: #content clientHeight 788px
against scrollHeight 1861px — 1073px of the table sealed behind a
second scrollbar, while the page itself only scrolled 228px. The
last row sat 1036px below the inner scroller's own bottom edge, and
the footer was stranded at y=1019 on a 900px viewport. Two nested
scrollbars, and no way to reach the bottom of a long list with the
wheel. That rule is deleted, not overridden.
--erp-shell-offset made this worse: erp-ui.js measured it at runtime
and no longer exists, so it was permanently frozen at its 7rem
fallback — a number describing a shell that is no longer rendered.
The variable is gone with it.
2. LONG MODALS. v2 capped the dialog and scrolled its body, but every
one of those rules was keyed on .modal-dialog-scrollable, and
erp-ui.js was the only thing that ever added that class. Without it
a long form simply grew past the viewport, and because Bootstrap's
.modal-dialog-centered centres with align-items:center, the overflow
spilled off BOTH edges — so the Save button could not be reached by
scrolling either.
Measured on the add form at three common laptop sizes, Save landed
at y=903..938 with viewports ending at 720 / 768 / 900.
elementFromPoint returned nothing: the button was not merely awkward,
it was unclickable. That is the "add form modal doesn't work" report.
§1 below now does the same job with NO class and NO JavaScript: the
dialog is capped against the viewport, the form is the flex column,
and the body is the only part that scrolls. Header and footer stay
pinned. It cannot regress the way a JS-applied class can.
Also removed: the student picker, image picker, .form-section,
.table-erp / .table-scroll, .erp-filters, .is-dense and the
#sidebar / .content-header / #page-loader print rules. Those came from
a school ERP — admissions, fee collection, tabulation sheets — and are
referenced by exactly zero templates in this project. ~300 lines.
═══════════════════════════════════════════════════════════════════════ */
:root {
--erp-gutter: 1.5rem;
--erp-label: .8125rem;
--erp-help: .6875rem;
--erp-radius: .5rem;
}
/* ═══ 1. MODALS ════════════════════════════════════════════════════════
The rule: a dialog is never taller than the window, and the Save button
is never the thing that falls off the bottom.
The cap goes on .modal-dialog rather than .modal-content so it survives
.modal-dialog-centered, which sets min-height on the same element. Both
resolve to roughly the viewport, so the dialog fills the space it is
allowed and its content is what gives.
These selectors match the markup this project actually ships:
.modal-content > .modal-header +