so the rule is one thing in
one place. An inline width would also be unreachable by any stylesheet fix, at
any specificity. */
.perm-matrix { width: max-content; min-width: 100%; }
.perm-matrix th.perm-role-col { width: 100px; text-align: center; }
/* --- "There is more of this table" -------------------------------------------
⚠⚠ THE STATE IS WRITTEN BY table-scroll.js, WHICH MEASURES. Nothing here may be
keyed on a viewport width or a role count: the matrix is one label column plus
100px per role and the roster is per tenant, so three roles fit a phone, nine
overflow a laptop and forty overflow anything. A `max-width: 760px` version of
this would be wrong in both directions at once — and would look right on
whichever screen it was written on.
[data-scroll="none"] it fits
[data-scroll="start"] at the left edge — more to the RIGHT
[data-scroll="both"] in between — more BOTH ways
[data-scroll="end"] at the right edge — more to the LEFT
⚠⚠ AN INDICATOR, NOT A CONTROL. A "Fit to screen" mode lived here briefly and
was removed: fitting means dividing the screen between the columns, so role
names had to shorten to initials, which reads badly at nine roles and cannot
work at all at forty — a column would end up narrower than its own checkbox.
Scrolling is the honest answer at every roster size, so the whole treatment is
a directional shadow, an arrow and a count.
⚠ SCOPED TO .perm-matrix-host, and that is what settles the specificity. The
phone block further down gives EVERY .tbl-wrap an unconditional right-edge
shadow at (0,2,0); these are (0,3,0) and win wherever they sit in the file, so
this does not depend on source order and cannot be broken by moving the block.
Verified by re-declaring that rule at the END of the document rather than by
counting selector weights.
⚠ And that unconditional shadow is deliberately still the fallback. If the
module never loads there is no data-scroll attribute, none of these match, and a
phone gets exactly what /roles gave it before — a hint that is always on. The
enhancement can fail without taking anything away. */
.perm-matrix-host .tbl-wrap[data-scroll="none"] { box-shadow: none; }
.perm-matrix-host .tbl-wrap[data-scroll="start"] { box-shadow: inset -10px 0 10px -10px rgba(0, 0, 0, 0.22); }
.perm-matrix-host .tbl-wrap[data-scroll="end"] { box-shadow: inset 10px 0 10px -10px rgba(0, 0, 0, 0.22); }
.perm-matrix-host .tbl-wrap[data-scroll="both"] {
box-shadow: inset 10px 0 10px -10px rgba(0, 0, 0, 0.22),
inset -10px 0 10px -10px rgba(0, 0, 0, 0.22);
}
/* The wrap becomes a tab stop only while it scrolls (table-scroll.js adds and
removes tabindex with role="region"), so it needs a focus ring like anything
else that can hold focus. */
.perm-matrix-host .tbl-wrap:focus-visible { outline: 2px solid var(--sky); outline-offset: 2px; }
/* --- The rail: a second scrollbar, above the table --------------------------
The native horizontal bar sits at the BOTTOM of ~70 permission rows, so you
have to scroll the page past the whole grid to find out the grid scrolls. This
is the same control where you start reading.
⚠ Hidden until the wrap has been MEASURED as overflowing — `display: none`
rather than visibility or opacity, so it is not a silent tab-order or
screen-reader passenger on a table that fits. Its inset and inner width are
set by table-scroll.js, which is the only thing that can know them.
⚠⚠ `overflow-x: scroll`, NOT `auto`. An empty strip whose only content is a
scrollbar is exactly what an overlay-scrollbar platform (macOS, iOS, and
Windows with "automatically hide scroll bars" on) fades out when idle — which
would leave a blank 10px gap above the table and no affordance at all, on the
machines least likely to be the one this was styled on. `scroll` keeps the
track present; the explicit sizes below keep it visible rather than hairline.
⚠ The height is set on the element AND the bar, because a strip shorter than
its own scrollbar clips it. */
.perm-scroll-rail { display: none; }
.perm-matrix-host:has(> .tbl-wrap[data-scroll]:not([data-scroll="none"])) .perm-scroll-rail {
display: block;
height: 17px;
margin-bottom: 6px;
overflow-x: scroll;
overflow-y: hidden;
/* Firefox: `thin` alone renders it nearly invisible on a bare strip. */
scrollbar-width: auto;
scrollbar-color: var(--line-mid) var(--fill);
border-radius: 5px;
background: var(--fill);
}
.perm-scroll-rail > div { height: 1px; }
/* ⚠ Overrides the sheet-wide 5px ::-webkit-scrollbar further up. That size is
right for a bar riding alongside content it can be read against; here the bar
IS the content, and 5px of it reads as a hairline rule rather than a control. */
.perm-scroll-rail::-webkit-scrollbar { height: 10px; }
.perm-scroll-rail::-webkit-scrollbar-track { background: var(--fill); border-radius: 5px; }
.perm-scroll-rail::-webkit-scrollbar-thumb { background: var(--line-mid); border-radius: 5px; }
.perm-scroll-rail::-webkit-scrollbar-thumb:hover { background: var(--ink3); }
/* --- The pinned column's edge ------------------------------------------------
A solid rule down the right of the Permission column, so the boundary between
what is pinned and what moves is stated rather than inferred from the motion.
⚠⚠ AN INSET BOX-SHADOW, NOT `border-right`. table.tbl is `border-collapse:
collapse`, and a collapsed border belongs to the TABLE's border grid rather
than to the cell that declared it — so it does not travel with a
`position: sticky` cell, and the rule would sit at the column's original
position while the column itself stays pinned. A box-shadow paints inside the
cell's own box and moves with it. Same pixel, and it cannot come adrift. */
.perm-matrix th:first-child,
.perm-matrix td:first-child { box-shadow: inset -1px 0 0 var(--line-mid); }
.role-chip {
display: inline-flex;
align-items: center;
gap: 6px;
padding: 4px 8px;
border: 1px solid var(--line);
border-radius: var(--r-pill);
background: var(--card);
font-size: var(--fs-sm);
font-weight: 600;
color: var(--navy);
}
.role-chip-x {
border: none;
background: transparent;
color: var(--bad);
cursor: pointer;
font-size:11px; /* ✕ glyph */
line-height: 1;
padding: 0 2px;
}
.role-chip-x:hover { color: #fff; background: var(--bad); border-radius: 50%; }
/* === RESPONSIVE ====================================================== */
/* The base layout is a fixed-viewport desktop shell (100vh, overflow:hidden,
inner scroll panes). The rules below progressively adapt it for narrow
windows, tablets, and phones. */
/* --- Tablet: relax dense multi-column grids --------------------------- */
@media (min-width: 761px) and (max-width: 1080px) {
/* Inline 3- and 4-up card grids step down to two columns. */
[style*="repeat(4"],
[style*="repeat(3"] { grid-template-columns: repeat(2, 1fr) !important; }
}
/* Below desktop (tablet AND phone): on an action bar that has a search field, the
trailing Add/Export buttons ride UP onto the title row (right-aligned) and the
search bar takes its own full-width row beneath — the buttons never stack below
the search. */
@media (max-width: 1080px) {
.action-bar:has(> .search-input-wrap) {
flex-wrap: wrap;
height: auto;
min-height: var(--actionbar-h);
row-gap: 6px;
}
/* Keep the spacer a horizontal filler so it pushes the buttons to the right of
the title row. The phone base rule otherwise makes it a full-width line break,
which is what was dropping the buttons below the search. */
.action-bar:has(> .search-input-wrap) > .action-bar-spacer {
order: 0;
flex: 1 1 0 !important;
flex-basis: 0 !important;
height: auto !important;
}
/* Title first, then the spacer + buttons on the same row. */
.action-bar:has(> .search-input-wrap) > .action-bar-title { order: 0; }
.action-bar:has(> .search-input-wrap) > .btn { order: 1; }
/* Search drops to its own full-width row underneath. */
.action-bar:has(> .search-input-wrap) > .search-input-wrap {
order: 2;
flex: 1 1 100%;
max-width: none !important;
margin-right: 0 !important;
margin-bottom: 5px !important;
}
}
/* --- Top nav collapses into a hamburger dropdown --------------------- */
/* With the grouped two-level menu (only 5 top-level items) the horizontal bar is
compact, so it stays visible down to a much smaller width than the old flat list
needed. */
@media (max-width: 900px) {
.topbar { position: relative; gap: 10px; }
.topbar-date { display: none; }
/* The search field stays a field — it just shrinks with the bar. The
results panel leaves the field's anchor and spans the viewport width
(anchored to the narrow pill it would overhang the screen edge). */
.topbar-search { padding: 6px 12px; }
.topbar-search-drop {
position: fixed;
top: calc(var(--topbar-h) + 4px);
left: 12px;
right: 12px;
width: auto;
}
.topbar-nav {
display: none;
position: absolute;
top: var(--topbar-h);
left: 0;
right: 0;
flex: none;
flex-direction: column;
gap: 2px;
padding: 8px;
background: var(--card);
border-bottom: 1px solid var(--line);
box-shadow: var(--shadow-md);
z-index: 250;
}
.topbar-nav.open { display: flex; }
.topbar-nav a,
.topbar-nav button {
width: 100%;
padding: 9px 12px;
border-radius: var(--r-sm);
text-align: left;
}
/* Groups stack in the panel: header on top, children shown indented below it
(no hover — everything is expanded). */
.nav-group { flex-direction: column; align-items: stretch; width: 100%; }
.nav-caret { display: none; }
.nav-dropdown {
display: flex;
position: static;
min-width: 0;
gap: 2px;
margin: 0;
padding: 0 0 4px 14px;
border: none;
border-radius: 0;
box-shadow: none;
background: transparent;
}
}
/* --- Phones / small windows: switch to natural document scroll -------- */
@media (max-width: 760px) {
/* Let the page scroll as a single document instead of fixed panes. */
html, body { height: auto; overflow: visible; }
body { min-height: 100vh; overflow-x: hidden; }
.app-shell { height: auto; min-height: 100vh; overflow: visible; }
/* Keep the top bar in view while the document scrolls. */
.topbar { position: sticky; top: 0; }
.page-body { overflow: visible; }
/* Unwind the fixed-height inner scroll regions (some set overflow inline). */
.main-content { overflow: visible !important; }
.content-scroll { overflow: visible; }
.dash { overflow: visible; }
/* Status strip: let it grow and scroll its stage pills horizontally. */
.status-strip { height: auto; }
.strip-stage-row { overflow-x: auto; padding-bottom: 2px; }
.strip-stage { flex-shrink: 0; }
/* The desktop 28px canvas gutters are 15% of a 360px screen — pull the
page-edge rows back in line with the content below them. */
.content-scroll,
.dash { padding-left: 12px; padding-right: 12px; }
.status-strip { padding-left: 12px; padding-right: 12px; }
/* Action bar wraps instead of clipping its controls. */
.action-bar {
height: auto;
min-height: var(--actionbar-h);
flex-wrap: wrap;
gap: 6px;
padding: 6px 12px;
margin-bottom: 10px;
}
/* The flex spacer would otherwise pin the buttons to the title's line and
shove them off-screen. Make it a full-width break so the title takes the
first line and the controls wrap onto the next, left-aligned. */
/* Scoped to real action bars: spacers inside section headers (box title
+ button rows) must stay horizontal fillers, or the full-width break
crushes the title into a sliver ("Estima/tes"). */
.action-bar > .action-bar-spacer { flex-basis: 100%; height: 0; }
.action-bar > .action-bar-spacer-nw { flex-basis: unset !important; height: 0; }
/* If a section header's title + button genuinely don't fit, the button
wraps below the title instead of squeezing it. */
.section-header { flex-wrap: wrap; row-gap: 6px; }
/* Add/edit pages nest a Save/Cancel action bar inside the breadcrumb. Let
the breadcrumb wrap and collapse that nested spacer (a 100% break here
would blow the bar past the screen and clip "Save"); the buttons then
sit together, right-aligned, on the breadcrumb row or just below it. */
.strip-breadcrumb { flex-wrap: wrap; row-gap: 6px; }
.strip-breadcrumb .action-bar {
flex-basis: 100%; /* drop onto its own full-width row */
margin-left: 0; /* stop pinning to the right edge (it overflowed) */
padding: 0;
height: auto;
min-height: 0;
}
.strip-breadcrumb .action-bar .action-bar-spacer { display: none; }
/* Collapse inline multi-column content grids to a single column. */
[style*="grid-template-columns"] { grid-template-columns: 1fr !important; }
/* Kanban flows naturally rather than relying on a fixed parent height,
and stacks its stage columns vertically instead of scrolling sideways. */
.kanban-board { height: auto; flex: none; flex-direction: column; overflow-x: visible; }
.kanban-col { width: 100%; }
.kanban-cards { overflow: visible; }
/* (The old .tbl-keep-N column-hiding rules are gone — every list table
now card-collapses via .tbl-cards instead of losing columns.) */
/* Touch targets: 44px is the FLOOR on a phone, not a target to approach.
⚠ This block used to sit at 40/36px, which reads as "close enough" and
is not — measured 2026-08-05 at 375px, 33 of 58 interactive elements on
the dashboard were under 44. The stated user is one-handed, in
sunlight, sometimes in gloves. Pinned by TouchTargetTests, which sweeps
every min-height inside a phone media query rather than an allowlist. */
.btn { min-height: 44px; padding: 11px 14px; }
/* ⚠ .btn-sm is 24px in the base sheet and appears in 17 pages. It had NO
phone rule at all, so `.btn { min-height }` above never reached it —
the modifier won on source order and shipped a 24px tap target. */
.btn-sm { min-height: 44px; padding: 10px 12px; }
.view-toggle .btn { min-height: 0; padding: 5px 12px; }
.modal-close, .flash-close, .li-del { min-width: 44px; min-height: 44px; }
/* The close button is absolutely positioned, so its 44px hit area does not
push the text — the reserve has to grow to match it by hand or a long
message runs underneath the ✕. */
.flash:has(.flash-close) { padding-right: 52px; }
/* Top-bar icon buttons keep their 34px VISUAL box on desktop (mockup
.iconbtn); on a phone they need a 44px hit area. min-*, not width/height,
so the painted circle is unchanged. (R9-07) */
.topbar-inbox .topbar-user-btn,
.topbar-user-btn { min-width: 44px; min-height: 44px; }
/* The home logo measured 26×26 and is on EVERY page — the smallest tap
target in the product sat in the corner a thumb reaches for first. The
painted logo keeps its size; only the hit box grows. */
.topbar-logo-m { min-width: 44px; min-height: 44px; justify-content: center; }
/* Filter chips are the primary affordance on every list page and measured
27px tall. Unlike the icon buttons above there is no separate painted
box to preserve — the pill IS the target, so it grows. */
.bp-chip { min-height: 44px; display: inline-flex; align-items: center; padding: 5px 14px; }
.bp-chips { gap: 8px; }
/* ⚠ .cell-link IS THE CONTROL THAT OPENS A RECORD, and it measured 23px tall
at 375px on ~100 instances across the list pages (2026-08-15 sweep). It is
the T18/TR-005 keyboard-parity control in the identity cell — the one thing
on a list row that a person is actually aiming for — and it was the smallest
target on the page. It inherits the row's font and had no phone rule at all:
the same "a modifier opts out of a floor by not being mentioned" shape that
.btn-sm had above.
⚠ inline-flex, not block: the identity cell often carries a badge or a
second line beside the link, and block would push those onto a new row. */
.cell-link { min-height: 44px; display: inline-flex; align-items: center; }
/* ⚠ The whole rail, not just its group headers. On a phone the rail IS the
navigation — it is what the bottom bar's "More" opens — so every row in
it is a primary tap target. Measured before this rule: group headers
33px, .navrail-top 36px, children 31px, which is 19 of the 58 tappable
things on the dashboard failing in one component. */
.navrail-group,
.navrail a,
.navrail-top,
.navrail .navrail-children a { min-height: 44px; }
/* The dashboard's "Around the shop" rows are links, stacked and adjacent —
at 36px each, a miss lands on the neighbouring one. ⚠ These were invisible
to the first measurement pass because that panel was still loading. A
target sweep has to run against a SETTLED page, or it reports the subset
that happened to have rendered. */
.bp-mini, .bp-xrow { min-height: 44px; }
/* 16px inputs also stop iOS Safari's zoom-on-focus. */
.field input, .field select, .field textarea,
.search-select-input, .search-input,
.li-row select, .li-row input, .ol-row input, .je-row input,
/* ⚠ .cell-input was MISSING from this list until 2026-08-07. It lives in a
| (and now in the detail head's rail), so it matched none of the four
selectors above — meaning every inline qty/cost cell on the estimate page
zoomed iOS on focus and offered a ~26px target. It is the one input in the
app you are most likely to be tapping from a truck. */
.cell-input, select.cell-input,
/* The three standalone field/kiosk pages declare their own font sizes in
page-level |