/* PROGRESS
A multi-step process that is worked through over time, reported as a row of
counted steps with a decision row above it and the completing row below.
For a process somebody comes back to across days and wants to ask "how much
is left" of. Not for a single loading bar, and not for a wizard: nothing here
moves anybody between screens, and the steps can be done in any order.
Three parts:
.tt-progress-row the line above the steps, and the line below them
.tt-progress-steps the grid of counted steps
.tt-progress-step one step, its own count, its own control
It was built for closing a production - jobs archived, hours in a payroll,
payrolls settled, registration shut, crew data cleared - and the sizes are
tuned to five steps in a card.
It also reads as a report of what is outstanding, which is the same question
asked once rather than over days: the per diem rates on a payroll are sorted
into what a run can move, what is too late to move, and what was typed on
purpose, one tile each with its own count and its own remedy. Such a tile drops
the bar - a fuller bucket there is a worse result, so a filling bar would run
the wrong way - and is never --done, since a bucket with nothing in it is left
out rather than shown green. The top row takes --caution instead, and a report
whose tiles already say what to do about themselves can end on the steps rather
than invent a closing row to fill.
*/
/* PROGRESS ROW
The line that bookends the steps: where the whole process stands, and the one
control that moves it.
One class for both ends, because they are two readings of one fact and should
not look like different kinds of thing. Text on the left, control on the
right, a rule between it and the steps.
A line rather than a panel, because what the process costs is written on the
steps themselves. This row only has to say what has and has not happened.
Both ends stay put in every state. Swapping a panel for a line the moment
somebody presses the button read as the screen taking something away, and a
control that only materialises once some unstated condition is met is one
people hunt for - so the closing row is present and disabled instead, with
the text beside it naming what is missing.
Usage:
Closing started on 15.09.2026.
…steps…
All 5 steps are done.
Modifiers:
--top sits above the steps; rule underneath
--bottom sits below the steps; rule over
--ready nothing is outstanding; the state line comes up to full strength
--caution the row reports a problem; colours the state line's leading icon
*/
.tt-progress-row {
display: flex;
flex-wrap: wrap;
align-items: center;
justify-content: space-between;
gap: var(--space-2xs);
}
.tt-progress-row--top {
padding-block-end: var(--space-2xs);
border-block-end: var(--border-thin) solid var(--border-muted);
}
.tt-progress-row--bottom {
margin-block-start: var(--space-xs);
padding-block-start: var(--space-xs);
border-block-start: var(--border-thin) solid var(--border-muted);
}
/* Wraps under the text on a phone, where side by side would squeeze both. The
text takes what it needs and the control keeps its own width. */
.tt-progress-row-state {
margin: 0;
flex: 1 1 18rem;
font-size: var(--step--1);
color: var(--text-muted);
}
/* Full strength once there is nothing left to wait for: this is the sentence
that says the work is over, and reading it as muted fine print next to a live
primary button is the wrong way round. */
.tt-progress-row--ready .tt-progress-row-state {
color: var(--text-color);
}
/* Not every process is neutral. A report of what is wrong - per diems priced at
a figure their rate set no longer states - is the same shape as a checklist and
wants the same three parts, but its top row has to say so.
The glyph carries the signal and nothing else changes, because the panel around
it should not have to: a block of colour the width of the screen is what this
shape exists to replace.
--warning-border-color rather than --warning-color, for the same reason the
step note's icon uses it - the lighter one is a fill and disappears against
one. */
.tt-progress-row--caution .tt-progress-row-icon {
color: var(--warning-border-color);
}
/* Keeps the control its own width in the flex row rather than letting it
stretch with the text beside it.
There is deliberately no width override on the button itself, here or on the
steps. .tt-btn is inline-flex and a full-width button needs an explicit
.tt-btn-100, so .tt-form never stretched anything - an override "correcting"
it only outranks the width classes a caller did ask for, which is how
.tt-btn-75 on the archive button stopped working. */
.tt-form.tt-progress-row-form {
flex: 0 0 auto;
}
/* Disabled until the steps are green. Dimmed rather than hidden, and with the
cursor saying so on hover, because the row beside it is already explaining
what is missing. */
.tt-progress-row-form .tt-btn:disabled {
opacity: 0.5;
cursor: not-allowed;
}
/* PROGRESS STEPS
The steps themselves: the things that have to be true before the process is
finished.
A step reports its own real count - 42 of 60 jobs, 1 of 2 payrolls - with the
scale beside it set small, so that five steps scan as five big numbers rather
than as ten. The scale is the denominator on a checklist step and the unit on a
report tile, which has no denominator to lean on. A step with nothing to count,
like a switch, shows a word in the figure's place.
Only the bar is scaled to 100, because it is the one part read across all the
steps at once, and bars of unlike lengths would say nothing.
A step is a card, not a row, because it can carry the control that moves it
along: archiving the jobs happens inside its own step, beside the number it
changes.
Usage:
Jobs archived
42/ 60
42 of 60 archived, 18 still open.
Modifier:
--done the step is finished; success colouring and a tick
A step also carries .tt-progress-step-note - what the step means, as opposed
to the detail line's what it currently says - with a --caution variant for a
step that deletes something permanently.
*/
.tt-progress-steps {
display: grid;
/* Two up on a full-width card, one up on a phone. The floor is set by the
widest thing a step holds - a form's select and button side by side -
rather than by the text. */
grid-template-columns: repeat(auto-fit, minmax(17rem, 1fr));
gap: var(--space-2xs);
margin-block: var(--space-s);
}
/* The margins are the gaps either side of a row. A card that opens or ends on the
steps - a report that needs no heading over them, or has nothing to say
underneath - has no row to be kept away from, so the margin would only be the
card's own padding a second time. */
.tt-progress-steps:first-child {
margin-block-start: 0;
}
.tt-progress-steps:last-child {
margin-block-end: 0;
}
/* --cards: the steps are the whole of it, standing on the page rather than inside
a card.
For a report with no rows. Once the heading and the closing line are gone, the
card around the grid is a surface whose only job is to hold another surface -
two borders and two paddings to say one thing - and the muted tiles inside it
are muted because they are sitting on something. Take the card away and each
tile becomes what the shape always called it: a card in its own right, the same
background, border and shadow as the cards above and below it in the column.
Its own margin is a card's margin, so the grid sits in the page flow like the
thing it now is. Written doubled to outrank the :first-child and :last-child
rules above, which are about a grid inside a card and have nothing to say here.
A checklist keeps the card. Its steps are read between a state line and a
closing control that belong to the same panel, and pulling them apart would
leave those two rows floating. */
.tt-progress-steps.tt-progress-steps--cards {
margin-block: 0 var(--space-xs);
}
.tt-progress-steps--cards .tt-progress-step {
background-color: var(--bg-color);
box-shadow: var(--box-shadow);
}
.tt-progress-step {
display: flex;
flex-direction: column;
gap: var(--space-3xs);
padding: var(--space-xs) var(--space-s);
background-color: var(--bg-muted);
border: var(--border-thin) solid var(--border-muted);
border-radius: 0.5rem;
}
/* --caution: this step is reporting trouble.
The border, and nothing else. It is the tile-level answer to
tt-progress-row--caution, and it exists because a report with no row has
nowhere else to put the colour: a card around the grid could only be one
colour for the lot, which on a payroll meant tiles that need a decision and
tiles that are somebody having done their job sharing a yellow border.
Not the icon, though the row colours its own. The row's icon is the warning -
one mark at the head of a line of text, and the only thing on that line that
can carry a state. A step's icon is a label's bullet, saying what the tile
counts rather than how it is doing: per diems, crew, jobs. Colouring it says
the per diems are the trouble.
No tint either, though --done has one. Green on a finished step is a reward
and reads once; yellow behind every tile of a card that only appears when
something is wrong is the wide block of colour this shape exists to replace. */
.tt-progress-step--caution {
border-color: var(--warning-color);
}
/* A tint rather than the solid --success-color: four saturated mint panels
would shout, and the tick plus the full bar already say "done". Mixed with
--bg-color so the same rule lands correctly in both themes. */
.tt-progress-step--done {
background-color: color-mix(in srgb, var(--success-color) 12%, var(--bg-color));
border-color: var(--success-border-color);
}
.tt-progress-step-head {
display: flex;
align-items: center;
gap: var(--space-3xs);
}
.tt-progress-step-icon {
/* Cancels the 0.25em .tt-icon carries for inline runs of text; the flex gap
is doing the spacing here. */
margin: 0;
flex-shrink: 0;
/* No colour of its own, so it inherits and comes out at the label's weight.
The two are one head line - the icon is the label's bullet, saying what the
step counts - and setting the icon muted split them, leaving a grey mark
beside black text as though it were a lesser part of the same phrase.
--done still overrides it below, where the colour is the state. */
}
.tt-progress-step--done .tt-progress-step-icon {
color: var(--success-border-color);
}
.tt-progress-step-label {
font-size: var(--step--1);
font-weight: var(--font-weight-medium);
}
.tt-progress-step-figure {
font-size: var(--step-2);
font-weight: var(--font-weight-medium);
line-height: 1.2;
/* Tabular figures so the number does not jog sideways between runs. */
font-variant-numeric: tabular-nums;
}
.tt-progress-step--done .tt-progress-step-figure {
color: var(--success-border-color);
}
/* What the figure is counted in, and what out of: "/ 60" on a checklist step,
"per diems" or "of 12 per diems" on a report tile. Context either way, not the
reading - kept small and muted so a row of steps scans as 42 · 1 · Off · 8
rather than as eight competing numbers.
A checklist step can leave it off, because its denominator is the only scale
the number needs and the label above supplies the unit. A report tile cannot:
with one tile there is no denominator, and a bare 7 is a number with no unit
and no size. */
.tt-progress-step-scale {
margin-inline-start: 0.2em;
font-size: var(--step--1);
font-weight: var(--font-weight-normal);
color: var(--text-muted);
}
.tt-progress-step-bar {
block-size: 0.3rem;
border-radius: 0.3rem;
background-color: color-mix(in srgb, var(--text-muted) 30%, transparent);
overflow: hidden;
}
.tt-progress-step-bar-fill {
display: block;
block-size: 100%;
border-radius: inherit;
background-color: var(--primary-color);
/* A run that reloads the page brings the bar to its new width rather than
growing it. The transition is for anything that updates one in place. */
transition: inline-size 0.3s ease;
}
.tt-progress-step--done .tt-progress-step-bar-fill {
background-color: var(--success-border-color);
}
.tt-progress-step-detail {
margin: 0;
font-size: var(--step--2);
color: var(--text-muted);
}
/* margin-block-start:auto pins whatever acts on the step to the bottom of it,
so the controls line up across a row of steps whose detail lines run to
different lengths. */
.tt-progress-step-form,
.tt-progress-step-action {
margin-block-start: auto;
padding-block-start: var(--space-2xs);
}
/* Placement and size only. The link itself is a .tt-link.tt-link-inline, so the
colour and hover come from the one place every other link in the app gets
them, and a step's link cannot drift away from the rest. */
.tt-progress-step-action {
font-size: var(--step--2);
}
/* The standing explanation of a step, under the live detail line. Muted and set
below the number, because it is the sentence you read once and the detail is
the one you come back for. Also carries any note under a step's own form,
which plays the same role. */
.tt-progress-step-note {
margin: var(--space-3xs) 0 0;
font-size: var(--step--2);
color: var(--text-muted);
}
/* A step that deletes data which cannot be recovered must not read as the same
kind of fine print as the rest.
Not an alert box: a yellow panel inside a step would fight the row of steps it
sits in. Full-strength text and a warning rule instead - the colour carries
the signal and the text carries the contrast, which is deliberate, since
--warning-border-color is a dark yellow that is legible as a rule or an icon
and not as a paragraph. */
.tt-progress-step-note--caution {
color: var(--text-color);
padding-inline-start: var(--space-3xs);
border-inline-start: var(--border-md) solid var(--warning-border-color);
}
.tt-progress-step-note-icon {
/* Cancels .tt-icon's inline run spacing; the icon leads the sentence. */
margin: 0;
color: var(--warning-border-color);
vertical-align: -0.15em;
}