chore(ui): improve width of containers

[avivkeller]

Partially fix/es nodejs/doc-kit#954 by expanding the main content (if possible) and the change history

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nodejs-org	Ready	Preview	Jul 28, 2026 10:46pm

[cursor]

PR Summary

Low Risk
CSS-only layout tweaks in shared UI components with no logic, auth, or data changes.

Overview
Widens documentation layout so main article content and the change-history menu can use more horizontal space (partially addresses doc-kit #954).

Change history dropdown panel grows from a fixed narrow width (w-52) to 26rem, with max-w-[calc(100vw-2rem)] on small viewports; the scrollable inner area follows the wrapper via w-full instead of a duplicate fixed width.

Article layout drops max-w-10xl and mx-auto on .articleLayout, so the grid stays full width instead of capping and centering the page shell.

^{Reviewed by Cursor Bugbot for commit 624748c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.13%. Comparing base (c086c54) to head (624748c).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9032      +/-   ##
==========================================
+ Coverage   75.10%   75.13%   +0.03%     
==========================================
  Files         102      102              
  Lines        9109     9109              
  Branches      372      372              
==========================================
+ Hits         6841     6844       +3     
+ Misses       2264     2261       -3     
  Partials        4        4              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 624748c. Configure here.}

[github-actions]

📦 Build Size Comparison

Summary

Metric	Value
Old Total First Load JS	10.65 MB
New Total First Load JS	10.65 MB
Delta	0 B (0.00%)

[bjohansebas]

Text should have a maximum line width of 80ch for better readability and UX: https://baymard.com/blog/line-length-readability

[bjohansebas]

https://web.dev/articles/min-max-clamp#width

[avivkeller]

I can either:

1. Revert this part of the change
2. Make prose use up to 80ch, but tables and code blocks still expand

[davidje13]

FWIW as the person who requested an increase in width:

• From my own experiments swapping out the styles in the documentation, I find it more readable and more skimmable when wider
• Even just a small increase of 6rem to the total page width made it significantly more comfortable to read (see the screenshots at the top of the issue I raised: Feedback: request for various minor style changes doc-kit#954 (comment))
• The oft-cited recommended width limit was figured out for long-form content of plain text, but the documentation mostly contains relatively short paragraphs and is full of inline code and indented list blocks
• The existing content is already quite a bit wider than 80ch, and reducing it to that size makes it very hard to skim (makes it feel a lot more like reading a book, but this is not a book!)
• This only affects relatively large screens, which are presumably biased towards people who prefer seeing more content at a time (like me!). On regular/smaller screens, the content is limited by the presence of the sidebars
• If people on larger screens prefer narrower content, they can easily increase the page zoom or reduce the window size using normal browser/OS controls. But the reverse is not true when size limits are coded into the page.

I wonder if maybe there are competing preferences due to this style being used for both the API documentation and other pages? I could imagine non-API pages may be more readable when narrow, so it might be worth foregoing some consistency to have each page more tuned to its own content. But as I noted above, even if all pages are allowed to be larger, users can always make the content narrower if desired using the browser and OS controls.

[AugustinMauroy]

Can we have stories for that change so if there are future change we will know what happened

[avivkeller]

Can we have stories for that change so if there are future change we will know what happened

I don't know if stories will cover this kind of dynamic change