fix: make the contents sidebar width independent of Tailwind emission order - #135
Closed
mmcky wants to merge 1 commit into
Closed
fix: make the contents sidebar width independent of Tailwind emission order#135mmcky wants to merge 1 commit into
mmcky wants to merge 1 commit into
Conversation
… 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 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR removes an unintended duplicate, unprefixed Tailwind width utility from the Contents sidebar so its base-width no longer depends on Tailwind’s arbitrary-value rule emission order.
Changes:
- Removed the stale
w-[250px]from the Contents sidebar container class list, leaving a single coherentw-[350px] lg:w-[250px] 2xl:w-[350px]width definition. - Added an inline comment explaining why duplicate unprefixed width utilities are problematic in this case (Tailwind emission-order dependence).
- Documented the fix in
CHANGELOG.mdunder Unreleased.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| CHANGELOG.md | Adds an Unreleased “Fixed” entry describing the sidebar width emission-order issue and resolution. |
| app/components/ContentsSidebar.tsx | Removes the duplicate unprefixed width utility and adds a comment clarifying the intended width behavior across breakpoints. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
|
Contributor
🎭 Visual regression results
Details
Skipped testsmobile-chrome › theme.spec.ts › QuantEcon theme — visual regression › launch-colab |
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deletes the stale unprefixed
w-[250px]from the Contents sidebar, so the panel's width stops depending on Tailwind's rule-emission order.The problem
ContentsSidebar.tsxput two unprefixed width utilities on the same element, split across two adjacent class strings:The responsive line reads as the intent — 350px at base, 250px from
lg, 350px again from2xl. The trailingw-[250px]is a leftover from before that line existed. Both are unprefixed, both land in Tailwind's base layer, and neither is more specific, so which one applies belowlgis decided purely by which rule Tailwind emits last.The rendered result was correct today, but only by accident: Tailwind sorts arbitrary values as strings,
[250px]sorts before[350px], and the 350px rule wins by landing later. That holds only while the two numbers keep their current relative order, and nothing pins it. Change the base width to anything sorting before250pxand the stale class silently takes over — the edit looks like it did nothing, and there is no error anywhere to explain why.Verification
npm run build:css, then probing the emitted stylesheet:.w-[250px]{width:250px}.w-[350px]{width:350px}lg:w-[250px]2xl:w-[350px]The ambiguous base rule is gone and both responsive variants survive, so the bands still resolve 350 / 250 / 350 across base /
lg/2xland nothing moves on screen.npm run compileis clean.The
visualjob against the untouched-linuxbaselines is the real acceptance criterion here: since this is a no-op at render time, a green run is the proof. If it reports a diff, the diagnosis was wrong and this should not merge.Locally:
npm run compileclean, and the full visual suite is 19 passed, 0 failed with every committed baseline untouched — which is the render-level proof that nothing moved.Note
If the visual suite behaves strangely for you locally, check for a leftover theme server before suspecting the branch:
pkill -f "node ./server.js". A stale process holding port 3000 makesmyst startproxy to whatever theme build it was launched with, which presents as widespread snapshot and DOM failures unrelated to the code under test. That is what it did to me here before I spotted it.Closes #130
🤖 Generated with Claude Code