` kept the paragraph's 0.75rem
* below it — `.field-hint` sets only the top — and a margin cannot cross the
* field's end when the field is a flex item or sits in a padded box, so every
* hinted field ended 12px lower than a plain one: 40px from its hint to the
* next label, against 28px from a box to the next label, alternating down the
* element and settings forms. The auth cards write the same hint as a
* `
`, which has no such margin, so the one component was spacing two
* ways. (0,2,0) against `p` (0,0,1) and `.field > label` (0,1,1). */
.field > :last-child {
margin-bottom: 0;
}
.field > label,
.form-label {
display: block;
margin-bottom: 0.3rem;
color: var(--muted);
}
/* HOW A TEXT-ENTRY CONTROL LOOKS. The width is NOT here and has not been since
2026-08-30; the rule below it is where it went and why.
`input[type="file"]` was in this list until 2026-09-29 and is not a
text-entry control: it is a box with a button drawn inside it, and it has a
rule of its own below (A FILE INPUT IS A BOX WITH A BUTTON IN IT) that
states its whole look, padding included. Left in here as well, the two
`padding`s would have been a tie at (0,1,1) settled by source order. */
input[type="text"],
input[type="password"],
input[type="email"],
input[type="number"],
input[type="date"],
input[type="search"],
select,
textarea {
font: inherit;
color: var(--text);
background: var(--input-bg);
border: 1px solid var(--input-border);
border-radius: 6px;
padding: 0.4rem 0.6rem;
}
/* A PLACEHOLDER IS ONE GREY, in every engine, since the second round of the
audit (2026-09-29). Nothing here said what colour it is, so each browser
used its own: Chromium's #757575 is plainly not a value beside the #d6d9de
a value is typed in, but WebKit's — Safari's — is `darkGray`, #a9a9a9, and
there an empty Actor box reading "any", or an allowance row reading
"12.00", looked filled in. `--placeholder` (section 1) is Chromium's grey,
the one every form here was read in, stated so Safari draws it too; it is
3.8:1 on the box's ground and 3.3:1 from a typed value. Not `--muted`,
which was tried: the labels' #8b95a3 is 2.1:1 from a value, halfway to
Safari's 1.7:1, and an empty box read nearly filled. `opacity: 1`
because Firefox fades a placeholder as well as colouring it. A
pseudo-element, (0,0,1), against the browsers' own sheets and nothing of
this one. */
::placeholder {
color: var(--placeholder);
opacity: 1;
}
/* AND HOW WIDE IT IS BY DEFAULT — a DEFAULT, at (0,0,0), which is the whole
point of splitting it out. This is the third bug from the one declaration.
The first two were the Policy CA % box on reports/new.html and the one on
reports/report.html; the third is the Log's date filters. Michael,
2026-08-30:
the from and to labels, please be consistent and place them on the left
side of the input fileds they link to not on top, all other once in line
are on the left. This should as well equal them in one straight
horizontal line.
THE ARITHMETIC THAT PRODUCED ALL THREE. `input[type="date"]` is (0,1,1) —
one attribute selector, one type. A utility class is (0,1,0). The class
count ties at one and the element count then decides, so `width: 100%` beat
every single-class rule in this sheet REGARDLESS OF SOURCE ORDER. Section 14
had to write `input[type="text"].input-narrow` and section 10
`.toolbar input[type="text"]`, both (0,2,1), and both had to name the very
selector they were beating. A rule no class can override is a rule that gets
overridden by a copy of itself on the next screen — which is precisely what
those two are, and why a third screen was owed the same fix.
`:where()` takes its argument's specificity to zero, so this list is (0,0,0)
— the lowest an author rule reaches, beaten by anything naming anything.
That is what "unless somebody says otherwise, fill the field" always meant.
NOTHING RESOLVES DIFFERENTLY TODAY, which is the reason to do it now rather
than on the day it is needed. Every rule in this sheet that narrows one of
these controls already won — but not all of them on specificity, and the
difference is the whole lesson. A selector LIST is scored PER BRANCH, so the
old list was never one (0,1,1) rule: its `input[type="date"]` branch was
(0,1,1) and its bare `select` branch was (0,0,1). `select { width: auto }`
two rules below is (0,0,1) as well, so that one was a TIE settled by source
order, and it would have flipped the day somebody moved it. Only
`.toolbar input[type="text"]` and `input[type="text"].input-narrow`, both
(0,2,1), beat the date branch outright. That is the state this edit ends:
against (0,0,0) every one of them is a strict win.
`tests.test_layout` re-resolves every control on every screen it renders
against the OLD per-branch selector list and demands the same answer.
THE APPEARANCE STAYED ABOVE, AT (0,1,1), AND THE SPLIT IS NOT TIDINESS. A
browser that cannot parse `:where()` drops this whole rule — that is how an
unknown selector fails — so what sits in here has to be something a form can
lose and still be a form. A box that sizes itself rather than filling its
field is that; a box with no background, no border and no padding on a dark
page is not. `:where()` shipped in Chrome 88, Firefox 78 and Safari 14, all
of them older than the `:has()` support section 13 argues about at length,
so by that section's own reckoning nobody is reading this fallback. That is
a reason to be careful about WHAT is in here, not a reason to skip it. */
:where(
input[type="text"],
input[type="password"],
input[type="email"],
input[type="number"],
input[type="date"],
input[type="search"],
input[type="file"],
select,
textarea
) {
width: 100%;
}
/* A BOX THAT SAYS HOW WIDE IT IS, IS THAT WIDE. Michael, 2026-09-29, asking
for the whole application to be gone over:
so that there is no more supises on lake of gaps, or input fields been
weird dimentions etc.
The weird dimensions were one default overruling an attribute. The markup
already sized its short boxes with `size` — a report name 36 characters, an
issue reference 48, a rating 5, a per-study value 8, a line range 5, the
reasons 24 to 40, an account rename 12 — and the default above filled the
field regardless, so a 5-character rating box was drawn 1198px wide. Three
places had each written `width: auto` back for their own screen: the
toolbar (section 10), the search form (below) and `.field-inline` (section
14). This is the rule those three were copies of: `size` is the HTML
attribute for "this many characters", and a box that carries one is sized
by it.
It also cures the opposite fault. A percentage width contributes nothing to
an auto-layout table's column minimum, so a box in a table cell was drawn as
narrow as the column's other content allowed: the new element's allowance
percent 21px wide on a phone, an operator code 42px. Sized, a box is as wide
as it says in a cell too, and a table that no longer fits scrolls in its
`.table-wrap`, which is what the wrapper is for. The templates give every
box in a table a `size` for that reason.
`max-width: 100%` so a 72-character box on a phone stops at its field.
(0,1,1) against the default's (0,0,0), a strict win; it ties with
`.field-inline input`'s (0,1,1) on `width` and both say `auto`. The three
older copies stay: each is a strict win of its own that `tests.test_layout`
asserts, and they agree with this one. */
input[size] {
width: auto;
max-width: 100%;
}
/* A PASSWORD IS NOT A PARAGRAPH. A password box has no length to state — a
passphrase is as long as its owner makes it — so it filled its field, and
the one password box outside a sign-in card, "Your password" on Security,
was drawn 878px wide at 1440 where the same words over the same box are
338px on the enrolment screen beside it (the audit, 2026-09-29). 24rem stops
it short of a paragraph and leaves every sign-in card's box as it is: those
are the card's 338px wide, less than this. `:not([size])` so that a
password box which did state a size would be sized by the rule above and
not tie with it on `max-width`: (0,2,1) against its (0,1,1). */
input[type="password"]:not([size]) {
max-width: 24rem;
}
/* AND HOW TALL A ONE-LINE CONTROL IS: the height of a button, stated. Michael,
2026-09-28, of the report toolbar:
the input field for policy CA% is now taller then any other input
field, culd we get that alighned please
Measured in Chromium, at 1440 and at 390 wide, on that one line: the Policy
CA % box 37.28px, the Precision select beside it 34.78px, Apply 34.38px.
Three heights from three line-heights, and only one of the three was chosen:
* the box takes `font: inherit` above, and that shorthand carries the line
height along with the font — body's 15px/1.5, a 22.5px line;
* the select takes the same 1.5 and cannot use it. Blink pins a drop-down's
line-height to `normal` whatever an author writes (its computed value
reads `normal` with this rule in force), then pads the inside of it by a
pixel above and below that no selector reaches. A select's height is not a
sum an author can write;
* `.btn` restates `line-height: 1.2` after its own `font: inherit` — the one
number here somebody picked.
WHY A HEIGHT AND NOT A LINE-HEIGHT. The obvious cure — the box's line
brought down to the button's 1.2, or to `normal` — was measured before it
was written, and it does not work: the box falls to 32.78px while the select
stays at 34.78px, two pixels SHORT where it had been two and a half tall.
The difference is the select's two hidden pixels, which belong to the
engine's theme and not to this sheet, so no rule that moves the box's
natural height can land on the select's. Both are told the one height
outright — and the one worth telling them is the button's, because a bar is
boxes, pickers AND the button that applies them: `.btn`'s 1.2em of line, its
0.45rem of padding above and below, and a 1px border top and bottom.
Section 2 makes everything border-box, so that sum IS the drawn height:
every box and select measures 34.39px beside the button's 34.38px, one sum
that the engine rounds onto its 1/64px grid by two routes. The box keeps its
own 0.4rem of padding, a tenth of a rem to spare around a 1.2em line; the
engines centre the text in the height they are given — and a select has
none above and below since 2026-09-29 (the rule after this one), because an
engine that pads inside the height as well cut its text to a sliver. On a
phone the text is 16px (below, ON A PHONE A CONTROL'S TEXT IS 16px), so the
one height is 35.59px there, the button's with it.
`line-height: 1.2` rides along for the boxes, whose inner line would
otherwise still be 22.5px inside a 19.6px content box. On the select it is
the value an engine that honours it would use, and Blink ignores it.
NOT IN THE LIST, each on purpose:
* `textarea` is a paragraph, not a line. It keeps the 1.5 `font: inherit`
gives it — the spacing its text is read at — and its `min-height` below.
* `input[type="file"]` is given the same height by its own rule below,
which also takes its padding off top and bottom so the button drawn
inside it fills that height rather than being squeezed by it — the reason
this comment used to give for leaving it out.
* A list box — `select[multiple]`, or a `size` above one — is many lines
tall, and this rule would flatten it to one. There is none in the
application, and `tests.test_layout` fails the day one is drawn.
Specificity (0,1,1) for the boxes and (0,0,1) for the select. Nothing else
in the sheet declares a height or a line-height for either except
`.login-card` (section 11), which sets its own padding and font size and so
sizes its own boxes; it says so where it does it. */
input[type="text"],
input[type="password"],
input[type="email"],
input[type="number"],
input[type="date"],
input[type="search"],
select {
line-height: 1.2;
height: calc(1.2em + 0.9rem + 2px);
}
/* A SELECT'S TEXT IS CENTRED BY ITS HEIGHT, NOT HELD UP BY ITS PADDING, since
the second round of the audit (2026-09-29). The height above is stated, and
every engine centres a drop-down's text in the height it is given; the
0.4rem above and below only has somewhere to go where an engine adds
padding of its own inside that — the Linux WebKit the audit's second
browser runs, whose theme puts 5px above and below the text: there it did
not fit the height, was cut to a sliver, and on a baseline-aligned bar
(section 10) each label sat 4.2px below the centre of its select. Safari
discards an author's padding on a drop-down anyway, and in Chromium neither
the height nor the text moves. The sides keep their 0.6rem. `:not([multiple])`
because a list box, were one ever drawn, is lines of options that do need
it. (0,1,1) against the look's bare `select` at (0,0,1). */
select:not([multiple]) {
padding-block: 0;
}
/* ON A PHONE A CONTROL'S TEXT IS 16px, since the second round of the audit
(2026-09-29). iPhone Safari zooms the page in when a box, a select or a
textarea whose text is smaller than 16px takes the focus, and every one
here was the body's 15px — so tapping a filter or a Code box enlarged a
layout fitted to 390px, and the reader had to pinch it back out. The
viewport is left as it is: forbidding the zoom (`maximum-scale=1`) would
also stop pinch-zoom on Android, which somebody may need to read at all.
EVERY full-size button goes to 16px with the boxes, because the one-line
height above is `.btn`'s own sum in `em`: at 16px each is 35.59px and they
still agree — a button left at 15px would stand a pixel short of the boxes
it submits. The first cut sized only the buttons on a row that holds a box
and left the rest at 15px, so one phone screen drew two button heights
(the report's Apply beside Save, Save as and Export CSV); the independent
review of 2026-09-29 found it, and the two labels that would have wrapped
at 16px were shortened instead ("Turn off two-factor", "Clear all EC flags
(N)"). `.btn-sm` (rows of buttons, never beside a box) and `.btn-lg` (the
auth card's, already 16.8px) keep their sizes, and so do the auth card's
boxes, whose own (0,2,1) is more than these.
`body` is what makes each rule a strict win rather than a tie settled by
where the query sits: (0,1,2) against the look's (0,1,1) — and the file
input's own (0,1,1) — and (0,0,2) against a bare `select` or `textarea`
(0,0,1). The button's is (0,2,1) — `:not()` counts as its most specific
argument — against `.btn`'s (0,1,0). */
@media (max-width: 640px) {
body input[type="text"],
body input[type="password"],
body input[type="email"],
body input[type="number"],
body input[type="date"],
body input[type="search"],
body input[type="file"],
body select,
body textarea {
font-size: 16px;
}
body .btn:not(.btn-sm, .btn-lg) {
font-size: 16px;
}
}
/* A BOX CLASSED `mono` OR `num` IS SET IN THE MONO FACE, which is what the
templates have been asking for and not getting. The look above starts with
`font: inherit`, and that shorthand sets the family too, at (0,1,1) — so
`.mono` and `.num` at (0,1,0) lost it on every box that carries them: the
element code, the operator and area codes, the rating, the line range and
the per-study value were all drawn in the body face while the same codes
and figures are mono everywhere they are printed. Found 2026-09-29 putting
`mono` on the settings form's Code box, where it would have done nothing
either. `.num`'s right alignment always applied; only the face was lost.
(0,2,1) against the look's (0,1,1); a mono box is a little wider for the
same `size`, every character being the widest. */
input[type].mono,
input[type].num {
font-family: var(--mono);
}
/* A number box is as wide as its numbers. It has no `size` attribute — HTML
gives `size` to text boxes only — and the browser sizes it from `min` and
`max` instead, 55px for Decimal places' 0 to 6. The default above drew that
one digit 1198px wide on the settings form. (0,1,1) against the default's
(0,0,0); `max-width` as for a sized box. The `font-family` beside them is
older and is NOT a strict win: the look's `font: inherit` is (0,1,1) as well
and this wins it by being written later. Nothing this edit adds depends on
it, and it is recorded here rather than disguised. */
input[type="number"] {
font-family: var(--mono);
text-align: right;
width: auto;
max-width: 100%;
}
/* A read-only field must LOOK read-only. The element code on an existing
element is drawn rather than omitted — its absence read as an oversight and
sent people hunting for the setting that had hidden it — but a box painted
like every other box is an invitation to type in it, and the explanation sits
below the field where it is read second. Muted, dimmed and cursor: default,
so the answer arrives before the click. The hint text still says why.
AND SO MUST A DISABLED ONE, since 2026-09-29. The project Code on the
settings form is `disabled` rather than `readonly` — it is not submitted at
all — and only `[readonly]` had this look, so it was painted exactly like
the editable Name box under it. projects/settings.html has said for months
that "a disabled box reads as 'you have permission to want this'"; this is
the half of that the stylesheet owed. `not-allowed` rather than `default`
because a disabled control is one the browser will not let anybody use, and
that cursor is what says so everywhere else (`.btn:disabled`).
`input[type]` AND NOT `input`, AND THAT IS A CORRECTION. `input[readonly]`
was (0,1,1), the same as `input[type="text"]` in the look above, so the
muted colour and the panel ground won only because this rule is written
later — a tie settled by source order, which is what `tests.test_layout`
reverses the sheet to catch. `input[type]` makes both states (0,2,1), a
strict win over the look and over the file input's own rule below; every
input in the application carries a `type`. A textarea or a select is
already strictly ahead: `textarea[readonly]` and `select:disabled` are
(0,1,1) against the bare element's (0,0,1). */
input[type][readonly],
textarea[readonly],
input[type]:disabled,
select:disabled,
textarea:disabled {
color: var(--muted);
background: var(--panel);
border-style: dashed;
}
input[type][readonly],
textarea[readonly] {
cursor: default;
}
input[type]:disabled,
select:disabled,
textarea:disabled {
cursor: not-allowed;
}
/* A FILE INPUT IS A BOX WITH A BUTTON IN IT, and it was the one control the
browser still drew: a box 38.28px tall beside 34.39px ones, holding a grey
square-cornered Arial button among `.btn`s. Out of the text-entry list above
since 2026-09-29, and described whole here instead.
The box is a one-line control's height — section 6's sum, `.btn`'s line,
padding and border — with no padding above or below, so the button inside
it can take that height whole rather than be squeezed by it, which is what
the height rule's comment used to say would happen. The button is then drawn
as the box's own left end: the panel ground a `.btn` has, the text colour
and face of the page, a rule on its right where it meets the file name, and
the box's own corner radius less its 1px border on the left. Its padding is
`.btn`'s across. `::file-selector-button` is Chrome 89, Firefox 82 and
Safari 14.1; a browser without it keeps its own button inside a box that is
still the right height. (0,1,1), against nothing: this is the only rule that
names the type since it left the list above. */
input[type="file"] {
font: inherit;
color: var(--text);
background: var(--input-bg);
border: 1px solid var(--input-border);
border-radius: 6px;
line-height: 1.2;
height: calc(1.2em + 0.9rem + 2px);
padding: 0 0.6rem 0 0;
}
input[type="file"]::file-selector-button {
font: inherit;
line-height: 1.2;
height: 100%;
margin: 0 0.6rem 0 0;
padding: 0 0.85rem;
color: var(--text);
background: var(--panel);
border: 0;
border-right: 1px solid var(--input-border);
border-radius: 5px 0 0 5px;
cursor: pointer;
}
select {
width: auto;
}
/* A SEARCH BOX SIZES ITSELF. The default above fills the field, and a search
box has no field: it sits in a `form[role="search"]`, a flex row, beside the
button that submits it. Filled to 100% it is a flex item whose hypothetical
size is the whole row, so the row gives it a line of its own and the button
drops under it — the toolbar's `#f-ca` defect (section 10) on a third
screen, which section 6's `:where()` was lowered to make cheap to cure.
Michael, 2026-09-14, of the project search as B9 shipped it:
Could the search button be nexto to the input field, on the right
please, same size as the 'ne project' button.
`form[role="search"]` and not the one screen's id, because the role is what
makes a form a search: every search form the application grows takes this
rule. (0,2,2) strictly beats the (0,1,1) the default had before it was
lowered, so the win is not a tie settled by source order —
`tests.test_layout` reverses the sheet and asks. How wide "itself" is comes
from `size` in the markup, an HTML attribute rather than a second number
here; `max-width: 100%` keeps the box inside a narrow viewport, as the
toolbar's rule does.
AND ON A PHONE THE BOX GIVES WAY, NOT THE BUTTON, since 2026-09-29. Thirty
characters is 295px, and the search form is a `.row-actions`, which wraps:
at 390 wide the box and its button did not fit one line, so Search dropped
under the box — the very arrangement the request above was about, back on
the one screen width nobody had drawn. The form therefore does not wrap, and
the box may shrink below its thirty characters (`flex: 0 1 auto` with
`min-width: 0`, since a flex item will not otherwise go below its own
width) until the button fits beside it. Measured at 390: the box 277px with
Search on its line, New project on the next. A search box narrower than its
`size` is still a search box; a button under it is not the one Michael
asked for. The form may shrink as well, and the row holding it in the page
head (section 3) — otherwise each refuses to be narrower than its content
and the page scrolls sideways instead, which the first measurement did.
`form[role="search"]` is (0,1,1) against `.row-actions`' `flex-wrap` at
(0,1,0); the box's rule is (0,2,2) and nothing else gives it a `flex` or a
minimum width. */
form[role="search"] {
flex-wrap: nowrap;
min-width: 0;
}
form[role="search"] input[type="search"] {
width: auto;
max-width: 100%;
flex: 0 1 auto;
min-width: 0;
}
textarea {
min-height: 6rem;
}
.field-error {
color: var(--text);
font-size: 0.85rem;
margin-top: 0.3rem;
}
.field-error::before {
content: "\26A0\FE0E";
color: var(--danger);
margin-right: 0.35rem;
}
.field-hint {
color: var(--muted);
font-size: 0.85rem;
margin-top: 0.3rem;
}
/* A refused box, marked where it stands. `input[type]` rather than `input`
since 2026-09-29, when the settings and new-project forms started using it
(they used to answer a refusal with a page flash only): `input.is-invalid`
was (0,1,1), the same as the `input[type="text"]` whose `border` shorthand
it overrides, so the red edge won on source order alone. (0,2,1) wins
outright; the select and textarea branches already beat their bare-element
look at (0,0,1). */
input[type].is-invalid,
select.is-invalid,
textarea.is-invalid {
border-color: var(--danger);
}
/* A ROW OF FIELDS THAT WRAPS IS SPACED LIKE A COLUMN OF FIELDS, since
2026-09-29. Side by side the fields are 0.75rem apart, which is the gap
across. Wrapped — the new operator's Code and Description, the add-a-line
form on Allowances, the element's allowance row, all of them on a phone —
the same 0.75rem stood between a box and the next field's label, where
everywhere else on the page a box is 28px above the next label: a field's
1rem and a card's 0.75rem gap. So a wrapped line is 1.75rem below the one
above it, the rhythm of the column it has become, and the submit button
that wraps under the last box is 28px below it as a card's action row is.
Nothing wraps at desktop width on the screens the audit draws, so this is
the phone's spacing only.
A row of boxes in a TABLE CELL is not a column of fields — the guide's
low/high/note correction, the accounts' Rename — and keeps 0.75rem between
lines, where the row's own padding is the spacing: `td .form-inline` at
(0,1,1) over (0,1,0). The accounts' row states its own `gap` at (0,2,0),
which beats both. */
.form-inline {
display: flex;
flex-wrap: wrap;
align-items: flex-end;
gap: 1.75rem 0.75rem;
}
td .form-inline {
row-gap: 0.75rem;
}
.form-inline .field {
margin-bottom: 0;
}
/* A SELECT IN A ROW OF FIELDS IS AT LEAST AS WIDE AS ITS LABEL. A field in
the row is as wide as the wider of its label and its control, and a select
is `width: auto` — as wide as its longest option — so a short option under
a long label left the select short of its own field and the button after it
stranded: "Default quantity" over "units", with Set default 44px past the
end of the select (the audit, 2026-09-29). With this the select ends where
its field does, and the button is the row's 0.75rem from it. A box that
states its `size` is left the width it states; this is the select only.
NOT IN A FIELD THAT CARRIES A HINT, since the second round of the audit
(2026-09-29). Such a field is as wide as its sentence — New report's Cycle
quantity, over "The denominator every frequency is written over…" — and
the select stretched to the sentence: "— none —" in a 714px box, with the
Fixed count box after it, where the Precision select in the card below is
75px. That is section 14's rule, A SENTENCE UNDER A CONTROL MAY NOT DECIDE
THAT CONTROL'S WIDTH, and a field with a hint keeps its select as wide as
its options. `:has()`, so a browser without it keeps the stretch it had.
(0,3,1) — `:not()` and `:has()` count as their argument — against nothing
else that sets a select's minimum width outside a toolbar, whose own
(0,1,1) `min-width` is for a different row. */
.form-inline .field:not(:has(> .field-hint)) > select {
min-width: 100%;
}
/* A TICK BOX OR A RADIO AND ITS WORDS: WHEN THE WORDS NEED A SECOND LINE, IT
STARTS UNDER THE WORDS, NOT UNDER THE BOX. A `
` that wraps its control
is inline text, and inline text breaks wherever a line runs out — the second
line starting at the label's left edge, under the box. On the import review
(2026-09-29) "Discard 3 observations" wrapped and its second line began
under the radio, where it read as a third option.
A hanging indent: the label is a block of its own, padded on the left by the
width of the box and the space after it, and its first line is pulled back
by the same amount so the box sits where it always did. Every later line
then starts where the first word did. 1.65rem is that width — a tick box
and its margins are 20px, a radio 21px, and the space after either about
4px in the system face — so a continued line lands within a pixel of the
first word, in both.
A flex row would line the words up exactly and was tried first. It moves no
glyph, but it makes every element in the label a flex item of its own —
the muted date after a study name became a block box a line tall — and the
audit's measurement then read the label's text 2.3px lower than it is
drawn. This keeps the inline layout the page already had, so the tick box
sits on exactly the line it sat on.
`:first-child` because the indent is the width of a control at the START of
the label, which is how every tick-box label here is written. And the label
is the box's tap target — clicking the words ticks the box — so it is at
least the 24px WCAG 2.5.8 asks of one: a 22.5px line and a pixel above and
below. The "All lines" toggle on the observation list was the one that
counted, too close to its neighbours for the spacing exemption.
What this does NOT do is stop the break between the box and the first word
where a word is wider than what is left of the line: the member picker's
two-letter codes dropped under their boxes that way, and section 9 answers
it where it happens, with room and `nowrap`.
`:has()`, so a browser without it keeps the inline label it had — the
fallback is the old layout by construction, which is section 13's argument
for its hide-rules and holds here for the same reason. (0,2,2) — an
attribute and a structural pseudo-class inside `:has()`, the two types —
which strictly beats the rules that make a label a block, `.field > label`
at (0,1,1) and `.form-label` at (0,1,0), and `.field-inline .form-label`'s
inline at (0,2,0). */
label:has(> input[type="checkbox"]:first-child),
label:has(> input[type="radio"]:first-child) {
display: inline-block;
padding: 1px 0 1px 1.65rem;
text-indent: -1.65rem;
}
/* ------------------------------------------------------------------ 7 */
.flash {
border: 1px solid var(--border);
border-radius: var(--radius);
padding: 0.7rem 1rem;
margin-bottom: 1rem;
}
.flash-error,
.flash-danger {
background: var(--flash-error-bg);
border-color: var(--danger);
}
.flash-info,
.flash-message,
.flash-success {
background: var(--flash-info-bg);
border-color: var(--accent);
}
/* The blocking banner: validation errors, and the contingency
double-count guard. It is loud on purpose — a report you cannot see the
warning on is a report you cannot defend. */
.banner {
border: 1px solid var(--accent);
border-left-width: 4px;
border-radius: var(--radius);
background: var(--flash-info-bg);
padding: 0.85rem 1rem;
margin-bottom: 1rem;
}
.banner-blocking {
border-color: var(--danger);
background: var(--flash-error-bg);
}
.banner-title {
font-weight: 600;
margin: 0 0 0.25rem;
display: flex;
align-items: baseline;
gap: 0.5rem;
}
.banner-blocking .banner-title::before {
content: "\26A0\FE0E";
color: var(--danger);
}
/* `.banner-title + p` and `.banner p:last-child` stood here, each zeroing a
paragraph's bottom margin. Both went 2026-09-29 for the one rule in section
5 that says what they were approximating — nothing inside a padded box adds
to the bottom of it — and the first went for a defect of its own: it fired
on the title's sentence when a second paragraph followed, and welded the
blocked study's "Show me the errors" button to the line above it. */
/* One validation finding: the rule's own wording, then the fix.
1rem under it since 2026-09-29, the break every box on the page brings
(section 5, THE MARGIN BELONGS TO THE BOX). It was 0.75rem, so a list of
findings was spaced 12px apart and the toolbar under the last one 12px
down, on a screen whose every other seam is 16. */
.finding {
display: flex;
flex-wrap: wrap;
gap: 0.5rem 1rem;
align-items: flex-start;
justify-content: space-between;
background: var(--panel);
border: 1px solid var(--border);
border-left: 4px solid var(--danger);
border-radius: var(--radius);
padding: 0.75rem 1rem;
margin-bottom: 1rem;
}
.finding-warn {
border-left-color: var(--t-contingency);
}
.finding-body {
flex: 1 1 24rem;
min-width: 0;
}
.finding-where {
font-family: var(--mono);
font-size: 0.85rem;
color: var(--muted);
margin-bottom: 0.2rem;
}
.finding-rule {
margin: 0;
}
.finding-detail {
color: var(--muted);
margin: 0.15rem 0 0;
}
/* ------------------------------------------------------------------ 8 */
.chip {
display: inline-flex;
align-items: baseline;
gap: 0.35rem;
font-size: 0.8rem;
line-height: 1.4;
padding: 0.1rem 0.45rem;
border-radius: 4px;
border: 1px solid transparent;
white-space: nowrap;
}
.chip .glyph {
font-size: 0.9em;
}
/* Element type — code + glyph + colour, in that order of importance. */
.chip-repetitive {
color: var(--t-repetitive);
background: var(--chip-repetitive-bg);
}
.chip-occasional {
color: var(--t-occasional);
background: var(--chip-occasional-bg);
}
.chip-contingency {
color: var(--t-contingency);
background: var(--chip-contingency-bg);
}
.chip-foreign {
color: var(--t-foreign);
background: var(--chip-foreign-bg);
}
.chip-ineffective {
color: var(--t-ineffective);
background: var(--chip-ineffective-bg);
}
/* Element category — the second cue is fill weight, never hue:
VA boxed, ENVA bare, NVA bordered. */
.cat {
display: inline-block;
font-size: 0.78rem;
letter-spacing: 0.04em;
padding: 0.05rem 0.4rem;
border-radius: 4px;
border: 1px solid transparent;
white-space: nowrap;
}
.cat-value_added {
color: var(--c-va);
background: var(--chip-va-bg);
}
/* Bare means no fill and no border — NOT no padding. The padding used to go as
well, so ENVA's text began 6.4px left of VA's and NVA's in the same column
and a category column read as ragged. The box is still there, invisible, so
all three words start on one line. */
.cat-essential_non_value_added {
color: var(--c-enva);
background: transparent;
}
.cat-non_value_added {
color: var(--c-nva);
background: var(--chip-nva-bg);
border-color: var(--c-nva);
}
/* A badge is set in its own face and weight wherever it is put. Without these
it took them from its surroundings, so the "ready" pill beside a study's
`` and FROZEN beside an issue's `` were bold, the percentage in the
comparison's `` headline was bold monospace, and the same
pills in a table cell were neither. */
.badge {
display: inline-block;
font-family: system-ui, sans-serif;
font-size: 0.78rem;
font-weight: 400;
padding: 0.05rem 0.45rem;
border: 1px solid var(--border);
border-radius: 999px;
color: var(--muted);
}
.badge-ok {
color: var(--c-va);
border-color: var(--c-va);
}
.badge-blocked {
color: var(--text);
background: var(--flash-error-bg);
border-color: var(--danger);
}
.badge-edited {
color: var(--t-contingency);
border-color: var(--t-contingency);
}
.badge-accent {
color: var(--accent);
border-color: var(--accent);
}
/* ------------------------------------------------------------------ 9 */
/* Tables are the point of this application.
border-collapse: separate is not a style choice. Collapsed borders do
not travel with position: sticky cells — the rules stay behind while the
cell scrolls over them — so the report table draws its own borders per
cell and sets border-spacing to 0. */
/* Both wrappers carry the 1rem every box does, so the footnote, the card or
the banner under a table is never flush against it. Section 5 says why it
is a margin on the box rather than a rule per neighbour, and where it is
taken off again (in a card, and last in a container).
A SCROLLER IS THE CONTAINING BLOCK OF WHAT IT SCROLLS: `position:
relative`, since 2026-09-29. A `.visually-hidden` label is absolutely
positioned (section 2) with no offsets, so it sits at its static place —
deep inside a wide table, far to the right of the pane — and it is
positioned against the nearest POSITIONED ancestor. Neither wrapper was
one, so that ancestor was the page, and a one-pixel label 600px along a
scrolled table widened the whole document: the reports list, Accounts, the
per-study quantities and the import review each scrolled sideways on a
phone into an empty band (609, 440, 435 and 666px wide at 390). Positioned,
the wrapper holds the label and scrolls it with the table. No `z-index`, so
no stacking context: the sticky El and Description columns, the sticky
head and the TOTAL row stack exactly as they did. Nothing else in a
wrapper is positioned against it. */
.table-wrap {
position: relative;
overflow-x: auto;
border: 1px solid var(--border);
border-radius: var(--radius);
margin-bottom: 1rem;
}
/* The element tables' pane: 70vh, with the head and the TOTAL row stuck to
its top and bottom while the lines scroll between them. A pane for a table
READ in part — a report of elements — and not for a list in which every row
is a decision: the quantity's member picker and the joblet's element list
are `.table-wrap`s since 2026-09-29, because the pane cut the last four to
seven of their nineteen rows off at a row boundary, with no footer and, on
an overlay scrollbar, no sign there was more. */
.table-scroll {
position: relative;
overflow: auto;
max-height: 70vh;
border: 1px solid var(--border);
border-radius: var(--radius);
margin-bottom: 1rem;
}
/* The one caption drawn on screen (the force-apply preview) was the browser's:
centred over the table and 3px above its border. It reads as the table's
heading row, so it starts where the cells do, wears the head's colour and
weight, and sits on the table's own ground rather than the page's showing
through the wrapper. Every other caption is `.visually-hidden`, which
zeroes this padding (section 2) so a hidden caption stays the one pixel it
is meant to be. */
caption {
text-align: left;
padding: 0.5rem 0.75rem;
color: var(--muted);
font-weight: 600;
background: var(--panel);
}
table {
width: 100%;
border-collapse: separate;
border-spacing: 0;
}
th,
td {
text-align: left;
padding: 0.5rem 0.75rem;
border-bottom: 1px solid var(--border);
border-right: 1px solid var(--rule-v);
background: var(--row-bg, var(--panel));
vertical-align: top;
}
th:last-child,
td:last-child {
border-right: 0;
}
tbody tr:last-child > * {
border-bottom: 0;
}
thead th {
--row-bg: var(--head-bg);
color: var(--muted);
font-weight: 600;
white-space: nowrap;
border-bottom-color: var(--border);
}
/* Row state is published once, on the , as --row-bg. Every cell reads
it — including the sticky ones, which is why zebra, hover, error and
ineffective each need exactly one rule and not one rule per column. */
tbody tr {
--row-bg: var(--panel);
}
tbody tr:nth-child(even) {
--row-bg: var(--row-zebra);
}
tbody tr:hover {
--row-bg: var(--row-hover);
}
tbody tr.is-ineffective {
--row-bg: var(--row-ineffective);
}
tbody tr.is-error {
--row-bg: var(--row-error);
}
tbody tr.is-error:hover {
--row-bg: var(--row-error-hi);
}
/* Amber, not red, for a line whose finding somebody has already acknowledged.
Michael, 2026-09-04, asked for "a red backgound under the row where the
issue is" and pointed at HR-001 / test2 line 22 — whose one finding, it
turned out, was already acknowledged. Painting that red would re-open on
every visit a decision the validation screen records as taken; painting it
nothing would leave his own example invisible. The validation screen already
draws the two states apart — `error` for open, `warn` plus an "acknowledged"
pill for accepted — so the list uses the same two words and the same
distinction. Same lightness family as --row-error, hue moved from red to
amber, so the two read as siblings and neither shouts over the other. */
tbody tr.is-warn {
--row-bg: var(--row-warn);
}
tbody tr.is-warn:hover {
--row-bg: var(--row-warn-hi);
}
/* Numeric columns: right-aligned, monospace, fixed 4 dp, so decimals line
up down the page. tabular-nums keeps the digit advance constant even
where the system font would not. */
.num {
text-align: right;
font-family: var(--mono);
font-variant-numeric: tabular-nums;
white-space: nowrap;
}
/* A NUMERIC COLUMN'S HEAD IS A HEAD, NOT A NUMBER. `.num` was written for the
cells — mono so the digits stack, nowrap so a figure never breaks — and the
templates put it on the `` as well, for the right alignment, which is
the half a head wants. The other two came along: every header row mixed two
faces, the mono ones over the numbers and the sans ones over the text, and a
long head could not wrap, so it set its column. "Project total" took 141px of
the project Overview's 353px Cycle definition card and cut the figures
under it to "22" for 227 on a phone. A head is set in the head's face and
wraps between its words like any other; it keeps `.num`'s alignment, so it
still stands over its figures. A unit written after its label is a word
too, and on a phone, where a percentage column is squeezed to its figures,
"CA" and "%" took a line each, so the templates hold the two together
(`CA % `, since the second round of the audit):
the head wraps between its words and never inside a label and its unit.
(0,1,2) against `.num`'s (0,1,0) and `thead th`'s (0,0,2). */
thead th.num {
font-family: inherit;
white-space: normal;
}
/* ON A PHONE A TABLE SCROLLS; IT DOES NOT ALSO WRAP ITS NAMES. A figure is
`nowrap`, so a table of them is wider than a phone before any text column is
counted, and it scrolls in its wrapper whatever the text does. Auto layout
then squeezed every text column to its narrowest word as well, so the
project list at 390 read "4349-" / "DC2-" / "layout" down a 60px column, a
username broke at its hyphen and rows ran 62 to 150px tall — a table that
both wraps and scrolls, the worst of each. The audit offered two cures and
the orchestrator chose, on Michael's "fix everything" of 2026-09-29, the one
that keeps a name whole: the table scrolls, and a name is one line.
What is a name is marked, not guessed. A row's own head (`th[scope="row"]`
— the report, the study, the convention) is one line at every width: each
is a few words, and the one place that could be longer is a table built to
scroll. A cell whose text is the project's code or name, a study's name,
an issue's reference, report and issuer, an account's username or the
Log's actor, is `.ident`, and is one line on a phone only: at desktop
width the production archive's codes are sentences of 40 characters
("Project 4905 - GXO Primark - AMR Putaway"), and held on one line in a
960px column they would scroll the project list sideways at 1440 too —
and the Log's actor, held whole at 1024, pushed the Log 92px past its pane
with its After column out of sight (the second round of the audit,
2026-09-29). A study's name is the same case: held whole, the production
copy's Induct studies list was 1285px in its 1246px pane at 1440, and 543
of that copy's study names are longer than 20 characters, up to 75 (the
review of the fixes, 2026-09-29, which marked the study list's names and
the Issued tab's). An image's "2 fields" on the Log is held with them, on a phone
only, for the same reason (section 14). The Log's hashes and fingerprints
are not names and stay breakable — one of them unbroken is 500px. (0,1,1)
and (0,1,1), against `th, td`, which says nothing about wrapping; `thead
th`'s nowrap is not a row head's. */
th[scope="row"] {
white-space: nowrap;
}
/* The composition's row head is not a name but a chip and its words — "ENVA
Essential non-value added" — and held on one line it is 280px: on a phone
the By value stream table then showed its slices and a cut Minutes column,
with Share % and Elements, the figures the card is for, out of the 330px
pane (the second round of the audit, 2026-09-29). It wraps between its
words again, and the table scrolls only for Elements, as it did. (0,2,1)
against the row head's (0,1,1). */
.composition th[scope="row"] {
white-space: normal;
}
@media (max-width: 640px) {
td.ident,
.log-image > summary {
white-space: nowrap;
}
}
/* A BUTTON IN A CELL IS ONE LINE, AND SO IS A ROW OF THEM. A squeezed column
broke "Export .pjf" on the joblets list over two lines inside its button,
and stacked Edit, Export and Delete into a 122px row; on a phone the
operators' and areas' Save and Delete stacked the same way. The row stays a
row and the table scrolls, as it already does for its figures. The Accounts
actions are an `.account-actions` and wrap on purpose (section 3: Michael
asked for every button to stay in view). (0,1,1) each, against nothing for
the button — `.btn` does not say how it wraps — and against `.row-actions`'
`flex-wrap` at (0,1,0) for the row. */
td .btn {
white-space: nowrap;
}
td > .row-actions {
flex-wrap: nowrap;
}
/* TABLES STACKED ONE ABOVE ANOTHER SHARE ONE GRID. Four screens draw a family
of tables with the same head, and each table was laid out on its own, so
the same column stood at a different place in each: the project list's
years (Studies at x=605 in 2014 and at 753 in 2026, with the archive open),
the relaxation guide's twelve sections, the composition's two tables in one
card (Minutes ending at 826 in one and 916 in the other), the import
review's per-file element lists. A reader running an eye down a column
crossed a table boundary and lost it.
Each family gives its tables a `` and the widths are stated here:
the columns of figures, dates and short notes the width their longest real
value needs, in rem, and where a family has two text columns one of them a
share of the table — so what is left goes to the same column in every
table: the project's name, the slice's name, the guide's variation, the
import's status (and on its decision table the three columns that describe
a new element, after a decision column sized to its two answers). The
audit proposed `table-layout: fixed` for this; that turns a width into a
law, and a name longer than its column would then be drawn over the next
cell. In the ordinary automatic layout a
stated width is what a column is given whenever its content allows it —
which is every table here at desktop width — and a column whose content
cannot fit grows instead, which on a phone is the project list's
one-line names (above): those tables scroll, each on its own. Measured on
the production copy with every year open, at 1440 and at 1024: every
year's six columns start at the same six x positions, and so do the
guide's sections and the import's lists. (0,2,1) each, and `` after the slash and the last two words of "% per SMV
Total" kept together, so none of them runs to a third line.
Measured in the audit's sweep: the narrowest these tables can now be drawn
is 1129 to 1235px (Induct report 4 the widest, the study summaries 1163 to
1177), so at 1440 every one of them fills its 1246px pane with every column
in view — the Study Grid's ten studies and its combined column too. At 1024
the pane is 990px, 139 to 245px short of that narrowest width with every
column already at its longest figure; fitting there would mean cutting
figures or Description to a few characters, so at 1024 and below the table
scrolls in its pane as it always has, with El and Description stuck on the
left. (0,1,1) against `th, td`'s (0,0,1). */
.report-table th,
.report-table td {
padding-left: 0.4rem;
padding-right: 0.4rem;
}
/* A REPORT TABLE THAT IS NOT A REPORT KEEPS ITS PADDING. The joblet's element
list is a `.report-table` for its sticky El and Description and its row
rules, not for fourteen columns that must fit a pane: it is seven, in a pane
with room to spare. At the report's 0.4rem the right-aligned position
number stood 14px from the El code across a rule that barely shows, so a
row read "1 1" and the head "On device El" (the second round of the audit,
2026-09-29). The ordinary 0.75rem puts 27px between them, wider than the
23px from the tick box to its number. (0,2,1) against the report's (0,1,1). */
.report-table.joblet-list th,
.report-table.joblet-list td {
padding-left: 0.75rem;
padding-right: 0.75rem;
}
/* A report head wraps between its words. `thead th` keeps a head on one line,
which is right for a head over text and is what made these columns wider
than their figures. Two lines at most, by the templates' own breaks above.
(0,1,2) against `thead th`'s (0,0,2); `thead th.num` above says the same at
the same weight. */
.report-table thead th {
white-space: normal;
}
/* A REPORT ROW IS A WHOLE NUMBER OF PIXELS TALL. The body's 15px/1.5 line is
22.5px, and a type chip on its baseline made the line 23.5: every row was
40.5px, so every other rule fell on a half pixel. The sticky El and
Description cells are painted on a layer of their own and round the half
the other way, and the audit found their row rules a pixel above the rest of
the row, doubled, or missing — a stepped left edge on every report at 1024
and on a phone. A 24px line (15px x 1.6) with the chips, badges, category
tags and small buttons in a row held inside it — centred on the text, a
pixel given back above and below so the tallest of them, a small button at
24.7px, no longer grows the line — makes every row 41px and a two-line head
65. Measured on the report, the study summary, the Study Grid, the
observation list (production's 1109 lines) and the styleguide: no row off
the pixel. (0,1,0) for the line, inherited by every cell; (0,2,0) for the
boxes, against nothing that sets their vertical alignment or margin. */
.report-table {
line-height: 1.6;
}
.report-table .chip,
.report-table .badge,
.report-table .cat,
.report-table .btn {
vertical-align: middle;
margin-top: -1px;
margin-bottom: -1px;
}
.report-table .col-el {
width: var(--col-el-w);
min-width: var(--col-el-w);
max-width: var(--col-el-w);
position: sticky;
left: 0;
z-index: 2;
font-family: var(--mono);
}
.report-table .col-desc {
width: var(--col-desc-w);
min-width: var(--col-desc-w);
max-width: var(--col-desc-w);
position: sticky;
left: var(--col-el-w);
z-index: 2;
border-right: 1px solid var(--border);
box-shadow: 6px 0 8px -8px rgba(0, 0, 0, 0.75);
}
.report-table thead .col-el,
.report-table thead .col-desc,
.report-table tfoot .col-el,
.report-table tfoot .col-desc {
z-index: 4;
}
.report-table thead th {
position: sticky;
top: 0;
z-index: 3;
}
/* A PICK LIST'S EL CELL HOLDS A TICK BOX AS WELL AS THE CODE. The quantity
editor's member picker is a report table whose El column is "In": the box,
then the code. 4.5rem leaves 48px inside the cell's padding, which holds a
code on its own and not a box beside one: the line broke between the box
and the code, so "SS", "CL" and "OP" dropped under their boxes (2026-09-29)
and each such row grew from 40px to 62px. The box and its code are one
thing, so the label does not break (`nowrap`), and the column is given the
room for them: 6.5rem holds the box, the space and five mono characters,
which is the most `MAX_ELEMENT_CODE` allows — at 4.5rem an unbreakable
five-letter code would have run into the sticky Description cell instead.
Set as the custom property on the table, not as a width on the cell,
because `.col-desc`'s sticky offset is read from the same property and the
two must stay in step (section 1). (0,2,0) and (0,2,1), against nothing. */
.report-table.picker {
--col-el-w: 6.5rem;
}
.report-table .col-el > label {
white-space: nowrap;
}
/* A POSITION NUMBER IS AS WIDE AS THE LARGEST ONE. The joblet's On device
column prints each chosen element's place on the tablet after its tick box,
in a right-aligned cell — so the box moved left by a digit's width at row
10, and again at 100, and an unticked row, with no number at all, drew its
box at the cell's right edge (the audit, 2026-09-29). Three mono digits of
room, whether or not there is a number to put in them — `MAX_ELEMENTS` is
400 — right-aligned inside that room, and every box in the column stands
in one line. `text-indent: 0` because an inline block is a block container
and would inherit the hanging indent its label is given in section 6.
(0,1,0), against nothing. */
.position {
display: inline-block;
min-width: 3ch;
text-align: right;
text-indent: 0;
}
/* A ROW OF BOXES CENTRES ITS CELLS. Every cell is `vertical-align: top`
(above), which is right for text: a two-line description and a one-line
number both start at the top of their row. It is wrong in a row that edits
in place — the operators and areas lists, the new element's allowance rows,
the study's per-quantity override — where the cells hold 34px boxes: the
Observations, Studies and Corrections figures sat 6px above the text in the
boxes beside them, and the buttons at a third height. Centred, the figures
and the text in the boxes share a line.
A row qualifies when a one-line box or a select is a cell's own content, or
sits on the one action row that is: that is what makes the box the row's
content rather than one part of a taller cell. The accounts list and the
allowance-source table hold their boxes deeper, among several lines of
other content, and read from the top as they did. Tick boxes and radios do
not count: they sit on a text line already. Without `:has()` a row stays
top-aligned, which is how it was. (0,4,5) — `:has()` counts as its most
specific argument — against `th, td`'s (0,0,1). */
tbody tr:has(
> td > :is(input:not([type="checkbox"]):not([type="radio"]):not([type="hidden"]), select),
> td > .row-actions > :is(input:not([type="checkbox"]):not([type="radio"]):not([type="hidden"]), select)
) > td {
vertical-align: middle;
}
/* A LINK THAT IS A CODE OR A NUMBER IS A TARGET, NOT A WORD. The observation
list links each line from its number and from its element code, and on a
phone the smallest were 9.55 x 18px — the element "4" — and "25" at
18 x 18, with other targets too near for the WCAG 2.5.8 spacing exemption.
24px across by at least the line's 22.5px and a pixel above and below: a
one-character code gains the difference in width, which moves the
description after it by at most 14px, and the negative margin hands the
line back the two pixels of padding, so no row grows. (0,1,2) against
nothing. */
td.col-el > a,
td.col-desc > a {
display: inline-block;
min-width: 1.6rem;
padding-block: 1px;
margin-block: -1px;
}
/* A TOTAL row is ruled off from the rows it totals, in every table and not
only the report's. The composition tables had none of the report's rule
below, so their TOTAL sat directly under an Ineffective row of nearly the
same ground and read as one more slice. The same 2px rule and 600 weight the
report's footer has always had; (0,0,2), which the report's own (0,1,2)
below still refines. */
tfoot th,
tfoot td {
border-top: 2px solid var(--border);
font-weight: 600;
}
/* The totals row sticks to the bottom of the scroll pane, as iePro's does.
Its cells carry their own --row-bg so the sticky left columns match. */
.report-table tfoot th,
.report-table tfoot td {
--row-bg: var(--row-total);
position: sticky;
bottom: 0;
z-index: 3;
border-top: 2px solid var(--border);
border-bottom: 0;
font-weight: 600;
}
/* ----------------------------------------------------------------- 10 */
.toolbar {
background: var(--panel);
border: 1px solid var(--border);
border-radius: var(--radius);
padding: 0.75rem 1rem;
margin-bottom: 1rem;
display: flex;
flex-wrap: wrap;
gap: 0.5rem 1.5rem;
align-items: center;
}
/* A LINE OF THE BAR READS ON ONE BASELINE, since 2026-09-29, and was
`align-items: center`. Centring is right while everything on a line is one
control tall and wrong the moment one item is not: the report's study
picker is a ``, and opened it is a list of studies some 400px
tall, so "Studies" and the Cycle quantity select beside it were centred on
the middle of the list — 180px below the summary line they belong to — and
on the Study Grid, where the picker opens by default, "Output" floated
half-way down it. On the baseline, a label sits on the line of the control
or summary it names, however tall a neighbour grows. Every other line
lands where it was: a label, a box and a button of one height share their
text line either way, and the fix sweep of every screen at three widths
found no control that moved against its neighbours.
AND IT IS A HANGING INDENT, the shape section 6 gives a tick box and its
words, for the same reason: when a line wraps, what wraps starts under the
controls, not under the line's own label. The first `.toolbar-label` is the
line's name and sits in the first 6rem; the line is padded by that column
and its gap, and the label is pulled back into the padding by the same
amount, so its controls start at 7rem and so does every line they wrap
onto. Before this, a wrapped note ("the element-type filter is a view…",
the cycle's basis) and the Log's To field restarted flush under "Filters"
or "Filter", where they read as the start of a line of their own — the
ragged edge the audit measured on the Log at 1024 and on a phone. A grid
with a label column would do the same with one more wrapper round every
line's controls; this needs none, and a line with no leading label (none
today) simply starts at the indent.
`:first-child` and `>` because only the line's own name is the column: a
`.toolbar-label` further along names one control and travels with it
(`.toolbar-pair`, below). Its `flex` is the column's width outright, where
`min-width: 6rem` on `.toolbar-label` left it free to grow past the
indent. (0,2,0) against `.toolbar-label`'s (0,1,0). */
.toolbar-line {
display: flex;
flex-wrap: wrap;
gap: 0.4rem 1rem;
align-items: baseline;
width: 100%;
padding-left: 7rem;
}
/* A LINE'S HEAD IS A HEAD: the labels' size and a head's weight, since the
second round of the audit (2026-09-29). The filter labels became
`.form-label`, 15px, and the words heading their lines — Studies, Filters,
Allowances, the Log's Filter, the comparison's Then and Now — stayed
13.6px beside them in the same grey, so "Filters" was drawn smaller than
the "Operator" it groups, most plainly on a phone where it heads a stack of
them. At the labels' size and 600, the weight `thead th` heads a table
with, the head of a line reads as the head of what follows it. (0,1,0),
against nothing that sets its size or weight. */
.toolbar-label {
color: var(--muted);
font-weight: 600;
min-width: 6rem;
}
.toolbar-line > .toolbar-label:first-child {
flex: 0 0 6rem;
margin-left: -7rem;
}
/* ON A PHONE THE LABEL TAKES A LINE OF ITS OWN and the controls start at the
bar's edge. A 7rem indent is a third of the 20.75rem a phone leaves inside
the bar, and a filter select beside it would be cut to half its option.
And every label in the bar is then above what it names, the pairs'
(`.toolbar-pair`, below) as well as the line's: a pair beside its control
where it fits and above it where it does not — "Cycle quantity" with the
Fixed count box, the Study Grid's "Output" over a long name — put both
shapes in one form on one screen, the mix the audit flags on every form.
Written as a query, not a container query: the bar is always the page's
full width. (0,2,0) against `.toolbar-pair`'s (0,1,0) on `align-items` and
`gap`.
THE LOG'S FIELDS ARE ITS PAIRS, and on a phone they stack the same way,
since the second round of the audit (2026-09-29). A `.field-inline` is the
Log's label and box as one item, and beside each other at 390 their boxes
started at four x positions, one per label's length, in the one bar on a
phone that kept its labels beside; above, every box starts at its field's
edge. Above 640px the Log's labels stay beside their boxes, where Michael
put them (2026-08-30, "on the left side of the input fileds"). Its Filter
and Clear are one `.row-actions`, so the full-size pair no longer parts —
Clear alone on a line — and the row sits at the foot of the line, level
with the last box rather than with a label. No `align-items` on the
stacked field: the baseline it inherits acts as the start of a column.
(0,2,0) against `.field-inline`'s (0,1,0) on `flex-direction` and `gap`;
nothing else sets the row's `align-self`. */
@media (max-width: 640px) {
.toolbar-line {
padding-left: 0;
}
.toolbar-line > .toolbar-label:first-child {
flex-basis: 100%;
margin-left: 0;
}
.toolbar-line > .toolbar-pair {
flex-direction: column;
align-items: flex-start;
gap: 0.3rem;
}
.toolbar-line > .field-inline {
flex-direction: column;
gap: 0.3rem;
}
.toolbar-line > .row-actions {
align-self: flex-end;
}
/* The cycle quantity takes a line of its own, under the study picker. It is
a label over a select and what the select resolves to, and beside a short
summary it fitted the picker's line on one report and not on the next —
the same bar in two shapes, by the data. (0,3,0), against nothing that
sets a pair's basis. */
.toolbar-line > .toolbar-pair.cycle-pair {
flex-basis: 100%;
}
/* The study summary's cycle bar is the same label, select and button as a
`.row-actions` form rather than a toolbar line. At 16px on a phone the
three no longer fit 332px, and Apply wrapped onto a line of its own at
the left — the "button alone on a line" the Log's filter had just been
rid of. The label goes above, as the report bar's does, and the select
and Apply share the line under it. (0,3,1), against `.row-actions >
.form-label`'s (0,2,0), which sets nothing on the basis. */
.toolbar > form.row-actions > .form-label {
flex-basis: 100%;
}
}
/* A LABEL AND ITS CONTROL ARE ONE ITEM OF THE LINE. Michael, 2026-09-29,
asking for the whole application to be gone over:
so that there is no more supises on lake of gaps, or input fields been
weird dimentions etc.
The report's Filters line was a row of separate flex items — Operator, its
select, Area, its select — and a wrapping flex line breaks between ANY two
items, so at 390 wide every filter's label ended the line above its own
select, beside the previous one. The issue comparison did it at 1440: "Now"
ended the first line and its picker began the second. Wrapped in one
`.toolbar-pair`, a label and its control are a single item, so a line can
break only between pairs. `inline-flex` with the line's own baseline, so the
label reads on the control's text line. A pair wider than the whole line —
on a phone, "Cycle quantity" with its select and the Fixed count box, or
the Study Grid's "Output" over a long quantity name — keeps its label whole
and puts it above the control, as a stacked form would (`flex-wrap`, and
the 0.3rem `.form-label` leaves under itself there); left to shrink, the
label broke over two lines beside the select and the select cut its own
option short. `min-width: 0` and `max-width: 100%` so a control wider
than the line even then — the comparison's issue names — is cut at the bar
(`.toolbar select`, below) instead of pushing the page sideways. A
`.toolbar-label` in a pair names the one control beside it and gives up
the 6rem the line's own label is given. (0,2,0) for that against
`.toolbar-label`'s (0,1,0). */
.toolbar-pair {
display: inline-flex;
flex-wrap: wrap;
align-items: baseline;
gap: 0.3rem 0.5rem;
min-width: 0;
max-width: 100%;
}
.toolbar-pair > .toolbar-label {
min-width: 0;
}
/* A CONTROL'S OWN LABEL, IN A ROW, SITS BESIDE IT. `.form-label` is a block
with a 0.3rem foot for the stacked form it was made for. In a flex row the
block became an item like any other — the observation list's "Lines [ ] to
[ ]" stacked into four lines inside the range — and the foot, which a flex
item's margin does not lose, lifted "reading" and "become" 2.65px above the
selects they name. Inline, with no foot, in the three places a label is
drawn beside its control: a `.toolbar-pair`, an action row, and the
observation list's line range. The report toolbar's filter labels are
`.form-label` for the same reason, since 2026-09-29, and so the Log's size:
they were `.small` at 13px against the Log's 15. (0,2,0) against
`.form-label`'s (0,1,0); the same declarations as `.field-inline
.form-label` in section 14, which is the Log's version of this pair. */
.toolbar-pair > .form-label,
.row-actions > .form-label,
.range-fields > .form-label {
display: inline;
margin-bottom: 0;
}
/* The observation list's line range is one item of its action row — "Lines
[ ] to [ ]" — which section 13 hides whole when "All lines" is ticked. A
flex row of its own, on the row's baseline, so its two boxes and their
labels stay on one line. Section 13's hide-rule is (0,2,1) and wins
`display` outright over this (0,1,0). */
.range-fields {
display: inline-flex;
align-items: baseline;
gap: 0.5rem;
}
/* A PICK LIST IN A BAR HAS TRACKS OF ITS OWN. The study picker on the report,
the Study Grid and New report was a `.card-grid` — section 5's layout for
cards, `minmax(22rem, 1fr)` with 1rem gaps — inside a `` that is a
shrink-to-fit flex item: auto-fit then had room for one 352px track, so the
list opened as one column of studies 38px apart, and on a phone the track
was wider than the 332px bar and, with real study names that did not wrap,
scrolled the whole page sideways to 450px. A tick-box label is a line of
text, not a card: 14rem tracks — or the whole width, whichever is less —
filled as the space allows, and a quarter-line between rows. The labels
wrap now (they were `.nowrap`): section 6's hanging indent keeps a second
line under the name. New report draws the same list in a card, whose gap
spaces it. */
.pick-grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(min(100%, 14rem), 1fr));
gap: 0.25rem 1rem;
}
/* And open, the picker takes the line. A shut `` is its summary's
width; an open one grows to fill what is left of the line (and wraps to a
line of its own below 20rem), so its tracks have room to be tracks and the
controls after it move to the next line, under the indent, instead of
squeezing the list to one column. Its summary is then a heading over the
list, a half-line above the first study rather than flush on it — 0.5rem,
the number `.manual-key[open] > summary` and `.year-group[open] > summary`
use for the same seam. (0,2,1) and (0,2,2), against nothing. */
.toolbar details[open] {
flex: 1 1 20rem;
min-width: 0;
}
.toolbar details[open] > summary {
margin-bottom: 0.5rem;
}
.toolbar .spacer {
margin-left: auto;
}
/* THE BUTTON THAT CLOSES A BAR ENDS ITS LINE ON THE RIGHT, wherever that line
is. The spacer before it pushes it right only while the two share a line,
and a note that fills the line ahead of them — the Study Grid's Output
basis, on real data — sends both to the next, where an empty spacer pushes
nothing: "Show grid" landed at the left under the note, at 1440 on the
production copy and at 1024 on the seeded one, where the report's Apply
and the same button everywhere else end the bar on the right (the second
round of the audit, 2026-09-29). With an auto margin of its own the button
ends its line on the right on its own; sharing a line with the spacer, the
two margins split the free space and it still ends at the edge. (0,3,0),
against nothing that sets a button's margin in a bar. */
.toolbar .spacer + .btn {
margin-left: auto;
}
/* THE BAR'S TEXT BOXES SIZE THEMSELVES, and the reason they did not is NOT the
reason the long form's copy of the same field did not. Michael, 2026-08-29,
naming the symptom on reports/new.html:
Policy CA%, the input filed is under the label deu to been max width
id=f-ca in css: width: 100%
The sentence is true of the toolbar's `#f-ca` as well and the cause is a
different one. On the long form the box carries `input-narrow` and that
class was losing a specificity contest (section 14). Here it carries no
class at all, so nothing was ever trying to narrow it: section 6's
`input[type="text"]` stretched it to the full width of `.toolbar-line`, and a
flex item whose hypothetical size is the whole line is given a line of its
own — which put the box under the label that names it, on a bar whose whole
point is that a filter and its value read as one phrase.
Scoped to the bar rather than pinned on that one box, because every other
control in here already works this way: `select { width: auto }` in section 6
sizes the quantity, mode and filter pickers to their own options, and these
two text boxes were the only things left asking for 100%. The other one is
the Fixed cycle count, which sits two elements deeper inside `.cycle-mode` —
a child combinator would have fixed the visible complaint and left its
neighbour broken, which is the shape of defect this project keeps finding.
What does the sizing is `size` on the inputs themselves: 6 characters for a
percentage, 8 for a cycle count. Specificity (0,2,1) — one class, one
attribute, one type — against section 6's (0,1,1). `max-width` so that a bar
narrower than the box clips it instead of pushing the page sideways.
SECTION 6 IS (0,0,0) SINCE 2026-08-30 and the contest recounted above is
history rather than arithmetic anybody has to redo. This rule is left at
(0,2,1) all the same: it still wins, it is what the test module asserts on,
and re-deriving a selector whose behaviour is unchanged is an edit with no
cause. `max-width: 100%` is the half that never had an opponent and never
needed one. */
.toolbar input[type="text"] {
width: auto;
max-width: 100%;
}
/* AND THE BAR'S SELECTS STOP AT THE BAR. Section 6 leaves a select at `width:
auto`, the width of its longest option, and the issue comparison's two
pickers name each issue in full — "v1 — 4349-DC2-layout/layout-toolbar v1
(2026-09-28, 10 studies)" — so each was 537px wide, ran out of the bar on a
phone and scrolled the whole page sideways to 566px. Capped, a select
longer than the bar shows its option cut at the bar's edge, the failure the
conventions block chose on purpose for the same reason (section 14): the
damage stays inside one control. The version the option starts with is
still read. (0,1,1) against section 6's `select` at (0,0,1).
AND AT LEAST 9rem, since 2026-09-29. A select is as wide as its longest
option, so the report's three filters — each reading "all" until one is
chosen — were 157, 124 and 187px, and different again on the next report,
whose operators have longer descriptions: three pickers saying the same word
at three widths. A floor does not make them equal, and nothing short of
cutting the option text would; it stops the short ones reading as a
different kind of control from the long ones beside them. `min-width` has
no other declaration on a select.
AND WHAT IT CUTS STAYS CUT, IN SAFARI TOO, since the second round of the
audit (2026-09-29). The cap above works in Chromium because Blink clips a
drop-down's content to its box on its own (its computed `overflow` reads
`clip`). WebKit leaves a select at `overflow: visible`, and its theme
overrides any `overflow` an author writes, so the cut-off option text —
about 500px of "v1 — 4349-DC2-layout/layout-toolbar v1 (2026-09-28, 10
studies)" in a 332px box — still counted as the page's overflow: the
comparison scrolled sideways to 540px at 390 in WebKit, into an empty
band. Paint containment clips a box's contents to it in every engine. The
select's own border, outline and focus ring are not its contents, and are
drawn whole. `contain` has no other declaration in the sheet. */
.toolbar select {
max-width: 100%;
min-width: 9rem;
contain: paint;
}
/* A FIELD IN A BAR IS SPACED BY THE BAR, exactly as one in a `.form-inline` is
spaced by the row (section 6, same declaration, same reason).
`.field` carries `margin-bottom: 1rem`, which is right in a stacked form and
wrong in a flex row: `.toolbar-line` is `align-items: center`, and centring
is applied to the item's MARGIN box. A 1rem margin on the bottom and none
on the top therefore lifts the field's contents 0.5rem above every control
beside it that has no margin — the Filter button, the Clear link, the
`.toolbar-label`. Four boxes half a line higher than the button that
submits them is the second half of what Michael reported on the Log:
This should as well equal them in one straight horizontal line.
The bar already spaces its own children: `.toolbar-line` is `gap: 0.4rem
1rem` and `.toolbar` `gap: 0.5rem 1.5rem`, and a margin does not collapse
inside a flex container, it adds. Specificity (0,2,0) against `.field`'s
(0,1,0).
`.toolbar-line` aligns on the baseline since 2026-09-29 (above), where a
margin no longer lifts anything; the bar's own `align-items: center` still
centres, and a wrapped line's height still counts the margin. The rule
stays for both. */
.toolbar .field {
margin-bottom: 0;
}
.legend {
display: flex;
flex-wrap: wrap;
gap: 0.4rem 0.9rem;
align-items: center;
color: var(--muted);
font-size: 0.85rem;
}
/* ----------------------------------------------------------------- 11 */
/* The fleet login page, non-Bootstrap variant: 56px logo centred INSIDE
the card, muted subtitle, no page heading, large inputs, full-width
submit. Everything is scoped to .login-card so no other card shifts.
AND IT IS THE ONE AUTH CARD, since 2026-09-29. Four screens ask for a
credential — sign in, the second factor, the password change and the
two-factor enrolment — and they were built two ways: the two sign-in steps
as this card, with boxes as tall as the large button under them, and the
other two as plain cards whose 34px boxes sat over the same 41px button.
The audit Michael asked for ("so that there is no more supises on lake of
gaps, or input fields been weird dimentions etc.") found the pair. All four
are this card now, and this is the whole of its spec:
- the 420px column, `main.auth`, and this shadow;
- boxes the large button's height, 41.34px, and the card's width;
- fields 1rem apart, in the block of their `