Skip to content

docs(roadmap): put the Bootstrap icon colour gap at the top - #173

Merged
dknauss merged 1 commit into
mainfrom
docs/roadmap-icon-colour
Aug 20, 2026
Merged

docs(roadmap): put the Bootstrap icon colour gap at the top#173
dknauss merged 1 commit into
mainfrom
docs/roadmap-icon-colour

Conversation

@dknauss

@dknauss dknauss commented Aug 19, 2026

Copy link
Copy Markdown
Owner

Adds a Next up section at the top of the roadmap — above ## Phases, below ## Milestones — carrying the Bootstrap icon colour gap from #172.

Framed as a decision to make rather than work to schedule, because the cheap options are approximations and the correct one is architectural.

The gap

All 87 Bootstrap icons sit at a fixed #a7aaad. Dashicons lighten on hover, go white on the current item, and follow the admin colour scheme — the Bootstrap ones do none of it, so a mixed menu looks inconsistent exactly where the eye lands.

Known trade-off, not an oversight: bin/generate-bootstrap-icons.mjs bakes the grey in because a data-URI used as a CSS background-image cannot resolve currentColor, while dashicons get it free by being a font. The constraint is core's — wp-admin/menu-header.php has no branch that would let a plugin emit inline <svg>, and 7.1's SVG Icon API does not change that (#162).

Options recorded

  1. Document it in the picker — costs nothing, fixes nothing
  2. CSS brightness(0) invert(1) — one line, but only reaches pure white, wrong against schemes whose icon-focus colour isn't white
  3. Per-state generated variants — doubles payload, still misses custom schemes
  4. Inline SVG injected by JS — the only correct one, and the most invasive

Recommendation: (1) now, (2) if the inconsistency is worth an approximation, (4) only alongside #167/#168 since it is the same architectural bet.

Also recorded

There are two icon sets, dashicons and bootstrap, registered in Assets::icon_sets() — not three. A third registered through the SVG Icon API would land with exactly this limitation, which is why it hasn't been added.

Docs-only. check:doc-links clean.

🤖 Generated with Claude Code

All 87 Bootstrap icons sit at a fixed #a7aaad while dashicons lighten on
hover, go white on the current item, and follow the admin colour scheme.
A mixed menu looks inconsistent exactly where the eye lands.

Recorded as a decision to make rather than work to schedule, because the
cheap options are approximations and the correct one is architectural.
The constraint is core's: a data-URI background-image cannot resolve
currentColor, and menu-header.php has no branch that would let a plugin
emit inline SVG. 7.1's SVG Icon API does not change that (#162).

Also records that there are two icon sets, not three — a third via the
SVG Icon API would land with the same limitation.

Detail and options in #172.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@dknauss
dknauss merged commit a0ce1c2 into main Aug 20, 2026
27 of 28 checks passed
@dknauss
dknauss deleted the docs/roadmap-icon-colour branch August 20, 2026 19:00
dknauss added a commit that referenced this pull request Aug 20, 2026
* docs(roadmap): put the Bootstrap icon colour gap at the top

All 87 Bootstrap icons sit at a fixed #a7aaad while dashicons lighten on
hover, go white on the current item, and follow the admin colour scheme.
A mixed menu looks inconsistent exactly where the eye lands.

Recorded as a decision to make rather than work to schedule, because the
cheap options are approximations and the correct one is architectural.
The constraint is core's: a data-URI background-image cannot resolve
currentColor, and menu-header.php has no branch that would let a plugin
emit inline SVG. 7.1's SVG Icon API does not change that (#162).

Also records that there are two icon sets, not three — a third via the
SVG Icon API would land with the same limitation.

Detail and options in #172.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(js): guard the hydration ceiling, and bound CI runtime

Two things that both exist because a failure already happened.

GUARD: FULLSCREEN_SETTLE_MS was silently reverted once. #164 raised it
3000 -> 10000 with measurements; #165 put it back, not by disagreeing but
because a wholesale `git checkout <branch> -- assets/maestro.js` replaced
the file from a branch predating the change. Every suite stayed green,
because the ceiling only bounds a give-up path nothing exercises. It
surfaced days later during an unrelated audit.

The guard asserts a FLOOR of 5000ms, not the exact value: 10000 is a
tuning number, and pinning it exactly would turn every legitimate re-tune
into a failing test and teach people to edit the assertion. A floor
catches what actually happened — a revert to a value too small to be safe
— and leaves tuning free above it. Verified against the real regression:
setting 3000 fails the guard with a message saying why.

It reads the source text because maestro.js is a browser IIFE with no
export surface. Same shape as the doc-links test.

TIMEOUTS: PR #173's Integration job hung in `Install Playwright Chromium`
— the same apt-get stall that burned six hours on Borges #79 — and no
Maestro workflow had any timeout.

Sized against 200 successful runs, not a recent window:

    Integration + E2E    1052s -> 35m
    Runtime + Plugin Check 158s -> 10m
    everything else       <=90s -> 10m

Plus 20m on the install step itself, which across 80 runs is 21-689s
(median 25s, p95 97s) — ~1.7x its observed max. The tail is far longer
than the typical run, so the median would have been the wrong basis.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant