fix: toasts were covering the navigation bar's controls
Six keyboard-shortcuts e2e tests started failing on CI: clicking the search
glyph was refused because a `mantine-Notification-title` was on top of it.
The toast container is fixed at `top: var(--mantine-spacing-md)` -- 16px --
while the bar occupies the first 54px of the page. Every toast has therefore
been landing on the bar's right-hand corner: the search glyph, the hamburger,
Help and Admin. For as long as the toast is up those controls cannot be
clicked, and an error toast is precisely the moment a user reaches for Admin.
It surfaced now because the previous commit gave the search glyph a proper hit
area. At 18px it sat in the gap beneath the toast; grown to the height of the
bar, it moved into the overlap. The toast has been covering that corner all
along -- there was nothing there to hit. So this is not a test that needs
loosening: CI found a real defect that predates the change that exposed it.
Toasts now start below the bar. `--navbar-height` is shared between the bar's
min-height and the offset so the two cannot drift, and the rule matches
`[data-position^='top']` so a future move to bottom-right does not silently
inherit a top offset. Mantine's own positioning uses `:where()`, which has zero
specificity, so a single class wins.
Tested by `elementFromPoint` rather than by comparing rectangles: that is the
question Cypress's actionability check asks and the one a mouse asks. A
geometry test would miss a toast that overlaps but sits behind, and a z-index
test would miss one that is in front but elsewhere on screen. Three cases --
the search control, every control in the corner, and the offset itself, which is
stated separately because the first two would also pass on a toast that merely
happened to be narrow enough to miss at one viewport. Removing the offset
reddens all three.
Confirmed on the running app with a real error toast up: toast top 70px, bar
bottom 54px, all six corner controls topmost at their own centres. The e2e
spec passes locally, 12 of 12.
1124 jest / 62 suites, 199 in ui-layout.cy.js, clean npm run build.
2026-08-02 15:55:26 -06:00
|
|
|
:root {
|
|
|
|
|
/* Shared with the toast offset below, so the two cannot drift apart. */
|
|
|
|
|
--navbar-height: 3.4em;
|
|
|
|
|
}
|
|
|
|
|
|
ui: the navbar measures its foreground instead of assuming one
The bar's background is the one surface a user picks -- twelve colour names,
which each theme resolves to twelve of its own colours. Forty-eight
backgrounds, and the links and status icons were drawn on all of them in a
single token, `--btn-text`, which is near-black in three of the four themes.
Night's `--brown` is #451212. A near-black glyph on it is 1.33:1. Nine of
night's twelve colours and seven of amber's sat below 4.5:1, and twelve of the
forty-eight below 3:1 -- icons the same colour as the bar behind them.
So the foreground is measured against the background the theme actually
resolved, choosing between that theme's own `--btn-text`, `--black` and
`--white`. Its own, not literal ones: a white pixel in night mode undoes the
dark adaptation the theme exists to protect, so night's "white" is #ff8a8a.
Measuring at runtime rather than shipping an `--on-red` token per colour also
means the custom YAML themes still ahead get this for free.
Nothing is below 3:1 any more and the worst case is 3.27:1, up from 1.33:1.
No combination is worse than it was.
Ten of the forty-eight are still under 4.5:1 and no foreground will lift them:
a monochrome theme resolves all twelve names onto one ramp, and a mid-tone of a
hue cannot carry text of that same hue. That shortfall is in the palette, so
/theme-sample now draws all twelve bars with the measured ratio printed beside
each one, calling out the ten -- it is a decision to make while looking at them.
The WCAG primitives move to themes/contrast so theme code can measure a colour
without importing Common.js, which pulls in half the component library.
Common.js forwards `contrastRatio` with a delegating function rather than a bare
re-export: six specs mock it with `{...jest.requireActual('./Common')}`, the
spread invokes every getter, and those spreads run re-entrantly while the module
is still evaluating -- a re-export getter fires before its import binding exists
and takes the whole suite down.
Tested: navColors.test.js measures all forty-eight against the palette parsed
out of tokens.css, and holds Nav.js to the call by source since neither bar is
reachable from a test that could measure it. ui-layout.cy.js measures the
painted result in a real browser in all four themes and holds it against the
number the component reports. Reverting to the fixed foreground reddens four
jest cases and three cypress ones.
1115 jest / 62 suites, 177 in ui-layout.cy.js, clean npm run build.
2026-08-02 14:07:19 -06:00
|
|
|
/* Nav bar: a hand-rolled flexbox bar (was a Semantic Menu). The user-chosen background
|
|
|
|
|
and the foreground measured against it are set inline (see themes/navColors); this
|
|
|
|
|
stylesheet only supplies structure and hover affordances. */
|
2026-07-30 13:15:43 -06:00
|
|
|
.wrolpi-navbar {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: stretch;
|
ui: the last Semantic UI file, and the stylesheet with it
ControllerPage was the final call site; Theme.tsx then had nothing left to wrap,
so it drops from 861 lines to 338 -- the provider that resolves the theme, stamps
`data-theme` and `data-media-filter`, persists both and hands Mantine our tokens.
Everything below that was Semantic wrappers.
The dark-mode compatibility props went with them. `i`, `s`, `t` and `inverted`
existed so unmigrated components could borrow Semantic's dark treatment, and
they carried hardcoded greys -- #1B1C1D, #dddddd, #eeeeee -- which is exactly
what the token themes replaced. Three call sites in Common.js were still
injecting the #eeeeee one into links.
Then `semantic-ui-offline/semantic.min.css` came out of App.js. That took more
with it than expected, and looking at the running app is the only reason it was
caught:
Every link lost its colour and gained the browser's underline and visited
purple. The dashboard's load averages and section headings were underlined
and purple. Links now take `--blue`, which remaps per theme, and underline
only on hover -- many of them wrap cards, posters and icons.
`box-sizing: border-box` disappeared, which silently changes the size of every
padded element in the app. Semantic's reset had been providing it.
The navigation bar overflowed a 1000px viewport with `nowrap` and cut "Admin"
off the right edge -- the one link a user needs to reach the settings that fix
a broken WROLPi. Semantic's menu wrapped; ours does now too.
The gzipped CSS bundle is 47.5 kB, and one call site was still leaning on
Semantic's grid classes -- now a flex column, since all three of its callers
pass library components.
The ratchet stays rather than being deleted. At zero it asserts four things: no
file imports Semantic UI, none calls its toast library, none leans on its
stylesheet, and no file reaches back through Theme.tsx. It can go when the
packages are uninstalled.
Theme.test.js is deleted, but not before porting the two behaviours it
protected: that Button forwards a ref to the real DOM element (a class-component
ref once crashed the Control page, because portals call `node.contains`), and
that the progress percentage stays readable on every bar colour.
2026-07-30 13:41:05 -06:00
|
|
|
/*
|
|
|
|
|
* Wraps rather than clipping. Semantic's menu wrapped, and with this many items the
|
|
|
|
|
* bar overflows a 1000px viewport -- `nowrap` cut "Admin" off the right edge, which
|
|
|
|
|
* is the one link a user needs to reach the settings that fix a broken WROLPi.
|
|
|
|
|
*/
|
|
|
|
|
flex-wrap: wrap;
|
fix: toasts were covering the navigation bar's controls
Six keyboard-shortcuts e2e tests started failing on CI: clicking the search
glyph was refused because a `mantine-Notification-title` was on top of it.
The toast container is fixed at `top: var(--mantine-spacing-md)` -- 16px --
while the bar occupies the first 54px of the page. Every toast has therefore
been landing on the bar's right-hand corner: the search glyph, the hamburger,
Help and Admin. For as long as the toast is up those controls cannot be
clicked, and an error toast is precisely the moment a user reaches for Admin.
It surfaced now because the previous commit gave the search glyph a proper hit
area. At 18px it sat in the gap beneath the toast; grown to the height of the
bar, it moved into the overlap. The toast has been covering that corner all
along -- there was nothing there to hit. So this is not a test that needs
loosening: CI found a real defect that predates the change that exposed it.
Toasts now start below the bar. `--navbar-height` is shared between the bar's
min-height and the offset so the two cannot drift, and the rule matches
`[data-position^='top']` so a future move to bottom-right does not silently
inherit a top offset. Mantine's own positioning uses `:where()`, which has zero
specificity, so a single class wins.
Tested by `elementFromPoint` rather than by comparing rectangles: that is the
question Cypress's actionability check asks and the one a mouse asks. A
geometry test would miss a toast that overlaps but sits behind, and a z-index
test would miss one that is in front but elsewhere on screen. Three cases --
the search control, every control in the corner, and the offset itself, which is
stated separately because the first two would also pass on a toast that merely
happened to be narrow enough to miss at one viewport. Removing the offset
reddens all three.
Confirmed on the running app with a real error toast up: toast top 70px, bar
bottom 54px, all six corner controls topmost at their own centres. The e2e
spec passes locally, 12 of 12.
1124 jest / 62 suites, 199 in ui-layout.cy.js, clean npm run build.
2026-08-02 15:55:26 -06:00
|
|
|
min-height: var(--navbar-height);
|
2026-07-30 13:15:43 -06:00
|
|
|
padding: 0 0.25em;
|
|
|
|
|
}
|
|
|
|
|
|
fix: toasts were covering the navigation bar's controls
Six keyboard-shortcuts e2e tests started failing on CI: clicking the search
glyph was refused because a `mantine-Notification-title` was on top of it.
The toast container is fixed at `top: var(--mantine-spacing-md)` -- 16px --
while the bar occupies the first 54px of the page. Every toast has therefore
been landing on the bar's right-hand corner: the search glyph, the hamburger,
Help and Admin. For as long as the toast is up those controls cannot be
clicked, and an error toast is precisely the moment a user reaches for Admin.
It surfaced now because the previous commit gave the search glyph a proper hit
area. At 18px it sat in the gap beneath the toast; grown to the height of the
bar, it moved into the overlap. The toast has been covering that corner all
along -- there was nothing there to hit. So this is not a test that needs
loosening: CI found a real defect that predates the change that exposed it.
Toasts now start below the bar. `--navbar-height` is shared between the bar's
min-height and the offset so the two cannot drift, and the rule matches
`[data-position^='top']` so a future move to bottom-right does not silently
inherit a top offset. Mantine's own positioning uses `:where()`, which has zero
specificity, so a single class wins.
Tested by `elementFromPoint` rather than by comparing rectangles: that is the
question Cypress's actionability check asks and the one a mouse asks. A
geometry test would miss a toast that overlaps but sits behind, and a z-index
test would miss one that is in front but elsewhere on screen. Three cases --
the search control, every control in the corner, and the offset itself, which is
stated separately because the first two would also pass on a toast that merely
happened to be narrow enough to miss at one viewport. Removing the offset
reddens all three.
Confirmed on the running app with a real error toast up: toast top 70px, bar
bottom 54px, all six corner controls topmost at their own centres. The e2e
spec passes locally, 12 of 12.
1124 jest / 62 suites, 199 in ui-layout.cy.js, clean npm run build.
2026-08-02 15:55:26 -06:00
|
|
|
/*
|
|
|
|
|
* Toasts start below the navigation bar instead of on top of it.
|
|
|
|
|
*
|
|
|
|
|
* They are fixed at `top: var(--mantine-spacing-md)` -- 16px -- while the bar occupies the
|
|
|
|
|
* first 54px of the page, so every toast landed over the bar's right-hand corner: the search
|
|
|
|
|
* glyph, the hamburger, Help and Admin. For as long as the toast was up those controls could
|
|
|
|
|
* not be clicked, and an error toast is exactly when a user reaches for Admin.
|
|
|
|
|
*
|
|
|
|
|
* It went unnoticed until the search glyph was given a proper hit area: at 18px it sat in the
|
|
|
|
|
* gap under the toast, and growing it to the height of the bar moved it into the overlap.
|
|
|
|
|
* The toast was always covering that corner; there was just nothing there to hit.
|
|
|
|
|
*
|
|
|
|
|
* `:where()` gives Mantine's own rule zero specificity, so one class is enough to win, but
|
|
|
|
|
* the attribute is matched too -- only the top-anchored positions need moving, and a future
|
|
|
|
|
* switch to `bottom-right` should not silently inherit a top offset.
|
|
|
|
|
*/
|
|
|
|
|
html .mantine-Notifications-root[data-position^='top'] {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
top: calc(var(--navbar-height) + var(--mantine-spacing-md, 1rem));
|
fix: toasts were covering the navigation bar's controls
Six keyboard-shortcuts e2e tests started failing on CI: clicking the search
glyph was refused because a `mantine-Notification-title` was on top of it.
The toast container is fixed at `top: var(--mantine-spacing-md)` -- 16px --
while the bar occupies the first 54px of the page. Every toast has therefore
been landing on the bar's right-hand corner: the search glyph, the hamburger,
Help and Admin. For as long as the toast is up those controls cannot be
clicked, and an error toast is precisely the moment a user reaches for Admin.
It surfaced now because the previous commit gave the search glyph a proper hit
area. At 18px it sat in the gap beneath the toast; grown to the height of the
bar, it moved into the overlap. The toast has been covering that corner all
along -- there was nothing there to hit. So this is not a test that needs
loosening: CI found a real defect that predates the change that exposed it.
Toasts now start below the bar. `--navbar-height` is shared between the bar's
min-height and the offset so the two cannot drift, and the rule matches
`[data-position^='top']` so a future move to bottom-right does not silently
inherit a top offset. Mantine's own positioning uses `:where()`, which has zero
specificity, so a single class wins.
Tested by `elementFromPoint` rather than by comparing rectangles: that is the
question Cypress's actionability check asks and the one a mouse asks. A
geometry test would miss a toast that overlaps but sits behind, and a z-index
test would miss one that is in front but elsewhere on screen. Three cases --
the search control, every control in the corner, and the offset itself, which is
stated separately because the first two would also pass on a toast that merely
happened to be narrow enough to miss at one viewport. Removing the offset
reddens all three.
Confirmed on the running app with a real error toast up: toast top 70px, bar
bottom 54px, all six corner controls topmost at their own centres. The e2e
spec passes locally, 12 of 12.
1124 jest / 62 suites, 199 in ui-layout.cy.js, clean npm run build.
2026-08-02 15:55:26 -06:00
|
|
|
}
|
|
|
|
|
|
2026-07-30 13:15:43 -06:00
|
|
|
.wrolpi-navbar-right {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
margin-left: auto;
|
|
|
|
|
gap: 0.2em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.wrolpi-navbar-link,
|
|
|
|
|
.wrolpi-navbar-link-button {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
ui: the last Semantic UI file, and the stylesheet with it
ControllerPage was the final call site; Theme.tsx then had nothing left to wrap,
so it drops from 861 lines to 338 -- the provider that resolves the theme, stamps
`data-theme` and `data-media-filter`, persists both and hands Mantine our tokens.
Everything below that was Semantic wrappers.
The dark-mode compatibility props went with them. `i`, `s`, `t` and `inverted`
existed so unmigrated components could borrow Semantic's dark treatment, and
they carried hardcoded greys -- #1B1C1D, #dddddd, #eeeeee -- which is exactly
what the token themes replaced. Three call sites in Common.js were still
injecting the #eeeeee one into links.
Then `semantic-ui-offline/semantic.min.css` came out of App.js. That took more
with it than expected, and looking at the running app is the only reason it was
caught:
Every link lost its colour and gained the browser's underline and visited
purple. The dashboard's load averages and section headings were underlined
and purple. Links now take `--blue`, which remaps per theme, and underline
only on hover -- many of them wrap cards, posters and icons.
`box-sizing: border-box` disappeared, which silently changes the size of every
padded element in the app. Semantic's reset had been providing it.
The navigation bar overflowed a 1000px viewport with `nowrap` and cut "Admin"
off the right edge -- the one link a user needs to reach the settings that fix
a broken WROLPi. Semantic's menu wrapped; ours does now too.
The gzipped CSS bundle is 47.5 kB, and one call site was still leaning on
Semantic's grid classes -- now a flex column, since all three of its callers
pass library components.
The ratchet stays rather than being deleted. At zero it asserts four things: no
file imports Semantic UI, none calls its toast library, none leans on its
stylesheet, and no file reaches back through Theme.tsx. It can go when the
packages are uninstalled.
Theme.test.js is deleted, but not before porting the two behaviours it
protected: that Button forwards a ref to the real DOM element (a class-component
ref once crashed the Control page, because portals call `node.contains`), and
that the progress percentage stays readable on every bar colour.
2026-07-30 13:41:05 -06:00
|
|
|
/* Tightened from 1.1em: the bar has eleven links plus nine indicators. */
|
|
|
|
|
padding: 0 0.8em;
|
2026-07-30 13:15:43 -06:00
|
|
|
color: inherit;
|
|
|
|
|
text-decoration: none;
|
|
|
|
|
white-space: nowrap;
|
|
|
|
|
background: none;
|
|
|
|
|
border: none;
|
|
|
|
|
font: inherit;
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.wrolpi-navbar-link:hover,
|
|
|
|
|
.wrolpi-navbar-link-button:hover {
|
style: spell it "color" everywhere
283 occurrences across 23 files, all of them mine and all of them in the
theme/UI work: comments, test names, and a handful of local identifiers
(`colours`, `roleColours`, `awaitColoured`) plus one test fixture tag named
'Uncoloured'.
Nothing was required to keep the other spelling. Checked before replacing: no
CSS custom property or class name contains it, no library prop or API key does,
and every string holding it is a test name or our own copy. The renamed
identifiers were checked for collisions with an existing `color`/`colors` in the
same file first -- there were none.
Verified as a pure rename: 262 lines changed, and normalising the spelling on
every removed line reproduces the added line exactly, for all 262. So the diff
contains no other edit hiding in it.
1134 jest / 64 suites, 271 cypress component tests with the same 12 pre-existing
Semantic-era failures in Tags/Channels/Download/Inventory, clean npm run build.
2026-08-02 18:02:44 -06:00
|
|
|
/* A translucent black works on every navbar color, light or dark. */
|
ui: the last Semantic UI file, and the stylesheet with it
ControllerPage was the final call site; Theme.tsx then had nothing left to wrap,
so it drops from 861 lines to 338 -- the provider that resolves the theme, stamps
`data-theme` and `data-media-filter`, persists both and hands Mantine our tokens.
Everything below that was Semantic wrappers.
The dark-mode compatibility props went with them. `i`, `s`, `t` and `inverted`
existed so unmigrated components could borrow Semantic's dark treatment, and
they carried hardcoded greys -- #1B1C1D, #dddddd, #eeeeee -- which is exactly
what the token themes replaced. Three call sites in Common.js were still
injecting the #eeeeee one into links.
Then `semantic-ui-offline/semantic.min.css` came out of App.js. That took more
with it than expected, and looking at the running app is the only reason it was
caught:
Every link lost its colour and gained the browser's underline and visited
purple. The dashboard's load averages and section headings were underlined
and purple. Links now take `--blue`, which remaps per theme, and underline
only on hover -- many of them wrap cards, posters and icons.
`box-sizing: border-box` disappeared, which silently changes the size of every
padded element in the app. Semantic's reset had been providing it.
The navigation bar overflowed a 1000px viewport with `nowrap` and cut "Admin"
off the right edge -- the one link a user needs to reach the settings that fix
a broken WROLPi. Semantic's menu wrapped; ours does now too.
The gzipped CSS bundle is 47.5 kB, and one call site was still leaning on
Semantic's grid classes -- now a flex column, since all three of its callers
pass library components.
The ratchet stays rather than being deleted. At zero it asserts four things: no
file imports Semantic UI, none calls its toast library, none leans on its
stylesheet, and no file reaches back through Theme.tsx. It can go when the
packages are uninstalled.
Theme.test.js is deleted, but not before porting the two behaviours it
protected: that Button forwards a ref to the real DOM element (a class-component
ref once crashed the Control page, because portals call `node.contains`), and
that the progress percentage stays readable on every bar colour.
2026-07-30 13:41:05 -06:00
|
|
|
background: rgba(0, 0, 0, 0.12);
|
2026-07-30 13:15:43 -06:00
|
|
|
}
|
|
|
|
|
|
ui: the corner icons opt out of the bar's foreground, so make them stop
Measuring the foreground against the bar is worth nothing if the icons ignore
it, and two of them did -- the search glyph and the hamburger came out blue on
every bar in every theme while the rest of the bar was correct.
Neither inherits. An anchor takes `a {color: var(--blue)}` from tokens.css,
which outranks an inherited value however the bar sets it; the search glyph is
an anchor. A Mantine ActionIcon paints `--ai-color`, its own themed blue, and
Mantine writes that variable INLINE on the element, so a stylesheet declaring it
loses every time -- the painted property has to be set instead. The status
icons that link to /admin are anchors too, and only looked right because they
carry an inline colour of their own, which still wins and is meant to.
The test that claimed to cover this read `querySelector('...svg')`: one element,
the first, which was a plain inheriting Icon. It asserted every icon and
measured the only one that was never broken. It now reads querySelectorAll,
asserts the count, and checks all four -- and reddens in all four themes with
the rule removed, naming --blue as the value it found.
The gallery sample was wrong in the same direction: it used an IconButton for
the search icon, so it showed the ActionIcon fault twice and hid the anchor
fault entirely. It now carries all three shapes the real bar puts in that
corner.
1115 jest / 62 suites, 177 in ui-layout.cy.js, clean npm run build.
2026-08-02 14:12:39 -06:00
|
|
|
/*
|
|
|
|
|
* Everything in the bar takes the bar's foreground.
|
|
|
|
|
*
|
|
|
|
|
* `color: inherit` on the links alone was not enough, because two of the things in the
|
|
|
|
|
* corner do not inherit at all and both came out blue on every bar in every theme:
|
|
|
|
|
*
|
|
|
|
|
* - An anchor takes `a {color: var(--blue)}` from tokens.css, which outranks an inherited
|
|
|
|
|
* value however the bar sets it. The search glyph is an anchor, and so is every status
|
|
|
|
|
* icon that links to /admin -- those only looked right because they carry an inline
|
style: spell it "color" everywhere
283 occurrences across 23 files, all of them mine and all of them in the
theme/UI work: comments, test names, and a handful of local identifiers
(`colours`, `roleColours`, `awaitColoured`) plus one test fixture tag named
'Uncoloured'.
Nothing was required to keep the other spelling. Checked before replacing: no
CSS custom property or class name contains it, no library prop or API key does,
and every string holding it is a test name or our own copy. The renamed
identifiers were checked for collisions with an existing `color`/`colors` in the
same file first -- there were none.
Verified as a pure rename: 262 lines changed, and normalising the spelling on
every removed line reproduces the added line exactly, for all 262. So the diff
contains no other edit hiding in it.
1134 jest / 64 suites, 271 cypress component tests with the same 12 pre-existing
Semantic-era failures in Tags/Channels/Download/Inventory, clean npm run build.
2026-08-02 18:02:44 -06:00
|
|
|
* color of their own, which still wins here and is meant to.
|
ui: the corner icons opt out of the bar's foreground, so make them stop
Measuring the foreground against the bar is worth nothing if the icons ignore
it, and two of them did -- the search glyph and the hamburger came out blue on
every bar in every theme while the rest of the bar was correct.
Neither inherits. An anchor takes `a {color: var(--blue)}` from tokens.css,
which outranks an inherited value however the bar sets it; the search glyph is
an anchor. A Mantine ActionIcon paints `--ai-color`, its own themed blue, and
Mantine writes that variable INLINE on the element, so a stylesheet declaring it
loses every time -- the painted property has to be set instead. The status
icons that link to /admin are anchors too, and only looked right because they
carry an inline colour of their own, which still wins and is meant to.
The test that claimed to cover this read `querySelector('...svg')`: one element,
the first, which was a plain inheriting Icon. It asserted every icon and
measured the only one that was never broken. It now reads querySelectorAll,
asserts the count, and checks all four -- and reddens in all four themes with
the rule removed, naming --blue as the value it found.
The gallery sample was wrong in the same direction: it used an IconButton for
the search icon, so it showed the ActionIcon fault twice and hid the anchor
fault entirely. It now carries all three shapes the real bar puts in that
corner.
1115 jest / 62 suites, 177 in ui-layout.cy.js, clean npm run build.
2026-08-02 14:12:39 -06:00
|
|
|
* - A Mantine ActionIcon paints `--ai-color`, its own themed blue. The hamburger and the
|
|
|
|
|
* theme toggle are ActionIcons. The variable is no use as a hook: Mantine writes it
|
|
|
|
|
* INLINE on the element, so a stylesheet declaring it loses every time (the same trap
|
|
|
|
|
* as `--group-justify` on Pagination). The painted property has to be set instead, and
|
|
|
|
|
* `html` lifts this over Mantine's own single-class rule.
|
|
|
|
|
*
|
|
|
|
|
* Measuring the foreground against the bar is worth nothing if the icons opt out of it.
|
|
|
|
|
*/
|
|
|
|
|
.wrolpi-navbar a,
|
|
|
|
|
html .wrolpi-navbar .mantine-ActionIcon-root {
|
|
|
|
|
color: inherit;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The bar's own hover, rather than a blue tint from Mantine's palette. */
|
|
|
|
|
html .wrolpi-navbar .mantine-ActionIcon-root:hover {
|
|
|
|
|
background: rgba(0, 0, 0, 0.12);
|
|
|
|
|
color: inherit;
|
|
|
|
|
}
|
|
|
|
|
|
ui: the navbar corner was nudged rather than laid out, and it showed
Three faults in the bar, all reproduced by measurement before being fixed.
The indicators sat low. The slot carried `marginTop: 0.8em`, a nudge left over
from Semantic's menu; the corner centres its children, and a top margin is part
of the margin box being centred, so it applied as a ~6px downward shift. It
read as an error on the hotspot and the theme picker but not on share or search,
which is why it survived: an IconButton is a square ActionIcon that centres its
glyph exactly, while a bare-icon anchor sits high inside a line box that
reserves descender space for text that is not there. The nudge cancelled that
out on one shape and was pure error on the other. Both are laid out now --
flex, centred, no nudge -- and the anchors get `display: flex` so they hug their
glyph instead of a text line.
Help and Admin highlighted only a box around their text while Videos and
Statistics highlighted the full height. Same class, same rules, different
parent: the bar stretches its children, but the corner is a nested flex
container that centres its own, so a link inside it was sized to its content.
The hover background is painted on the link box, so that box IS the affordance.
The bar broke onto a second line at certain widths. Two measurement errors that
only overlap in a narrow band, which is why it appeared while resizing rather
than always. useOverflowNav measured the WRAPPER's offsetWidth and subtracted
only the home link and the corner, missing the bar's own `padding: 0 0.25em` --
about 8px it believed it had. And the hidden "More" placeholder it measured was
a plain button with no dropdown caret, about 21px narrower than the button that
eventually rendered. The placeholder is now the same component as the real
trigger, so the two cannot drift again.
Tested in ui-layout.cy.js against the real <DesktopNav/>, which takes its
colours, home link and indicators as props and so needs none of NavBar's polling
hooks. Indicator centres are measured against the bar's centre rather than each
other, because three things can be equally and consistently wrong and were. The
wrap case sweeps 1180px down to 640px in 6px steps -- a spot check steps over a
band that narrow. All three failed first: share 3.4px high, Help 24.8px against
a 54.4px bar, and two rows at 1156px.
Confirmed on the running app: every indicator at 0.0px from the bar's centre,
Help and Admin at the full 54.4px, and no wrap anywhere from 1500px to 780px.
1115 jest / 62 suites, 182 in ui-layout.cy.js, clean npm run build.
2026-08-02 14:25:04 -06:00
|
|
|
/*
|
|
|
|
|
* One status indicator's slot. Laid out rather than nudged: see NavIconWrapper in Nav.js
|
|
|
|
|
* for the 0.8em top margin this replaces and why it looked correct on half the indicators.
|
|
|
|
|
*/
|
|
|
|
|
.wrolpi-navbar-icon {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
margin-left: 1.5em;
|
ui: the corner triggers, the More button, and the search modal
Four faults, each measured in the running app before and after.
The search glyph carried Semantic's `item` class, which has had no rules at all
since Semantic was removed: no pointer cursor, no hover, and an 18.6px hit area
against a 54.4px bar. It is the same kind of thing as Help and Admin and now
takes the same class. The share glyph did compute `cursor: pointer` -- it is an
`<a href>` -- but its target was the 24px box the icon occupies, so the pointer
appeared only if you found it exactly. Corner anchors now stretch and pad like
a link.
The More button rendered with NO class at all: a bare grey UA button while the
rest of the bar took the user's colour. Menu.Target clones its child and hands
it a className of its own, and the trigger spread those cloned props after its
own `className` attribute, so the clone replaced ours. It is merged now. This
was mine, from extracting NavDropdownTrigger last commit -- and it also made the
previous commit's "measured and drawn are the same component" claim only half
true, because the hidden placeholder is not cloned and so kept its class.
The bar still wrapped, for a reason the padding fix could not reach: the corner
does not keep a constant width. The Cmd-K hint renders only once
useKeyboardDetected has seen a keypress, so it appears at an arbitrary later
moment and widens the corner by ~30px; the load, memory, temperature and drive
warnings come and go with the machine's state. None of that resizes the
container, which was the only thing observed -- so nothing recalculated. That
is the other half of "at certain widths": the same viewport wrapped or not
depending on whether the user had touched a key. The corner and the home link
are observed too now.
The search modal showed an input and the first line of the first group. The
suggestion list is absolutely positioned, which is right everywhere else -- a
list that reflows the page while you type is unusable -- but in a modal it fails
twice: an absolute list adds no height, so the panel sized itself to the search
box alone at 114px, and the panel's own `overflow: auto` then clipped the list
at that edge. In the modal the list sits in flow; the inverse is asserted so
the rule cannot leak to the pages where overlaying is correct.
Two of the new tests were wrong first and reverting the fix left them green:
they asserted hand-written markup carrying the classes I expected the components
to have, rather than the real SearchIconButton and ShareButton. They use the
real components now. Every fix was then planted against: 5 red for the More
class, 2 for the search class, 2 for the corner hit area, 1 for the observer,
2 for the modal.
1115 jest / 62 suites, 196 in ui-layout.cy.js, clean npm run build.
Confirmed live: share and search both pointer at 54.4px, More white on the bar
colour with a transparent face, and the modal's list in flow and unclipped.
2026-08-02 14:45:49 -06:00
|
|
|
/* Full bar height, so the anchor inside has somewhere to stretch to. */
|
|
|
|
|
align-self: stretch;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* An icon-only trigger in the corner gets a link's hit area, not its glyph's.
|
|
|
|
|
*
|
|
|
|
|
* The share glyph already computed `cursor: pointer` -- it is an `<a href>` -- but the
|
|
|
|
|
* target was the 24px box the icon occupies, so the pointer appeared only if you found it
|
|
|
|
|
* exactly, and there was no hover highlight to aim at. Stretched and padded, it behaves
|
|
|
|
|
* like Help and Admin beside it.
|
|
|
|
|
*
|
|
|
|
|
* `align-self` rather than `align-items: stretch` on the wrapper: the IconButtons in the
|
|
|
|
|
* corner have an explicit height, and a stretch container places an item it cannot stretch
|
|
|
|
|
* at the start -- which would push the hotspot and theme glyphs back off centre.
|
|
|
|
|
*/
|
|
|
|
|
.wrolpi-navbar-icon > a {
|
|
|
|
|
align-self: stretch;
|
|
|
|
|
padding: 0 0.5em;
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.wrolpi-navbar-icon > a:hover {
|
|
|
|
|
background: rgba(0, 0, 0, 0.12);
|
ui: the navbar corner was nudged rather than laid out, and it showed
Three faults in the bar, all reproduced by measurement before being fixed.
The indicators sat low. The slot carried `marginTop: 0.8em`, a nudge left over
from Semantic's menu; the corner centres its children, and a top margin is part
of the margin box being centred, so it applied as a ~6px downward shift. It
read as an error on the hotspot and the theme picker but not on share or search,
which is why it survived: an IconButton is a square ActionIcon that centres its
glyph exactly, while a bare-icon anchor sits high inside a line box that
reserves descender space for text that is not there. The nudge cancelled that
out on one shape and was pure error on the other. Both are laid out now --
flex, centred, no nudge -- and the anchors get `display: flex` so they hug their
glyph instead of a text line.
Help and Admin highlighted only a box around their text while Videos and
Statistics highlighted the full height. Same class, same rules, different
parent: the bar stretches its children, but the corner is a nested flex
container that centres its own, so a link inside it was sized to its content.
The hover background is painted on the link box, so that box IS the affordance.
The bar broke onto a second line at certain widths. Two measurement errors that
only overlap in a narrow band, which is why it appeared while resizing rather
than always. useOverflowNav measured the WRAPPER's offsetWidth and subtracted
only the home link and the corner, missing the bar's own `padding: 0 0.25em` --
about 8px it believed it had. And the hidden "More" placeholder it measured was
a plain button with no dropdown caret, about 21px narrower than the button that
eventually rendered. The placeholder is now the same component as the real
trigger, so the two cannot drift again.
Tested in ui-layout.cy.js against the real <DesktopNav/>, which takes its
colours, home link and indicators as props and so needs none of NavBar's polling
hooks. Indicator centres are measured against the bar's centre rather than each
other, because three things can be equally and consistently wrong and were. The
wrap case sweeps 1180px down to 640px in 6px steps -- a spot check steps over a
band that narrow. All three failed first: share 3.4px high, Help 24.8px against
a 54.4px bar, and two rows at 1156px.
Confirmed on the running app: every indicator at 0.0px from the bar's centre,
Help and Admin at the full 54.4px, and no wrap anywhere from 1500px to 780px.
1115 jest / 62 suites, 182 in ui-layout.cy.js, clean npm run build.
2026-08-02 14:25:04 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* An anchor in the corner hugs its glyph instead of a text line box.
|
|
|
|
|
*
|
|
|
|
|
* A line box reserves descender space for text that is not there, which leaves an icon
|
|
|
|
|
* sitting about 3px above the centre of the box being centred -- the share and search
|
|
|
|
|
* glyphs, but not the hotspot or theme picker, which are square ActionIcons that centre
|
|
|
|
|
* their own glyph. That difference is what made a single top margin look right on some
|
|
|
|
|
* indicators and wrong on others.
|
|
|
|
|
*/
|
|
|
|
|
.wrolpi-navbar-right a {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A link in the corner fills the bar's height, as one outside it does.
|
|
|
|
|
*
|
|
|
|
|
* Help and Admin highlighted only a box around their text while Videos and Statistics
|
|
|
|
|
* highlighted the full height. Same class and same rules; the difference is the parent.
|
|
|
|
|
* The bar stretches its children, but the corner is a nested flex container that centres
|
|
|
|
|
* its own, so a link inside it was sized to its content. The hover background is painted
|
|
|
|
|
* on the link box, so this is the hover affordance itself and not just its outline.
|
|
|
|
|
*/
|
|
|
|
|
.wrolpi-navbar-right .wrolpi-navbar-link,
|
|
|
|
|
.wrolpi-navbar-right .wrolpi-navbar-link-button {
|
|
|
|
|
align-self: stretch;
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-01 16:42:52 -06:00
|
|
|
.channel-edit {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
border-radius: 0.1875rem;
|
2021-11-01 16:42:52 -06:00
|
|
|
padding: 0.75em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.channel-edit:hover {
|
|
|
|
|
background-color: #7abaff;
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
::-ms-clear {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.form-control-clear {
|
|
|
|
|
z-index: 10;
|
|
|
|
|
pointer-events: auto;
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pre.wrap-text {
|
|
|
|
|
white-space: pre-wrap; /* Since CSS 2.1 */
|
|
|
|
|
white-space: -moz-pre-wrap; /* Mozilla, since 1999 */
|
|
|
|
|
word-wrap: break-word; /* Internet Explorer 5.5+ */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.duration-overlay {
|
|
|
|
|
position: absolute;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
top: 0.25rem;
|
|
|
|
|
right: 0.25rem;
|
2021-11-01 16:42:52 -06:00
|
|
|
color: black;
|
2023-04-01 11:52:41 -06:00
|
|
|
background: #ffffff;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
padding: 0px 0.25rem;
|
|
|
|
|
border-radius: 0.1875rem;
|
2021-11-01 16:42:52 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.no-link-underscore {
|
|
|
|
|
text-decoration: none !important;
|
|
|
|
|
}
|
|
|
|
|
|
ui: cards get legible titles, contained posters, and meta beside the title
Four defects on /videos, /docs and /archives.
Titles were invisible outside light. `.card-link` carried a literal
`color: black` from before the themes existed -- about 1.1:1 on the dark,
night and amber panels. It applies to every card title and to the
channel/author/domain line beside it. The date was fine, since it takes
`--muted` from the card body, which is what made this look like a card
bug rather than a link bug. Titles now take `--text`: they are links,
but they are the card's text, not a wall of blue.
Posters were cropped, not mis-proportioned. The image carried a fixed
290x163 box; a card in the default grid is about 233px wide and Mantine's
Card sets `overflow: hidden`, so the browser painted the middle 233px of
a 290px image. The ratio was right in the layout tree and wrong on
screen. Replaced with caps on both axes -- the card's width and
`--card-poster-max-height: 200px` -- with `width`/`height` left `auto` so
the pair behaves as "contain". Bounding the width alone was tried first
and is not enough: a square thumbnail then stands as tall as the card is
wide, and a portrait book cover taller still.
The meta line was foot-anchored, so on /docs a PDF with no author had its
date shoved up to 55px below the title, at the bottom of a card that was
tall only because of its neighbour in the row. It now sits directly
under the title.
Archive cards read buttons-then-domain, because the buttons were children
and the meta was what got pushed to the foot. Card gains an `actions`
slot, rendered last and anchored to the foot, so a row lines its buttons
up however many lines each title took.
Gallery gains a poster row covering all five ratios and a row showing
meta/actions against unequal titles.
1076 jest tests, 145 in ui-layout.cy.js, clean build. Every new guard was
checked against a planted regression: dropping the height cap reddens the
square and portrait cases and leaves 16:9 green; `width: 100%` reddens
containment; restoring `color: black` reddens dark/night/amber and leaves
light green; re-anchoring the meta and swapping the slot order redden both
the jest order test and the cypress geometry tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-02 09:16:31 -06:00
|
|
|
/*
|
|
|
|
|
* A card's title and its author/channel/domain line are links, but they are the card's
|
style: spell it "color" everywhere
283 occurrences across 23 files, all of them mine and all of them in the
theme/UI work: comments, test names, and a handful of local identifiers
(`colours`, `roleColours`, `awaitColoured`) plus one test fixture tag named
'Uncoloured'.
Nothing was required to keep the other spelling. Checked before replacing: no
CSS custom property or class name contains it, no library prop or API key does,
and every string holding it is a test name or our own copy. The renamed
identifiers were checked for collisions with an existing `color`/`colors` in the
same file first -- there were none.
Verified as a pure rename: 262 lines changed, and normalising the spelling on
every removed line reproduces the added line exactly, for all 262. So the diff
contains no other edit hiding in it.
1134 jest / 64 suites, 271 cypress component tests with the same 12 pre-existing
Semantic-era failures in Tags/Channels/Download/Inventory, clean npm run build.
2026-08-02 18:02:44 -06:00
|
|
|
* text -- they take the body color rather than the link color, so a grid of cards reads
|
ui: cards get legible titles, contained posters, and meta beside the title
Four defects on /videos, /docs and /archives.
Titles were invisible outside light. `.card-link` carried a literal
`color: black` from before the themes existed -- about 1.1:1 on the dark,
night and amber panels. It applies to every card title and to the
channel/author/domain line beside it. The date was fine, since it takes
`--muted` from the card body, which is what made this look like a card
bug rather than a link bug. Titles now take `--text`: they are links,
but they are the card's text, not a wall of blue.
Posters were cropped, not mis-proportioned. The image carried a fixed
290x163 box; a card in the default grid is about 233px wide and Mantine's
Card sets `overflow: hidden`, so the browser painted the middle 233px of
a 290px image. The ratio was right in the layout tree and wrong on
screen. Replaced with caps on both axes -- the card's width and
`--card-poster-max-height: 200px` -- with `width`/`height` left `auto` so
the pair behaves as "contain". Bounding the width alone was tried first
and is not enough: a square thumbnail then stands as tall as the card is
wide, and a portrait book cover taller still.
The meta line was foot-anchored, so on /docs a PDF with no author had its
date shoved up to 55px below the title, at the bottom of a card that was
tall only because of its neighbour in the row. It now sits directly
under the title.
Archive cards read buttons-then-domain, because the buttons were children
and the meta was what got pushed to the foot. Card gains an `actions`
slot, rendered last and anchored to the foot, so a row lines its buttons
up however many lines each title took.
Gallery gains a poster row covering all five ratios and a row showing
meta/actions against unequal titles.
1076 jest tests, 145 in ui-layout.cy.js, clean build. Every new guard was
checked against a planted regression: dropping the height cap reddens the
square and portrait cases and leaves 16:9 green; `width: 100%` reddens
containment; restoring `color: black` reddens dark/night/amber and leaves
light green; re-anchoring the meta and swapping the slot order redden both
the jest order test and the cypress geometry tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-02 09:16:31 -06:00
|
|
|
* as titles and not as a wall of blue. This was a literal `black` until the themes
|
|
|
|
|
* arrived, which left every title at about 1.1:1 on the dark, night and amber panels.
|
|
|
|
|
*/
|
2022-01-03 15:13:02 -07:00
|
|
|
.card-link {
|
ui: cards get legible titles, contained posters, and meta beside the title
Four defects on /videos, /docs and /archives.
Titles were invisible outside light. `.card-link` carried a literal
`color: black` from before the themes existed -- about 1.1:1 on the dark,
night and amber panels. It applies to every card title and to the
channel/author/domain line beside it. The date was fine, since it takes
`--muted` from the card body, which is what made this look like a card
bug rather than a link bug. Titles now take `--text`: they are links,
but they are the card's text, not a wall of blue.
Posters were cropped, not mis-proportioned. The image carried a fixed
290x163 box; a card in the default grid is about 233px wide and Mantine's
Card sets `overflow: hidden`, so the browser painted the middle 233px of
a 290px image. The ratio was right in the layout tree and wrong on
screen. Replaced with caps on both axes -- the card's width and
`--card-poster-max-height: 200px` -- with `width`/`height` left `auto` so
the pair behaves as "contain". Bounding the width alone was tried first
and is not enough: a square thumbnail then stands as tall as the card is
wide, and a portrait book cover taller still.
The meta line was foot-anchored, so on /docs a PDF with no author had its
date shoved up to 55px below the title, at the bottom of a card that was
tall only because of its neighbour in the row. It now sits directly
under the title.
Archive cards read buttons-then-domain, because the buttons were children
and the meta was what got pushed to the foot. Card gains an `actions`
slot, rendered last and anchored to the foot, so a row lines its buttons
up however many lines each title took.
Gallery gains a poster row covering all five ratios and a row showing
meta/actions against unequal titles.
1076 jest tests, 145 in ui-layout.cy.js, clean build. Every new guard was
checked against a planted regression: dropping the height cap reddens the
square and portrait cases and leaves 16:9 green; `width: 100%` reddens
containment; restoring `color: black` reddens dark/night/amber and leaves
light green; re-anchoring the meta and swapping the slot order redden both
the jest order test and the cypress geometry tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-02 09:16:31 -06:00
|
|
|
color: var(--text);
|
2021-11-01 16:42:52 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.center-me {
|
|
|
|
|
margin: 0 auto;
|
|
|
|
|
}
|
2022-08-06 05:22:07 +00:00
|
|
|
|
|
|
|
|
div.inverted {
|
|
|
|
|
background-color: #1B1C1D;
|
|
|
|
|
}
|
|
|
|
|
|
review: close the mixed-unit gaps the scale left behind
Seven review comments, all valid. The common thread is the one the guard was supposed to
catch and did not: geometry converted to rem beside geometry that stayed px.
The guard was narrower than its name. It missed:
- `transform`, `flex` and `flex-basis`, so `translateX(26px)` and `flex: 1 1 200px` were
invisible on properties nobody thought to list;
- every NEGATIVE length, because the lookbehind treated the minus sign as part of the
preceding token -- `left: -7px` and `margin-top: -2.5px` position the eyelet on a tag whose
diamond HAD been converted, and `right: -3px` / `bottom: -3px` place the corner badge on a
converted icon. Each is a piece of geometry that stopped tracking the piece it belongs to.
With both fixed it found nine values, including one no comment mentioned (`flex: 1 1 200px`).
All nine converted, except the three in a dead `.toggle` / `.slider` block: nothing has
referenced those classes since Toggle became a Mantine Switch, and it was ALREADY broken --
track and knob in rem, travel still `translateX(26px)`, so the thumb stopped ~4px short of a
54px track. Dead CSS that is also wrong is a trap for whoever revives it, so it is deleted.
The tag eyelet is centred with `translateY(-50%)` rather than a negative margin of half its
own height, so the two pieces cannot drift again whatever the scale.
Also from the review:
- A runtime check, which is what the source guards were missing. Three cases in
ui-layout.cy.js measure the real thing: the root font-size is the declared multiple of 16,
our text AND a Mantine control both grow by the same factor when the scale changes, and a
hairline does not. The second is the one that catches `theme.scale` being set and silently
cancelling the root.
- `max-height: max(..., 56.25cqw)` now follows a plain rem declaration. An engine without
container query units throws out the whole declaration, which would have left the poster
with NO cap -- a portrait cover standing as tall as the card is wide. Older engines clamp;
newer ones take the second.
- `pxToRem` in components/ui/scale.ts, replacing the `/ 16` written out in CardGroup and
Placeholder.
- The map overlays: 20 values across the layer panel, add-pin dialog, search panel and
context menu, whose type had grown 10% while their padding had not. Left in px on purpose:
the context menu's `left`/`top` (a real click coordinate), maplibre's own `ScaleControl`
maxWidth, and the `calc(100% - 100px)` reserve for maplibre's px-sized controls. The
`100vh - 120px` reserve DID become rem, since the chrome it reserves for is ours.
- The keyboard-shortcuts spec no longer deletes `.mantine-Notifications-root` from the DOM.
The reviewer was right that it is brittle; the endpoints are mocked instead, now that the
probe named them: `/api/tag`, `/api/events/feed`, `/api/files/search` and
`/api/files/worker_status`. Two of those were already "mocked" as `/api/tags` and
`/api/events`, which nothing calls -- the wrong paths were the reason a toast appeared at
all. Verified under CI's condition (`forceNetworkError` on everything unmocked): 12
passing with no DOM surgery.
What is NOT done, deliberately: about 176 numeric geometry values remain in 23 feature files.
The map overlays were the visible ones. Sweeping the rest is a change to 23 files nobody has
reviewed, so instead the guard's name now says "in our stylesheets" rather than implying the
whole app, and a new ratchet keeps numeric geometry out of the component library so the
eleventh inline `gap: 10` cannot be added there.
Both new guards planted against. Verified: 1142 jest / 65 suites, 251 ui-layout + 10
modal-stack component tests, all 50 e2e specs, clean build, map overlays measured to track the
scale (panel minWidth 200 -> 220, search 320 -> 352) and screenshotted.
2026-08-03 19:37:25 -06:00
|
|
|
/*
|
|
|
|
|
* The hand-rolled `.toggle` / `.slider` switch is gone.
|
|
|
|
|
*
|
|
|
|
|
* Nothing referenced either class: `Toggle` is a Mantine Switch, and the only remaining
|
|
|
|
|
* matches for the words were the `classList.toggle` DOM method and the controller's own
|
|
|
|
|
* templates, which do not load this stylesheet.
|
|
|
|
|
*
|
|
|
|
|
* It is deleted rather than finished because it was already half-converted and broken: the
|
|
|
|
|
* track and knob became rem while the checked-state travel stayed `translateX(26px)`, so on a
|
|
|
|
|
* 54px track the thumb would have stopped ~4px short. Dead CSS that is also wrong is a trap
|
|
|
|
|
* for whoever revives it, and it also hardcoded #6435C9 and white, which no theme can reach.
|
|
|
|
|
*/
|
2023-01-31 18:08:07 -07:00
|
|
|
|
2026-03-12 17:48:35 -06:00
|
|
|
.inverted-progress-text.ui.indicating.progress .bar > .progress,
|
|
|
|
|
.inverted-progress-text.ui.progress > .label {
|
|
|
|
|
color: white !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Light bar colors (yellow, olive) need dark text on the bar — must override inverted-progress-text. */
|
|
|
|
|
.light-bar-progress-text.ui.indicating.progress .bar > .progress,
|
|
|
|
|
.light-bar-progress-text.ui.progress .bar > .progress {
|
|
|
|
|
color: rgba(0, 0, 0, 0.85) !important;
|
|
|
|
|
}
|
|
|
|
|
|
2026-04-15 13:18:45 -06:00
|
|
|
/* File preview Modal.Actions toolbar.
|
|
|
|
|
Single layout that works at every viewport — buttons keep their order at any width.
|
|
|
|
|
On narrow screens, the tags selector wraps to its own line while the button groups stay together. */
|
|
|
|
|
.preview-toolbar {
|
|
|
|
|
display: flex;
|
|
|
|
|
flex-wrap: wrap;
|
|
|
|
|
align-items: center;
|
|
|
|
|
gap: 0.5em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.preview-toolbar-group {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
gap: 0.25em;
|
|
|
|
|
flex: 0 0 auto;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.preview-toolbar-tags {
|
review: close the mixed-unit gaps the scale left behind
Seven review comments, all valid. The common thread is the one the guard was supposed to
catch and did not: geometry converted to rem beside geometry that stayed px.
The guard was narrower than its name. It missed:
- `transform`, `flex` and `flex-basis`, so `translateX(26px)` and `flex: 1 1 200px` were
invisible on properties nobody thought to list;
- every NEGATIVE length, because the lookbehind treated the minus sign as part of the
preceding token -- `left: -7px` and `margin-top: -2.5px` position the eyelet on a tag whose
diamond HAD been converted, and `right: -3px` / `bottom: -3px` place the corner badge on a
converted icon. Each is a piece of geometry that stopped tracking the piece it belongs to.
With both fixed it found nine values, including one no comment mentioned (`flex: 1 1 200px`).
All nine converted, except the three in a dead `.toggle` / `.slider` block: nothing has
referenced those classes since Toggle became a Mantine Switch, and it was ALREADY broken --
track and knob in rem, travel still `translateX(26px)`, so the thumb stopped ~4px short of a
54px track. Dead CSS that is also wrong is a trap for whoever revives it, so it is deleted.
The tag eyelet is centred with `translateY(-50%)` rather than a negative margin of half its
own height, so the two pieces cannot drift again whatever the scale.
Also from the review:
- A runtime check, which is what the source guards were missing. Three cases in
ui-layout.cy.js measure the real thing: the root font-size is the declared multiple of 16,
our text AND a Mantine control both grow by the same factor when the scale changes, and a
hairline does not. The second is the one that catches `theme.scale` being set and silently
cancelling the root.
- `max-height: max(..., 56.25cqw)` now follows a plain rem declaration. An engine without
container query units throws out the whole declaration, which would have left the poster
with NO cap -- a portrait cover standing as tall as the card is wide. Older engines clamp;
newer ones take the second.
- `pxToRem` in components/ui/scale.ts, replacing the `/ 16` written out in CardGroup and
Placeholder.
- The map overlays: 20 values across the layer panel, add-pin dialog, search panel and
context menu, whose type had grown 10% while their padding had not. Left in px on purpose:
the context menu's `left`/`top` (a real click coordinate), maplibre's own `ScaleControl`
maxWidth, and the `calc(100% - 100px)` reserve for maplibre's px-sized controls. The
`100vh - 120px` reserve DID become rem, since the chrome it reserves for is ours.
- The keyboard-shortcuts spec no longer deletes `.mantine-Notifications-root` from the DOM.
The reviewer was right that it is brittle; the endpoints are mocked instead, now that the
probe named them: `/api/tag`, `/api/events/feed`, `/api/files/search` and
`/api/files/worker_status`. Two of those were already "mocked" as `/api/tags` and
`/api/events`, which nothing calls -- the wrong paths were the reason a toast appeared at
all. Verified under CI's condition (`forceNetworkError` on everything unmocked): 12
passing with no DOM surgery.
What is NOT done, deliberately: about 176 numeric geometry values remain in 23 feature files.
The map overlays were the visible ones. Sweeping the rest is a change to 23 files nobody has
reviewed, so instead the guard's name now says "in our stylesheets" rather than implying the
whole app, and a new ratchet keeps numeric geometry out of the component library so the
eleventh inline `gap: 10` cannot be added there.
Both new guards planted against. Verified: 1142 jest / 65 suites, 251 ui-layout + 10
modal-stack component tests, all 50 e2e specs, clean build, map overlays measured to track the
scale (panel minWidth 200 -> 220, search 320 -> 352) and screenshotted.
2026-08-03 19:37:25 -06:00
|
|
|
/* rem so the basis grows with the tags it holds. */
|
|
|
|
|
flex: 1 1 12.5rem;
|
2026-04-15 13:18:45 -06:00
|
|
|
min-width: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Caps preview content to fit inside the file-preview Modal.
|
|
|
|
|
300px reserves room for pathContent <pre>, Modal.Header, Modal.Actions row,
|
|
|
|
|
inner content (e.g. STL dimensions banner), and modal padding.
|
|
|
|
|
Use 100dvh so mobile browser chrome (URL bar) is accounted for. */
|
|
|
|
|
.preview-fit {
|
|
|
|
|
width: 100%;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
height: calc(100dvh - 18.75rem);
|
|
|
|
|
max-height: calc(100dvh - 18.75rem);
|
|
|
|
|
min-height: 15rem;
|
2023-01-31 18:08:07 -07:00
|
|
|
overflow: hidden;
|
|
|
|
|
position: relative;
|
2026-04-15 13:18:45 -06:00
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
justify-content: center;
|
2023-01-31 18:08:07 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-09 19:44:35 -06:00
|
|
|
/* Fresnel (Media) wraps iframes in a div which would otherwise shrink to the
|
|
|
|
|
default iframe size; make it fill the preview so the iframe's 100% works. */
|
|
|
|
|
.preview-fit .fresnel-container {
|
|
|
|
|
width: 100%;
|
|
|
|
|
height: 100%;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-31 18:08:07 -07:00
|
|
|
td.file-path {
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
|
|
|
|
|
ui: give tables a real header, drop the column grid, quiet the row rules
Three things the file browser made obvious.
The header was not a surface. Mantine gives thead no background at all, so
the header painted whatever was behind the table -- which is exactly what an
unstriped body row paints. Against a striped body it read as one more stripe,
and bold type was the only thing distinguishing it. It now carries `--head`,
the token that already means "recessed surface", with a full-strength 2px rule
under it: the header/body division is the one line in a table that carries
meaning, so it is the one allowed to be loud.
Column borders are gone. A line around every cell is a lot of ink to repeat
what the column headings already say, and it was half of why the header
disappeared -- a bordered header cell looks like a cell in a grid.
Row rules were `--border`, the same weight as the outline around the table, so
a long table read as a stack of boxes. They now use `--table-line`, a new
token per theme sitting between the surface and `--border`. The table outline
is not a row rule and keeps `--border`; Mantine draws both from
`--table-border-color`, so that had to be restated.
In the file browser an icon and a filename are inline siblings in one cell. An
inline SVG sits on the text baseline, so a 24px glyph beside 13px text hung
above it -- the icon looked centred in the row and the name looked like it was
resting on the icon's floor. `vertical-align: middle` centres it, and the
margin is a gap that was never there at all: the folder icon touched the first
letter of its own name.
Cypress now loads App.css, as the app does. Without it a spec covering the
file browser rows measures a component the app never renders.
One jest test and eleven browser tests, each checked red against a planted
regression. Two notes for the next person:
- `html .mantine-Table-table` is specificity, not decoration. Mantine
declares --table-border-color on its own hashed class, which ties with
`.mantine-Table-table` and wins on source order.
- the "quieter than the outline" test measures both lines against `--panel`.
Nothing paints <html> under a mounted component, so measuring against the
root background compares them to black, which ranks the *paler* line as the
louder one -- the assertion passed backwards until it was pointed at the
surface the rules actually sit on.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 16:46:50 -06:00
|
|
|
/*
|
|
|
|
|
* The row is an icon followed by a filename, as inline siblings. An inline SVG
|
|
|
|
|
* sits on the text baseline by default, so a 24px glyph next to 13px text hangs
|
|
|
|
|
* well above it and the name looks like it is resting on the icon's floor.
|
|
|
|
|
* `middle` centres the glyph against the text instead.
|
|
|
|
|
*
|
|
|
|
|
* The margin is the gap that was never there: the folder icon touched the first
|
|
|
|
|
* letter of its own name, and two icons (a folder and its ignored marker) touched
|
|
|
|
|
* each other.
|
|
|
|
|
*/
|
|
|
|
|
td.file-path > svg {
|
|
|
|
|
vertical-align: middle;
|
|
|
|
|
margin-right: 0.35em;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-31 18:08:07 -07:00
|
|
|
/* Necessary until react-semantic-toasts is upgraded to Node 18 */
|
|
|
|
|
.ui-alerts {
|
|
|
|
|
position: fixed;
|
|
|
|
|
z-index: 2060;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
padding: 1.5rem;
|
2023-01-31 18:08:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.ui-alerts.top-right {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
top: 1.25rem;
|
|
|
|
|
right: 1.25rem;
|
2023-01-31 18:08:07 -07:00
|
|
|
}
|
2023-02-15 20:58:07 -07:00
|
|
|
|
|
|
|
|
textarea.otp {
|
|
|
|
|
width: 100%;
|
|
|
|
|
color: #333;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.card-icon {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
min-height: 10.1875rem;
|
2023-02-15 20:58:07 -07:00
|
|
|
text-align: center;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
padding-top: 3.3125rem;
|
2023-02-15 20:58:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.card-icon.inverted {
|
|
|
|
|
background-color: #222222;
|
|
|
|
|
}
|
|
|
|
|
|
2023-04-18 22:03:45 -06:00
|
|
|
.modal .inverted {
|
|
|
|
|
border-color: #888888;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.modal .header.inverted {
|
|
|
|
|
color: #DDDDDD !important;
|
|
|
|
|
background-color: #171616 !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.modal .content.inverted {
|
|
|
|
|
color: #DDDDDD !important;
|
|
|
|
|
border-color: #888888 !important;
|
|
|
|
|
background-color: #171616 !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.modal .actions.inverted {
|
|
|
|
|
color: #DDDDDD !important;
|
|
|
|
|
border-color: #888888 !important;
|
|
|
|
|
background-color: #171616 !important;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-21 14:50:32 -06:00
|
|
|
.modal.inverted i.close {
|
|
|
|
|
color: #DDDDDD !important;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-28 16:38:43 -06:00
|
|
|
/* The accordion has no background of its own; it inherits whatever container it sits in (Modal
|
|
|
|
|
content #171616, Segment #1B1C1D, the page body, etc.). This matches how the light theme already
|
|
|
|
|
renders accordions (transparent), and avoids a darker band when the parent isn't #171616.
|
|
|
|
|
Direct children only, so nested components that use the `content`/`title` class names (e.g. a
|
|
|
|
|
Message's Message.Content) are not affected. */
|
|
|
|
|
.ui.inverted.accordion,
|
Move One-Time Pad encryption to the browser (#479)
* Move One-Time Pad encryption to the browser; delete backend OTP module
OTP encryption/decryption is now performed entirely in the browser so
messages, keys, and generated pads never leave the originating device.
- Add app/src/components/otp.js: a JS port of the former modules/otp/lib.py
(encrypt/decrypt, message formatting, validation, and secure pad
generation via crypto.getRandomValues with rejection sampling).
- Encrypt/Decrypt now run live as the user types or pastes, with inline
error messages instead of submit buttons.
- Generate New Pad builds the printable HTML locally (blob URL) instead of
hitting /api/otp/html.
- Migrate all backend OTP tests to app/src/components/otp.test.js with
identical data.
- Delete the modules/otp backend module and its blueprint registration.
* Revoke the One-Time Pad blob URL after the new tab loads
Addresses a minor blob-handle leak: handleGenerateNewPad created an object
URL on every click but never released it.
* Let users choose the One-Time Pad character set
Add an "Advanced" accordion under the buttons with three options: A-Z,
A-Z/0-9 (default, unchanged), and a custom character set. The chosen set is
shared by encrypt, decrypt, and pad generation.
- otp.js: parameterize encrypt/decrypt/generate on the alphabet (default
OTP_CHARS for back-compat); add OTP_CHARS_ALPHA and validateCharset; input
is auto-uppercased only when the set is all-uppercase, so custom sets with
lowercase are case-sensitive; the printable pad is labeled with its set.
- Apps.js: lift charset state into OTP(); gate encrypt/decrypt/generate on a
valid set with inline validation errors.
- otp.test.js: add A-Z, custom round-trip, auto-uppercase, validateCharset,
and pad-label tests.
* Scope inverted-accordion dark background to direct children
The rule forcing #171616 on .ui.inverted.accordion .title/.content used a
descendant selector, so it leaked onto any nested element using the `content`
class — e.g. an ErrorMessage's Message.Content rendered inside SimpleAccordion
got a dark band behind its text. Scope to direct children so the accordion
still styles its own title/content but not nested components.
* Add optional error-detection checksum to the One-Time Pad
Adapts the position-weighted checksum from otp-checksum.md to the
frontend-only OTP. checksum = sum(position * value) mod N, parameterized on
the selected character set (N = chars.length), so it follows whichever pad
alphabet is chosen. Position weighting catches transposition errors.
- otp.js: add calculateChecksum/appendChecksum/verifyChecksum.
- Apps.js: opt-in "Append error-detection checksum" toggle in Advanced
(default off). When on, encrypt appends a checksum char; decrypt verifies
it, warns on mismatch, and still shows the decrypted text.
- otp.test.js: checksum unit tests, charset-variation, and end-to-end vectors.
* Show compact checksum status instead of a large warning box
Replace the bulky semantic-ui WarningMessage on decrypt with a small inline
status line: a green check + "Checksum is valid" or a red x + "Checksum is
invalid", shown whenever the checksum option is on and a message is being
decrypted.
* Fix checksum-mode decrypt truncating messages without a checksum
When the "Append error-detection checksum" option was on, Decrypt always
stripped the last ciphertext character before decrypting, so a message that
carried no trailing checksum (wrong sender setting, body pasted alone, etc.)
lost its final character and decrypted to garbage.
Add stripChecksum(received, chars), which removes the trailing character only
when it actually verifies as the checksum of the preceding characters; a
message without a valid checksum is returned intact and flagged invalid. The
decrypt UI now uses it.
Also broaden test coverage:
- stripChecksum tests, including a regression for the truncation bug.
- validation error classes (InvalidOTP/Plaintext/Ciphertext) and the
longer-than-OTP length guards.
- deterministic encrypt/decrypt roundtrip fuzz across several character sets.
- generateMessage character-count and charset-membership checks.
- end-to-end checksummed encrypt -> format -> strip -> decrypt flow.
Use a dedicated InvalidMessage error for the checksum helpers instead of the
misleading InvalidPlaintext.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-06-13 13:52:18 -06:00
|
|
|
.ui.inverted.accordion > .title,
|
|
|
|
|
.ui.inverted.accordion > .content {
|
2026-06-28 16:38:43 -06:00
|
|
|
background-color: transparent !important;
|
2026-03-05 16:18:03 -07:00
|
|
|
}
|
|
|
|
|
|
2026-07-09 15:19:47 -06:00
|
|
|
/* Semantic UI paints a definition table's empty corner cell white (background on the inverted
|
|
|
|
|
variant, white box-shadows on the celled/plain variants) to fake a "cut-out" corner on a white
|
|
|
|
|
page. Our dark theme has a dark page, so the corner must be transparent with no shadow. */
|
|
|
|
|
.ui.inverted.definition.table thead:not(.full-width) th:first-child,
|
|
|
|
|
.ui.inverted.definition.table tfoot:not(.full-width) th:first-child,
|
|
|
|
|
.ui.inverted.celled.definition.table thead:not(.full-width) th:first-child,
|
|
|
|
|
.ui.inverted.celled.definition.table tfoot:not(.full-width) th:first-child {
|
|
|
|
|
background: transparent !important;
|
|
|
|
|
box-shadow: none !important;
|
|
|
|
|
}
|
|
|
|
|
|
2023-02-15 20:58:07 -07:00
|
|
|
.clickable {
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
2023-04-18 22:03:45 -06:00
|
|
|
|
|
|
|
|
.segment.inverted {
|
|
|
|
|
border: 1px solid #ffffff22 !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inverted label {
|
|
|
|
|
color: #DDDDDD !important;
|
2023-11-02 10:07:49 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.table-ellipsis td.column-ellipsis {
|
|
|
|
|
white-space: nowrap;
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
text-overflow: ellipsis;
|
|
|
|
|
max-width: 0; /* Ensures the content doesn't exceed the cell's width */
|
2023-11-04 15:57:13 -06:00
|
|
|
min-width: 25em; /* About iPhone SE width */
|
2023-11-02 10:07:49 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.card-title-ellipsis {
|
|
|
|
|
display: -webkit-box;
|
|
|
|
|
-webkit-line-clamp: 3;
|
|
|
|
|
-webkit-box-orient: vertical;
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
text-overflow: ellipsis;
|
|
|
|
|
}
|
2023-11-21 13:01:52 -07:00
|
|
|
|
|
|
|
|
.search-container {
|
|
|
|
|
display: flex;
|
|
|
|
|
justify-content: flex-start;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.search-input {
|
|
|
|
|
flex-grow: 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.search-clear {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
margin: 0.625rem;
|
2023-11-21 13:01:52 -07:00
|
|
|
}
|
2024-06-25 17:05:41 -06:00
|
|
|
|
|
|
|
|
.icon.divider {
|
|
|
|
|
color: rgb(0, 0, 0, 0.4) !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.divider.inverted {
|
|
|
|
|
color: rgb(255, 255, 255, 0.6) !important;
|
|
|
|
|
}
|
2024-08-02 11:56:06 -06:00
|
|
|
|
|
|
|
|
.video-player {
|
|
|
|
|
display: block;
|
|
|
|
|
margin: 0 auto; /* Center the video horizontally */
|
|
|
|
|
}
|
2025-01-22 08:33:05 -07:00
|
|
|
|
2026-04-14 15:00:49 -06:00
|
|
|
.audio-poster-container {
|
|
|
|
|
position: relative;
|
|
|
|
|
display: block;
|
|
|
|
|
text-align: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.audio-poster-overlay {
|
|
|
|
|
position: absolute;
|
|
|
|
|
top: 50%;
|
|
|
|
|
left: 50%;
|
|
|
|
|
transform: translate(-50%, -50%);
|
|
|
|
|
color: rgba(255, 255, 255, 0.85);
|
|
|
|
|
text-shadow: 0 0 20px rgba(0, 0, 0, 0.6);
|
|
|
|
|
pointer-events: none;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 08:33:05 -07:00
|
|
|
table.ratio-table td.equal-width {
|
|
|
|
|
width: 48%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
table.ratio-table td.min-width {
|
|
|
|
|
width: auto;
|
|
|
|
|
}
|
2025-12-02 15:33:46 -07:00
|
|
|
|
|
|
|
|
/* CollectionEditForm styles */
|
|
|
|
|
.required-indicator {
|
|
|
|
|
color: red;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Form loading skeleton */
|
|
|
|
|
.form-skeleton-field {
|
|
|
|
|
margin-bottom: 1.5em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.form-skeleton-label {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
height: 0.875rem;
|
|
|
|
|
width: 5rem;
|
|
|
|
|
margin-bottom: 0.5rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
background: linear-gradient(90deg, #e0e0e0 25%, #f0f0f0 50%, #e0e0e0 75%);
|
|
|
|
|
background-size: 200% 100%;
|
|
|
|
|
animation: skeleton-shimmer 1.5s infinite;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
border-radius: 0.1875rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.form-skeleton-input {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
height: 2.375rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
width: 100%;
|
|
|
|
|
background: linear-gradient(90deg, #e0e0e0 25%, #f0f0f0 50%, #e0e0e0 75%);
|
|
|
|
|
background-size: 200% 100%;
|
|
|
|
|
animation: skeleton-shimmer 1.5s infinite;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
border-radius: 0.25rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.form-skeleton-textarea {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
height: 5rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
width: 100%;
|
|
|
|
|
background: linear-gradient(90deg, #e0e0e0 25%, #f0f0f0 50%, #e0e0e0 75%);
|
|
|
|
|
background-size: 200% 100%;
|
|
|
|
|
animation: skeleton-shimmer 1.5s infinite;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
border-radius: 0.25rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.form-skeleton-button {
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
height: 2.625rem;
|
|
|
|
|
width: 6.25rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
background: linear-gradient(90deg, #e0e0e0 25%, #f0f0f0 50%, #e0e0e0 75%);
|
|
|
|
|
background-size: 200% 100%;
|
|
|
|
|
animation: skeleton-shimmer 1.5s infinite;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
border-radius: 0.25rem;
|
2025-12-02 15:33:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@keyframes skeleton-shimmer {
|
|
|
|
|
0% {
|
|
|
|
|
background-position: -200% 0;
|
|
|
|
|
}
|
|
|
|
|
100% {
|
|
|
|
|
background-position: 200% 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Dark mode skeleton */
|
|
|
|
|
.inverted .form-skeleton-label,
|
|
|
|
|
.inverted .form-skeleton-input,
|
|
|
|
|
.inverted .form-skeleton-textarea,
|
|
|
|
|
.inverted .form-skeleton-button {
|
|
|
|
|
background: linear-gradient(90deg, #333 25%, #444 50%, #333 75%);
|
|
|
|
|
background-size: 200% 100%;
|
|
|
|
|
animation: skeleton-shimmer 1.5s infinite;
|
|
|
|
|
}
|
2025-12-07 09:17:30 -07:00
|
|
|
|
test: one place for fixtures, real providers instead of mocked context modules
Specs had no shared vocabulary for the app's data or its contexts, so each one
rebuilt both. A settings object was written out by hand wherever one was needed,
twenty-odd keys at a time, and nothing held those copies to each other or to the
API. Contexts were worse: to render a consumer a spec mocked the whole context
module, which replaces every export including the providers, so each spec
reinvented the pieces it still needed. One supplies a `Media` that always
reports desktop -- quietly leaving that component's mobile branch untested -- and
one hand-writes a context as a bare `_currentValue` with no provider, working only
because useContext reads that React internal.
test-fixtures.js is now the single definition of both, shared by jest, the
Cypress component specs, and e2e intercept bodies, so the three cannot disagree
about what the API returns. Every fixture is a function taking overrides; a
shared mutable object lets one test change what the next one sees.
The drift this prevents was already real. The theme fixture supplied `i`, `s`
and `t` holding hardcoded Semantic greys for months after ThemeProvider stopped
supplying them, and ThemeContext still declared all four. So the fixture agreed
with the tests, and with nothing else: FileBrowser was reading `inverted` off the
context and pasting the resulting `undefined` into a className, which is why the
file browser's footer -- near-white #f9fafb, with a `.inverted` dark variant that
nothing could select any more -- stayed light in dark, night and amber. A white
bar pinned to the bottom of the screen in night mode costs the user exactly the
dark adaptation the theme exists to protect. It takes tokens now.
test-fixtures.test.js holds each fixture to its context's declared shape in both
directions, so a property added to one and forgotten in the other fails a test.
Two failed attempts are recorded in test-utils.js because both were instructive.
Importing Tags.js and FileWorkerStatusContext.js so the harness could supply
those providers broke eight suites: it put both into the module graph of every
spec ahead of that spec's own mocks, and components bound to a second instance of
a mocked module -- a different jest.fn() than the test had configured, so a hook
mocked to return a value returned undefined, in a file no test mentions.
Requiring them lazily fixed that and not its mirror image: useContext read a
different TagsContext than the harness had required, so the provider was ignored
and the context default won. A harness must not change what a spec imports, so
it owns only contexts/contexts.js and a spec passes any other context itself.
DomainTagging is converted off the `_currentValue` fake as proof, and now asserts
the tag name a user sees rather than a test id its own mock invented. The five
remaining specs are listed in a ratchet so the count can only fall.
974 jest, 15 browser component, 46 e2e, clean cache-busted build, tsc clean.
Fixtures are confirmed absent from the shipped bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-30 16:30:49 -06:00
|
|
|
/*
|
|
|
|
|
* Sticky footer for the file browser.
|
|
|
|
|
*
|
|
|
|
|
* These were two hardcoded Semantic greys with `.inverted` selecting the dark one, but
|
|
|
|
|
* nothing has set `.inverted` since ThemeProvider stopped supplying it -- so the footer stayed
|
|
|
|
|
* at near-white `#f9fafb` in dark, night and amber. In night mode a white bar pinned to the
|
|
|
|
|
* bottom of the screen costs the user the dark adaptation the whole theme exists to protect.
|
|
|
|
|
* Tokens have no such failure mode: there is one rule and each theme fills it in.
|
|
|
|
|
*/
|
2025-12-07 09:17:30 -07:00
|
|
|
.sticky-footer {
|
|
|
|
|
position: fixed;
|
|
|
|
|
bottom: 0;
|
|
|
|
|
left: 0;
|
|
|
|
|
right: 0;
|
|
|
|
|
padding: 0.5em 1em;
|
test: one place for fixtures, real providers instead of mocked context modules
Specs had no shared vocabulary for the app's data or its contexts, so each one
rebuilt both. A settings object was written out by hand wherever one was needed,
twenty-odd keys at a time, and nothing held those copies to each other or to the
API. Contexts were worse: to render a consumer a spec mocked the whole context
module, which replaces every export including the providers, so each spec
reinvented the pieces it still needed. One supplies a `Media` that always
reports desktop -- quietly leaving that component's mobile branch untested -- and
one hand-writes a context as a bare `_currentValue` with no provider, working only
because useContext reads that React internal.
test-fixtures.js is now the single definition of both, shared by jest, the
Cypress component specs, and e2e intercept bodies, so the three cannot disagree
about what the API returns. Every fixture is a function taking overrides; a
shared mutable object lets one test change what the next one sees.
The drift this prevents was already real. The theme fixture supplied `i`, `s`
and `t` holding hardcoded Semantic greys for months after ThemeProvider stopped
supplying them, and ThemeContext still declared all four. So the fixture agreed
with the tests, and with nothing else: FileBrowser was reading `inverted` off the
context and pasting the resulting `undefined` into a className, which is why the
file browser's footer -- near-white #f9fafb, with a `.inverted` dark variant that
nothing could select any more -- stayed light in dark, night and amber. A white
bar pinned to the bottom of the screen in night mode costs the user exactly the
dark adaptation the theme exists to protect. It takes tokens now.
test-fixtures.test.js holds each fixture to its context's declared shape in both
directions, so a property added to one and forgotten in the other fails a test.
Two failed attempts are recorded in test-utils.js because both were instructive.
Importing Tags.js and FileWorkerStatusContext.js so the harness could supply
those providers broke eight suites: it put both into the module graph of every
spec ahead of that spec's own mocks, and components bound to a second instance of
a mocked module -- a different jest.fn() than the test had configured, so a hook
mocked to return a value returned undefined, in a file no test mentions.
Requiring them lazily fixed that and not its mirror image: useContext read a
different TagsContext than the harness had required, so the provider was ignored
and the context default won. A harness must not change what a spec imports, so
it owns only contexts/contexts.js and a spec passes any other context itself.
DomainTagging is converted off the `_currentValue` fake as proof, and now asserts
the tag name a user sees rather than a test id its own mock invented. The five
remaining specs are listed in a ratchet so the count can only fall.
974 jest, 15 browser component, 46 e2e, clean cache-busted build, tsc clean.
Fixtures are confirmed absent from the shipped bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-30 16:30:49 -06:00
|
|
|
background-color: var(--panel);
|
|
|
|
|
border-top: 1px solid var(--border);
|
2025-12-07 09:17:30 -07:00
|
|
|
z-index: 100;
|
ui: three button-layout defects, each with a different cause
Reported together as "button groups", but they turned out to be three unrelated
things.
The file browser's footer buttons touched while the Channel Edit page's had
gaps. Channel Edit lays its buttons out with Mantine's `Group`, which is a flex
row with a gap; the footer is hand-rolled and was a plain block, so its
inline-block buttons sat flush -- JSX drops whitespace-only lines, so there was
not even a space character between them. The footer is now the flex row every
other button group already is, wrapping because it carries eight controls.
The Settings config table's Import and Save buttons had off-centre icons while
Restore in the same row looked right. Restore is an IconButton -- an ActionIcon,
which centres a lone glyph by construction. Import and Save are icon-only
Buttons, and an icon on a Button goes into Mantine's `leftSection`, which carries
a `margin-inline-end` to hold it off the label. With no label that margin is
pure offset: measured at 8px left of centre. An icon with no label is now
rendered as the button's content instead, so it centres. `Children.toArray`
decides that, because it drops nulls and the file browser passes
`{label('Delete')}` -- null whenever the bar is too narrow for words, which is
exactly where the offset showed most.
The search field's clear button sat inside the field rather than attached to it:
the control is a bordered box with `padding: 0 8px`, leaving the button 9px short
of the edge and 2px short of the height. Semantic welded it to the field --
measured on the QA Pi at zero gap and full height -- so it now stretches and
negative margins cancel the padding and the flex gap. Negative margins rather
than dropping the control's padding, because that padding is what holds the
search icon and the text off the border; only this one child should escape it.
The `html` prefix on that rule is load-bearing: Mantine sets ActionIcon's height
from `--ai-size` on its own single class, and at equal specificity the winner is
whichever stylesheet loaded last.
Fourteen new cases. One correction worth recording: the height assertion first
compared against the control's border box and failed on correct behaviour -- the
button fills the CONTENT box, and the 1px above and below it is the field's own
border, which it should sit inside rather than paint over. Each fix planted
separately; the icon change reddens three, the footer one, the clear button one.
Every case is paired with an inverse -- a labelled button must keep its icon on
the left, and the field must still be padded around its other children.
1128 jest / 63 suites, 226 in ui-layout.cy.js, clean npm run build. Confirmed
live: footer gaps 8px on one row, config glyphs at 0.0px from centre, clear
button 1px from the field edge at the field's full inner height.
2026-08-02 17:13:28 -06:00
|
|
|
/*
|
|
|
|
|
* A row with gaps, like every other group of buttons in the app.
|
|
|
|
|
*
|
|
|
|
|
* This was a plain block, so the buttons -- inline-block elements with no whitespace
|
|
|
|
|
* between them, because JSX drops whitespace-only lines -- sat flush against each other
|
|
|
|
|
* in one unbroken slab. Everywhere else buttons are laid out with Mantine's `Group`,
|
|
|
|
|
* which is a flex row with a gap; the file browser's footer is hand-rolled and never got
|
|
|
|
|
* one. It wraps because the bar carries eight controls and a phone cannot hold them.
|
|
|
|
|
*/
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
flex-wrap: wrap;
|
|
|
|
|
gap: 0.5em;
|
2025-12-07 09:17:30 -07:00
|
|
|
}
|
|
|
|
|
|
2025-12-26 11:28:10 -07:00
|
|
|
/* Drag selection visual feedback for FileBrowser */
|
|
|
|
|
tr.drag-selecting td {
|
|
|
|
|
background-color: rgba(33, 133, 208, 0.15) !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inverted tr.drag-selecting td {
|
|
|
|
|
background-color: rgba(33, 133, 208, 0.25) !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Drag deselection visual feedback (red tint) */
|
|
|
|
|
tr.drag-deselecting td {
|
|
|
|
|
background-color: rgba(219, 40, 40, 0.15) !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inverted tr.drag-deselecting td {
|
|
|
|
|
background-color: rgba(219, 40, 40, 0.25) !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Prevent text selection during drag */
|
|
|
|
|
.file-browser-dragging {
|
|
|
|
|
user-select: none;
|
|
|
|
|
-webkit-user-select: none;
|
|
|
|
|
-moz-user-select: none;
|
|
|
|
|
-ms-user-select: none;
|
|
|
|
|
}
|
2026-02-08 10:57:12 -07:00
|
|
|
|
2026-07-03 11:17:11 -06:00
|
|
|
/* Filter input and collapse-all button: right-aligned on desktop, full width on mobile (below). */
|
|
|
|
|
.file-browser-filter-container {
|
|
|
|
|
display: flex;
|
|
|
|
|
justify-content: flex-end;
|
review: the scan the first two commits needed
Five findings, all valid. The substantive one: the video page's Download /
Delete / Refresh / AddToPlaylist strip was still four bare buttons in a `<p>` --
the direct analogue of the archive row this PR started with -- and the scan that
was supposed to catch exactly that reported the app clean.
It only ever saw `{fooButton}` interpolations, and most of the app writes its
buttons out in place. Scanning for adjacent button ELEMENTS finds twelve more
rows in the same state: reorder icons in the playlist and field-schema tables,
both service tables on the controller page, its hotspot Save/QR pair and its
Restart/Shutdown pair, the downloads footer, the one-time pad's Generate/Cheat
Sheet, and the ration calculator's CSV/Print. All rowed.
Two holes had to be closed before that scan could be trusted, because a scan
that reports noise is worse than one with a stated limit:
- `tagsIn` never captured the tag NAME, so `ROW_COMPONENTS.has(undefined)` was
false for every tag and the list of components that lay out their own
children -- Group, ButtonGroup, Modal.Actions -- silently accepted none of
them. 56 false positives, every modal footer in the app among them.
- A row whose style is a const (`style={seasonRowStyle}`) says nothing in its
own attributes. Resolved now; the dates selector's seasons row is a
four-column grid with a gap and was reported three times.
Also from review: the row body is found by walking to the MATCHING close rather
than the first `</div>`, which one nested div would have truncated -- and the
collection form now nests one, so this was about to matter. Cancel and Save
travel together in a row of their own pushed to the end; `margin-left: auto` on
Save alone was right for a row that could not wrap, and would now drop Save onto
a second line by itself with Cancel left among the action buttons. The doc
page's comment no longer implies the picker's 1em separation was not a change.
One more found on the way: the file browser's filter row is flex with no gap, and
its collapse-all button carried `margin-left: 0.5em` for it. The gap is the
container's.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 17:06:56 -06:00
|
|
|
/* The gap is the container's. The collapse-all button carried `margin-left: 0.5em` for it,
|
|
|
|
|
which is the same thing one element to the right of where it belongs. */
|
|
|
|
|
gap: 0.5em;
|
ui: pages own the space between their blocks
Panels shared edges: two 1px borders meeting, which reads as one tall
surface with a rule across it rather than a seam between two.
Done as `margin-bottom` on the panel first, which is the anti-pattern, and
it failed in both of the ways that rule is known to fail before the reading
was done. It compounded with the gap of every Stack that already held
panels -- four of them, spacing those lists at 35.2px against the app's
17.6px -- and the `:last-child` reset meant to keep trailing space off the
bottom of a container silently did nothing, because Media wrapping makes a
panel the only child of its own wrapper. On Status that separated four
pairs out of five and left the first touching.
So the space belongs to whatever stacks the blocks. `.wrolpi-stack` is on
PageContainer, which every page uses, and on the three wrappers that stack
blocks somewhere the page's own stack cannot reach: Settings' panel wrapper,
the block below the video player, and the Zim and Map route wrappers, which
hold their tab bar outside PageContainer.
A gap rather than `> * + * { margin-top }`, which was tried and is quietly
broken here: Media injects `.fresnel-container { margin: 0; padding: 0 }` at
runtime, same specificity, later source order, so every wrapped block threw
the margin away. A child cannot zero its parent's gap. It also means
Media's hidden half contributes nothing, where the owl selector spaced
around something invisible.
With the page owning the spacing, the blocks that owned some of it had to
give it up, or their margin was added to the gap: the tab bar (33px against
17.6 everywhere else), the shared search control bar and paginator on
Videos/Archives/Docs/Files, the card grid, the file browser's filter row and
the inventory search. Two margins deliberately stay -- the file browser's
4em, which reserves room for the sticky buttons (62645831), and heading
margins, which bind a heading to the content below it.
Tests plant each of the three failures: the wrapped block, a child that
zeroes its own margin, and a hidden Media half. Verified in the browser on
sixteen routes and in all four themes -- every stacked pair 17.6px, the
map's 85vh box and the video player unchanged, no horizontal overflow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 15:40:27 -06:00
|
|
|
/* No `margin-bottom`: this is a top-level block of the Files page, and the page's stack
|
|
|
|
|
spaces it (see `.wrolpi-stack`). Its own 0.5em was added to that. */
|
2026-07-03 11:17:11 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Double the default input width on desktop. */
|
|
|
|
|
.ui.input.file-browser-filter {
|
|
|
|
|
width: 34em;
|
|
|
|
|
max-width: 100%;
|
|
|
|
|
}
|
|
|
|
|
|
2026-03-09 16:11:44 -06:00
|
|
|
@media only screen and (max-width: 700px) {
|
|
|
|
|
.hide-on-mobile {
|
|
|
|
|
display: none !important;
|
|
|
|
|
}
|
2026-07-03 11:17:11 -06:00
|
|
|
|
|
|
|
|
.file-browser-filter-container {
|
|
|
|
|
justify-content: flex-start;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Fill the row, but stay on one line with the collapse-all button. */
|
|
|
|
|
.ui.input.file-browser-filter {
|
|
|
|
|
flex: 1 1 auto;
|
|
|
|
|
width: auto;
|
|
|
|
|
}
|
2026-03-09 16:11:44 -06:00
|
|
|
}
|
|
|
|
|
|
2026-02-08 10:57:12 -07:00
|
|
|
/* Ensure step icons are always visible, even when disabled */
|
|
|
|
|
.ui.steps .step.disabled > .icon,
|
|
|
|
|
.ui.steps .step.disabled > i.icon,
|
|
|
|
|
.ui.steps .disabled.step > .icon,
|
|
|
|
|
.ui.steps .disabled.step > i.icon {
|
|
|
|
|
opacity: 0.45 !important;
|
|
|
|
|
display: inline-block !important;
|
|
|
|
|
visibility: visible !important;
|
|
|
|
|
width: auto !important;
|
|
|
|
|
height: auto !important;
|
|
|
|
|
color: rgba(0, 0, 0, 0.87) !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Ensure the icon glyph (::before) is visible for disabled steps */
|
|
|
|
|
.ui.steps .step.disabled > .icon:before,
|
|
|
|
|
.ui.steps .step.disabled > i.icon:before,
|
|
|
|
|
.ui.steps .disabled.step > .icon:before,
|
|
|
|
|
.ui.steps .disabled.step > i.icon:before {
|
|
|
|
|
opacity: 0.45 !important;
|
|
|
|
|
visibility: visible !important;
|
|
|
|
|
color: rgba(0, 0, 0, 0.87) !important;
|
|
|
|
|
}
|
|
|
|
|
|
Add CSV/PDF export and a search filter to Inventory
New Export tab with two client-side formats (no new dependencies):
- CSV: the raw items table (RFC-4180 quoting, UTF-8 BOM for Excel), generated
entirely in the browser. The download anchor is attached to the DOM and the
object URL is revoked on the next tick for cross-browser robustness.
- PDF: a printable full-inventory table followed by a group-by summary table,
via the browser's print dialog ("Save as PDF"). The summary's grouping is
chosen in the Export tab.
Search filter: a box on its own line under the inventory selector filters the
active inventory across every column's displayed value (case-insensitive;
whitespace-separated terms are AND-ed). It narrows the whole view — Items
table, Summary aggregation, and Export/PDF — while edits/adds in the table
still operate on the full inventory, so filtering never drops data.
Summary/export grouping:
- The group-by aggregation is extracted into a shared summarize.js (field-role
detection + count-aware totals via units.js + calories), now the single
source of truth for the Summary tab, the PDF summary, and the ration
calculator. findCaloriesKey/findCountKey moved here from RationCalculator
(re-exported for back-compat).
- The Sum selector now offers number and calories fields in addition to
quantity: number/calories are summed as a plain column total, while quantity
stays count-aware and unit-compacted and the dedicated Calories column stays
count-aware.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 11:00:01 -06:00
|
|
|
|
|
|
|
|
/* Inventory "PDF" export: the printable table is hidden on screen and becomes the only
|
|
|
|
|
visible content when printing, so a user can use the browser dialog to Save as PDF. */
|
|
|
|
|
.inventory-print {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@media print {
|
|
|
|
|
body * {
|
|
|
|
|
visibility: hidden;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print,
|
|
|
|
|
.inventory-print * {
|
|
|
|
|
visibility: visible;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print {
|
|
|
|
|
display: block;
|
|
|
|
|
position: absolute;
|
|
|
|
|
top: 0;
|
|
|
|
|
left: 0;
|
|
|
|
|
width: 100%;
|
|
|
|
|
color: #000;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print h1 {
|
|
|
|
|
font-size: 18pt;
|
|
|
|
|
margin: 0 0 0.25em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print h2 {
|
|
|
|
|
font-size: 13pt;
|
|
|
|
|
margin: 1.25em 0 0.5em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print-meta {
|
|
|
|
|
font-size: 9pt;
|
|
|
|
|
color: #444;
|
|
|
|
|
margin: 0 0 0.75em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print table {
|
|
|
|
|
width: 100%;
|
|
|
|
|
border-collapse: collapse;
|
|
|
|
|
font-size: 10pt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print th,
|
|
|
|
|
.inventory-print td {
|
|
|
|
|
border: 1px solid #999;
|
ui: scale the whole interface by 10%, off the root font-size
The interface reads about 10% smaller than the pre-migration Semantic build, and the
drift is not one number. Measured on the QA Pi at 1280px, Semantic's headings were
h1 28 / h2 24 / h3 18 / h4 15 / h5 14 against our 26 / 21 / 17 / 14 / 13, and its video
card a fixed 290px with an 18px title against our 238px with a 13px one -- while our
BODY text and chrome went the other way, a 16px base against Semantic's 14 and 42px
buttons against 36. No per-component nudge reproduces what a user comparing the two
sees, which is the whole page at once.
Ten percent is not a fudge factor: our heading scale times 1.1 is 28.6 / 23.1 / 18.7 /
15.4 / 14.3, which is Semantic's scale to within a pixel at every step. Verified in
the browser -- those are the numbers it now renders.
`--ui-scale: 1.1` and `html { font-size: calc(100% * var(--ui-scale)) }`, with
everything that should grow written in rem:
- 102 lengths in ui.css, App.css and tokens.css converted, restricted by property:
font-size, padding, margin, gap, width/height, border-radius, offsets.
- Borders, outlines and shadows deliberately NOT converted. A hairline is a hairline
at any text size.
- 46 inline `fontSize` px values across 8 files. `em` values were left alone: they
already resolve against the parent.
- Ten inline-styled blocks in the library (Card's text block, Loading, Placeholder,
ColoredInput, Confirm's action row, CardGroup's gap) moved into ui.css, because an
inline px size cannot be reached by a scale or seen by a test.
- CardGroup converts its `minWidth` prop to rem, which is what returns a phone to one
card per row: as px the track ignored the scale, so a 430px screen fitted two 200px
cards where the old build fitted one 290px card.
Mantine needs nothing: its 644 size declarations are `calc(Xrem * var(--mantine-scale))`
and scale with the root. `theme.scale` must stay at 1 -- it exists to CANCEL a
customised root font-size, so setting it to 1.1 as well would leave Mantine's half of
the interface at the old size beside our larger text. A test pins that.
`zoom: 1.1` on the root was tried first and rejected. It works and it is one line, but
it scales at paint: every 1px hairline becomes 1.1px and softens on a 1x display, and
viewport units do not shrink to compensate, so `100vh` paints 110% of the screen -- a
95vw modal overflowed sideways and the CBZ viewer's fullscreen overflowed down. Rem
scales real lengths, keeps borders crisp, leaves viewport units alone, and preserves a
user's own browser font-size preference instead of overriding it.
A percentage rather than a px root size, for that last reason.
Five guards in themes/ui-scale.test.js, each planted against: the scale itself, that
every scalable declaration is rem, that borders are NOT, that no inline px font-size
survives anywhere including the gallery, and that Mantine's scale stays 1.
Also removes `.ui.modal.themed-confirm`, a dead Semantic-era rule and the source of the
one `95vw` that would have overflowed: `.ui.modal` no longer exists and nothing sets
that class.
Verified: 1141 tests / 65 suites; clean build; browser-checked at 1280px and at a 430px
phone; navbar single-row from 780 to 1800px; hairlines still 1px and no horizontal
overflow in all four themes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:45:08 -06:00
|
|
|
padding: 0.25rem 0.375rem;
|
Add CSV/PDF export and a search filter to Inventory
New Export tab with two client-side formats (no new dependencies):
- CSV: the raw items table (RFC-4180 quoting, UTF-8 BOM for Excel), generated
entirely in the browser. The download anchor is attached to the DOM and the
object URL is revoked on the next tick for cross-browser robustness.
- PDF: a printable full-inventory table followed by a group-by summary table,
via the browser's print dialog ("Save as PDF"). The summary's grouping is
chosen in the Export tab.
Search filter: a box on its own line under the inventory selector filters the
active inventory across every column's displayed value (case-insensitive;
whitespace-separated terms are AND-ed). It narrows the whole view — Items
table, Summary aggregation, and Export/PDF — while edits/adds in the table
still operate on the full inventory, so filtering never drops data.
Summary/export grouping:
- The group-by aggregation is extracted into a shared summarize.js (field-role
detection + count-aware totals via units.js + calories), now the single
source of truth for the Summary tab, the PDF summary, and the ration
calculator. findCaloriesKey/findCountKey moved here from RationCalculator
(re-exported for back-compat).
- The Sum selector now offers number and calories fields in addition to
quantity: number/calories are summed as a plain column total, while quantity
stays count-aware and unit-compacted and the dedicated Calories column stays
count-aware.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 11:00:01 -06:00
|
|
|
text-align: left;
|
|
|
|
|
vertical-align: top;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Repeat the header row at the top of each printed page. */
|
|
|
|
|
.inventory-print thead {
|
|
|
|
|
display: table-header-group;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.inventory-print tr {
|
|
|
|
|
page-break-inside: avoid;
|
|
|
|
|
}
|
Add a recommended Food Storage example, a Ration tab, and a supply planner
Build on the rebuilt config-only Inventory with three related additions.
Recommended example inventory:
- A fresh install now seeds the "Food Storage" example with the recommended
one-adult / one-year (~3,000 kcal/day) emergency food supply (60 items,
~1.12M kcal), instead of an empty inventory.
- The counts are layered on top of the shipped food catalog (single source of
per-package nutrition) via RECOMMENDED_ONE_YEAR_FOOD_COUNTS, joined at seed
time by recommended_food_storage_items().
- Genericized the two remaining brand names in the catalog defaults
(Velveeta -> Processed Cheese, Spam -> Canned Lunch Meat) so both the catalog
and the seeded inventory stay brand-free.
Ration tab (split out of Summary):
- Moved the Ration Estimate (People / Daily Calories / estimate table) out of
the increasingly long Summary tab into its own "Ration" tab, shown only for
inventories that have a calories field.
Supply planner ("Plan More Supply"):
- A slider picks a target duration longer than the current estimate; the whole
inventory is scaled up proportionally (every item by the same factor, mix
kept balanced) into a sortable shopping list of what to buy.
- Any split package rounds UP to a whole one (ceil), matching the "1.6 buckets
-> buy 1 more" rule.
- The shopping list is exportable as CSV (reusing toCSV) and PDF (reusing the
print-to-PDF path, scoped via body.printing-shopping so only the list prints
-- no inventory or summary).
Search filter:
- Moved the items search out of the top toolbar (which implied it filtered
every tab) into the Items tab, so it clearly narrows Items only;
Summary/Ration/Export/print always use the full inventory.
Aggregation/role helpers (findNameKey, planSupplyPurchase) live in summarize.js,
the single source of truth shared by Summary, export, and the ration views.
All new pure functions and UI flows are covered by tests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 12:39:58 -06:00
|
|
|
|
|
|
|
|
/* The supply-plan shopping list reuses the .inventory-print element styling (h1/table/etc.) but is a separate
|
|
|
|
|
printable block. By default (e.g. the Export tab's whole-inventory PDF) it is hidden; it becomes the ONLY
|
|
|
|
|
printed block when the supply plan toggles `body.printing-shopping` just before window.print(). */
|
|
|
|
|
.shopping-print,
|
|
|
|
|
.shopping-print * {
|
|
|
|
|
visibility: hidden;
|
|
|
|
|
}
|
|
|
|
|
.shopping-print {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
body.printing-shopping .inventory-print:not(.shopping-print),
|
|
|
|
|
body.printing-shopping .inventory-print:not(.shopping-print) * {
|
|
|
|
|
visibility: hidden;
|
|
|
|
|
}
|
|
|
|
|
body.printing-shopping .inventory-print:not(.shopping-print) {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
body.printing-shopping .shopping-print,
|
|
|
|
|
body.printing-shopping .shopping-print * {
|
|
|
|
|
visibility: visible;
|
|
|
|
|
}
|
|
|
|
|
body.printing-shopping .shopping-print {
|
|
|
|
|
display: block;
|
|
|
|
|
}
|
Add CSV/PDF export and a search filter to Inventory
New Export tab with two client-side formats (no new dependencies):
- CSV: the raw items table (RFC-4180 quoting, UTF-8 BOM for Excel), generated
entirely in the browser. The download anchor is attached to the DOM and the
object URL is revoked on the next tick for cross-browser robustness.
- PDF: a printable full-inventory table followed by a group-by summary table,
via the browser's print dialog ("Save as PDF"). The summary's grouping is
chosen in the Export tab.
Search filter: a box on its own line under the inventory selector filters the
active inventory across every column's displayed value (case-insensitive;
whitespace-separated terms are AND-ed). It narrows the whole view — Items
table, Summary aggregation, and Export/PDF — while edits/adds in the table
still operate on the full inventory, so filtering never drops data.
Summary/export grouping:
- The group-by aggregation is extracted into a shared summarize.js (field-role
detection + count-aware totals via units.js + calories), now the single
source of truth for the Summary tab, the PDF summary, and the ration
calculator. findCaloriesKey/findCountKey moved here from RationCalculator
(re-exported for back-compat).
- The Sum selector now offers number and calories fields in addition to
quantity: number/calories are summed as a plain column total, while quantity
stays count-aware and unit-compacted and the dedicated Calories column stays
count-aware.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 11:00:01 -06:00
|
|
|
}
|