From 8a0bc1a70c9a6f1deccd27add90481107bb61ffb Mon Sep 17 00:00:00 2001 From: Matt McKay Date: Thu, 20 Aug 2026 15:27:41 +1000 Subject: [PATCH] fix: make the contents sidebar width independent of Tailwind emission order The panel carried two unprefixed width utilities on the same element, split across adjacent class strings: `w-[350px]` from the responsive line and a stale `w-[250px]` on the next one. Both land in Tailwind's base layer at the same specificity, so which applies below `lg` was decided purely by which rule Tailwind emitted last. The rendered result was correct today only by accident: Tailwind sorts arbitrary values as strings, so `[250px]` sorts before `[350px]` and the 350px rule wins by landing later. Change the base width to anything sorting earlier and the stale class silently takes over, with no error anywhere to explain why the edit appeared to do nothing. Deleting the stale utility leaves `w-[350px] lg:w-[250px] 2xl:w-[350px]` as the single source of the width. Verified against a Tailwind build: the ambiguous base-layer `.w-[250px]` rule is gone while the `lg` and `2xl` variants are untouched, so the bands still resolve 350/250/350 and no pixels move. Closes #130 Co-Authored-By: Claude Fable 5 --- CHANGELOG.md | 13 +++++++++++++ app/components/ContentsSidebar.tsx | 6 +++++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 31d1be0a7..2f3f7be09 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## [Unreleased] +### Fixed +- The Contents sidebar's width below `lg` no longer depends on Tailwind's + rule-emission order. The panel carried two unprefixed width utilities on the + same element — `w-[350px]` from the responsive line and a stale `w-[250px]` + on the next class string — which land in the same layer at the same + specificity, so the base band resolved to 350px only because Tailwind sorts + arbitrary values as strings and `[250px]` sorts before `[350px]`. Change the + base width to anything sorting earlier and the stale class silently took + over, with no error to explain why. The stale utility is gone, leaving + `w-[350px] lg:w-[250px] 2xl:w-[350px]` as the single source of the width. + Nothing moves: the resolved widths stay 350/250/350 across the base/`lg`/`2xl` + bands ([#130](https://github.com/QuantEcon/quantecon-theme.mystmd/issues/130)). + ## [2.3.0] - 2026-08-20 > Headline: lecture pages gain **in-page live compute** (a JupyterLite/Pyodide diff --git a/app/components/ContentsSidebar.tsx b/app/components/ContentsSidebar.tsx index a22a86815..3b7f1d856 100644 --- a/app/components/ContentsSidebar.tsx +++ b/app/components/ContentsSidebar.tsx @@ -103,8 +103,12 @@ export function ContentsSidebar() { // this panel off-screen on the very first paint — before app.css lands. 'qe-contents-sidebar', 'fixed top-0 left-0', + // Every band of the panel width lives on this one line. A second + // unprefixed width anywhere in these class strings lands in the same + // layer at the same specificity, so which one wins below `lg` would be + // decided by Tailwind's emission order rather than by intent (#130). 'w-[350px] lg:w-[250px] 2xl:w-[350px]', - 'h-screen w-[250px] z-[20] pt-[40px] pb-[90px] px-9', + 'h-screen z-[20] pt-[40px] pb-[90px] px-9', 'bg-qetoolbar-light dark:bg-qetoolbar-dark ', 'border-r-[1px] border-qetoolbar-border', 'overflow-y-auto',