feat: colour content links QuantEcon blue to match the Sphinx lectures - #167
Conversation
myst-to-react colours content anchors via the .link and .hover-link classes, which @myst-theme/styles paints blue-700/blue-400 with its own blue decoration colours. The Sphinx lecture builds render links in the QuantEcon palette instead: #0072bc base, #004979 on hover, white in dark mode (their dark theme paints all anchors white). New CONTENT LINKS section in styles/quantecon.css overrides both classes at specificity matched to each upstream rule, winning every tie on source order; the colours are design tokens (--qe-link-color, --qe-link-hover-color) with dark variants. The underline now draws in currentColor rather than upstream's separate blue decoration utilities. Colour only: the always-on underline and unstyled :visited are left as upstream ships them (the Sphinx builds underline on hover only and colour visited links #004979). Verified on the visual fixture: content links compute to rgb(0,114,188) base / rgb(0,73,121) hover in light mode and white in dark, decoration matching, while the footer badge and back-to-top keep their own rules. Darwin baselines refreshed; suite verifies at 19 passed / 3 skipped. Linux baselines need /update-snapshots once a PR is open.
|
🎭 Visual regression results
Details
Skipped testsmobile-chrome › theme.spec.ts › QuantEcon theme — visual regression › without JavaScript › drawer-opens-without-javascript |
There was a problem hiding this comment.
🟢 Approval recommended
It is an isolated, colour-only CSS change whose specificity, cascade-layer, and source-order reasoning I verified against the exact pinned upstream version, with no objective issues found.
Pull request overview
This PR colours in-content links to match the QuantEcon Sphinx lecture builds. It adds two design tokens (--qe-link-color: #0072bc, --qe-link-hover-color: #004979) with dark-mode overrides (both white), and a new CONTENT LINKS section in styles/quantecon.css that re-colours the myst-to-react .link and .hover-link classes, drawing the underline in currentColor so it always tracks the text. The change fits the theme's established pattern of overriding @myst-theme/styles classes in quantecon.css's @layer components by matching specificity and winning on source order, rather than using !important. Site chrome (footer badge, back-to-top) is unaffected because those selectors carry higher specificity.
Changes:
- Add
--qe-link-color/--qe-link-hover-colortokens with.darkoverrides (white in both states). - Add a
CONTENT LINKS@layer componentsblock re-colouring.link/.hover-link(base, hover, and dark variants) at specificity matched to upstream@myst-theme/styles@1.3.0. - Update the neighbouring dark-mode anchor comment to reflect that
.linknow takes its colour from the new section.
File summaries
| File | Description |
|---|---|
| styles/quantecon.css | Adds link-colour design tokens and a specificity-matched CONTENT LINKS override section (colour-only), plus a clarifying comment update on the dark-mode anchor rule. |
I verified the cascade reasoning against the pinned dependency: upstream @myst-theme/styles@1.3.0 defines .link/.hover-link in @layer components via @apply text-blue-700 dark:text-blue-400 … decoration-blue-400 dark:decoration-blue-500 hover:… dark:hover:…, so the override lands in the same layer, matches specificity (base 0,1,0; hover 0,2,0; dark 0,2,0; dark-hover 0,3,0), and wins because quantecon.css is @import-ed after @myst-theme/styles (styles/app.css:4,9). The "dotted for .hover-link" note is accurate (styles/hover.css applies decoration-dotted), and footer/back-to-top selectors retain higher specificity, so chrome is unaffected. No stale tests hardcode link colours.
Review details
- Files reviewed: 1/12 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…colour # Conflicts: # tests/visual/__snapshots__/desktop-chrome-darwin/features.png # tests/visual/__snapshots__/desktop-chrome-darwin/history-open.png # tests/visual/__snapshots__/desktop-chrome-darwin/intro.png # tests/visual/__snapshots__/desktop-chrome-darwin/lists.png # tests/visual/__snapshots__/desktop-chrome-darwin/notebook.png # tests/visual/__snapshots__/desktop-chrome-darwin/sidebar-open.png # tests/visual/__snapshots__/mobile-chrome-darwin/features.png # tests/visual/__snapshots__/mobile-chrome-darwin/history-open.png # tests/visual/__snapshots__/mobile-chrome-darwin/intro.png # tests/visual/__snapshots__/mobile-chrome-darwin/lists.png # tests/visual/__snapshots__/mobile-chrome-darwin/notebook.png
Filed under [Unreleased] after merging main. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The colour change sits under the 1% pixel threshold, so a plain --update-snapshots rewrote nothing; recorded with --update-snapshots=all so the QuantEcon blue is the baseline state on every page with a link. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
/update-snapshots |
|
🎭 Refreshed visual baselines in 763fef9:
|
The update-snapshots workflow pushes with GITHUB_TOKEN, which leaves the CI run waiting for approval.
|
Thanks @DrDrij. I checked the cascade argument against the installed As with #165 and #166 I pushed a few commits on top to get it mergeable after those two landed; push back on any of them.
CI is green on the final head, so this is ready to merge from my side. The hover-only underline and |
Summary
Colours content links to match the Sphinx lecture builds (e.g. python-programming.quantecon.org):
#0072bcbase,#004979on hover, white in dark mode.myst-to-react colours every content anchor through two classes —
.link(plain links) and.hover-link(cross-references, citations, footnotes) — which@myst-theme/stylespaints blue-700/blue-400 with separate blue decoration colours. A new CONTENT LINKS section instyles/quantecon.cssoverrides both classes at specificity matched to each upstream rule (base, hover, and their dark variants), winning every tie on source order. The colours are design tokens (--qe-link-color,--qe-link-hover-color) with dark-mode overrides, and the underline now draws incurrentColorso it always matches the text — replacing upstream's independent decoration utilities.Dark mode goes white in both states, which is what the Sphinx dark theme does (
&.dark-theme a { color: #fff !important }) and what this theme's existing.dark .article :where(a)rule already did for anchors without a.linkclass — the two now agree.Colour only, by design. Two Sphinx behaviours are deliberately not matched here (noted in the code): the lecture builds underline only on hover, and colour
:visitedlinks#004979. Happy to follow up on either.Site chrome is untouched:
.link/.hover-linkare only applied by the content renderers, and the footer badge and back-to-top button keep their own higher-specificity rules (verified unchanged).Testing
rgb(0, 114, 188)base /rgb(0, 73, 121)hover, dark white in both states, decoration colour matching the text in all four. Values match the Sphinx theme's SCSS source (a { color: #0072bc },a:hover { color: #004979 }).#0072bcon white is 5.05:1 — WCAG AA.Known follow-up
/update-snapshotsonce this PR is open.