Skip to content

Fix right-side alignment of content area on non-homepage pages#2133

Merged
dscho merged 1 commit intogit:gh-pagesfrom
dscho:fix-alignment
Feb 20, 2026
Merged

Fix right-side alignment of content area on non-homepage pages#2133
dscho merged 1 commit intogit:gh-pagesfrom
dscho:fix-alignment

Conversation

@dscho
Copy link
Member

@dscho dscho commented Feb 17, 2026

Changes

Fix right-hand side alignment:

BeforeAfter
before after

Context

In 9f2a5ae ("Continue to display sidebar when page scrolls"), the layout of #content-wrapper was converted from floats to flexbox in order to support position: sticky on the sidebar. That commit removed float: left from aside and float: right from #content, and added display: flex to #content-wrapper.

However, the old float layout relied on the fact that #content was floated to the right: the sidebar (218px) and the content area (702px) together only add up to 920px inside a 940px container, with the remaining 20px forming a gap between them. With float: right, the content area was pushed flush against the right edge of the container, so its right edge aligned perfectly with the header above. After the switch to flexbox, both children are packed to the left by default (the initial value of justify-content is flex-start), leaving the 20px gap on the right side instead of between the two elements. This caused the right edge of the content area to be visibly misaligned with the right edge of the header's search bar and dark-mode toggle.

The fix is to add justify-content: space-between to #content-wrapper, which restores the original float-era behavior: the sidebar sits at the left edge and the content area sits at the right edge, with the 20px gap between them.

A Playwright test is included that verifies the right edge of #content is flush with the right edge of #content-wrapper. This test was used to bisect and confirm that the regression was introduced in 9f2a5ae.

Assisted-by: Claude Opus 4.6

In 9f2a5ae ("Continue to display sidebar when page scrolls"), the
layout of `#content-wrapper` was converted from floats to flexbox in
order to support `position: sticky` on the sidebar. That commit removed
`float: left` from `aside` and `float: right` from `#content`, and
added `display: flex` to `#content-wrapper`.

However, the old float layout relied on the fact that `#content` was
floated to the right: the sidebar (218px) and the content area (702px)
together only add up to 920px inside a 940px container, with the
remaining 20px forming a gap between them. With `float: right`, the
content area was pushed flush against the right edge of the container,
so its right edge aligned perfectly with the header above. After the
switch to flexbox, both children are packed to the left by default
(the initial value of `justify-content` is `flex-start`), leaving the
20px gap on the right side instead of between the two elements. This
caused the right edge of the content area to be visibly misaligned with
the right edge of the header's search bar and dark-mode toggle.

The fix is to add `justify-content: space-between` to `#content-wrapper`,
which restores the original float-era behavior: the sidebar sits at the
left edge and the content area sits at the right edge, with the 20px gap
between them.

A Playwright test is included that verifies the right edge of `#content`
is flush with the right edge of `#content-wrapper`. This test was used
to bisect and confirm that the regression was introduced in 9f2a5ae.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho requested review from To1ne and jvns February 17, 2026 13:06
@jvns
Copy link
Collaborator

jvns commented Feb 17, 2026

The fix makes sense to me, thanks for catching this! I double checked what the site looked like before 9f2a5ae, and there was indeed a gap between the sidebar and the content, it looked like this:

image

@dscho
Copy link
Member Author

dscho commented Feb 17, 2026

@jvns thank you for reviewing it! TBH the credit for finding this should go to @To1ne, I would never spot something like this...

@dscho dscho merged commit ae99354 into git:gh-pages Feb 20, 2026
1 check passed
@dscho dscho deleted the fix-alignment branch February 20, 2026 19:42
dscho added a commit that referenced this pull request Feb 20, 2026
## Changes

- Adds a Node.JS script to generate screenshots, mainly to support
opening PRs.

## Context

In PRs like #2133, it is good to
accompany the code changes and the explanation (including rationale!)
with a before/after comparison. This is oddly involved at the moment!

Historically, I used to whip out my trusty interactive
<kbd>🪟</kbd><kbd>Shift</kbd><kbd>S</kbd> screenshot shortcut, and kind
of aimed to catch the same areas before and after making my change.
Then, I pasted them into the PR description and surrounded them by
Markdown table markup. Quite tedious, if I'm honest!

So here's a script that automates a lot of that. It can even be used to
re-build the site locally from two given revisions, and then take
snapshots of those pages, using Playwright. It also allows to clip the
areas to capture via specifying pixel values, which is admittedly not
_that_ convenient, but I couldn't find a better way.

The output is a copy/paste'able bit of Markdown/HTML with the images'
absolute paths inserted: There is no API to upload images to GitHub PRs,
and therefore they have to be uploaded manually. At least this way, the
user can copy the entire Markdown, paste it into the PR description
editor, then cut the first path to the clipboard, click the "Paste,
drop, or click to add files" button below the editor, paste the path,
then repeat with the second path.

This is precisely what I did over in #2133, with the tell-tale `<!--
Generated by 'node compare-screenshots.js --clip=256x256+900+0
https://git-scm.com/about https://dscho.github.io/git-scm.com/about'
-->` comment in the PR body (can be seen here:
https://api.github.com/repos/git/git-scm.com/pulls/2133).
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.

2 participants