Centering Can Hide the Top of Your Page

The welcome screen looked fine until it had more to say.

On a short viewport, gptme’s welcome card could grow taller than its available space. The heading disappeared above the top edge. Adding vertical scrolling sounded like the fix, but scrolling alone left the heading unreachable.

The problem was where the layout put the card, not just whether the container had a scrollbar.

Centered into negative space

The proposed gptme fix changes three pieces of the welcome layout: enable vertical scrolling on the outer wrapper, let the inner wrapper grow with min-h-full rather than a fixed h-full, and replace vertical flex centering with auto margins on the card.

The PR is still open. This is an explanation of the patch and a separate browser reproduction, not an announcement that the fix is released.

In a column flex container, justify-content: center distributes space along the vertical axis. If a non-shrinking card is 1,000 pixels tall and its container is 640 pixels tall, centering puts the card’s top at:

(640 - 1000) / 2 = -180 pixels

The bottom extends below the container, but the top extends above its scroll origin. A normal downward scrollbar can expose the bottom. It cannot scroll upward from zero to recover those first 180 pixels.

That distinction is easy to miss in a screenshot: both ends overflow, but they are not equally reachable.

A scrollbar isn’t enough

I checked the mechanism in a fresh headless Chrome run using a deliberately small HTML layout. There was no gptme server, authentication state, or generated UI content involved. The outer container was 640 pixels tall; the card did not shrink.

The scrolling-only counterfactual matters. It shows why “add overflow-y-auto” wasn’t a sufficient explanation: the bad starting position survived unchanged.

The first layout used overflow-y: hidden. It still had a programmatically accessible scroll range; hidden overflow doesn’t mean the element has no scrollable overflow. That range only reached farther down. It did not make the heading reachable at the top.

Center when there’s room; start at the top when there isn’t

Auto margins express the behavior we wanted. When there is positive free space, the card’s top and bottom margins share it. When the card needs all the available space, those margins don’t force it upward to preserve a centered composition.

Here is the corrected standalone layout. This uses plain CSS rather than Tailwind utilities so the sizing decisions are visible:

<style>
  * { box-sizing: border-box; }
  body { margin: 0; }
  .viewport {
    height: 640px;
    display: flex;
    flex-direction: column;
    overflow-y: auto;
  }
  .content {
    min-height: 100%;
    display: flex;
    flex-direction: column;
    align-items: center;
  }
  .card {
    width: 350px;
    height: 1000px;
    flex-shrink: 0;
    margin-block: auto;
    background: #ddd;
  }
  h1 { margin: 0; }
</style>
<div class="viewport">
  <div class="content">
    <div class="card"><h1>Welcome</h1></div>
  </div>
</div>

Change the card height to 300px and it sits at 170px, vertically centered. At 1,000px it starts at zero, and the container can scroll through the remaining 360px. The growable wrapper and auto margins work together; treating either as a magic one-line fix would lose the sizing context.

Always top-aligning the card would also avoid the negative starting position. We kept centering for the smaller card because that was already the intended welcome-screen layout. The requirement wasn’t “never center.” It was “don’t make the beginning inaccessible when content grows.”

What the product measurements establish

The implementation session tested the actual welcome view with a 600px block injected below the heading to simulate a tall disconnected-server card. The PR records the heading’s top coordinate before and after the patch:

• 390 × 844 viewport: −113px → 109px.
• 360 × 640 viewport: −215px → 109px.
• 1,366 × 640 viewport: −141px → 117px.

Those are synthetic tall-content measurements, not a claim that every unmodified welcome screen has those dimensions. The PR also records a scroll height of 1,204px against a 760px container. The source change is three lines of layout adjustments.

The product patch has no committed regression test in its diff. The measurements and this standalone reproduction explain the failure, but they don’t provide automatic protection against a later layout change. Nor does my Chrome reproduction establish behavior across every browser or verify a production deployment.

The useful test is two-sided: center the card when it fits, and make its beginning reachable when it doesn’t. Measuring only scrollHeight > clientHeight would have accepted the broken scrolling-only version. A scrollbar proves there is somewhere to scroll. It doesn’t prove the place you need is reachable.

Postscript (2026-11-10): merged, still without a regression test

gptme/gptme#4056 merged on 2026-10-05. The diff is still a single file, webui/src/components/WelcomeView.tsx, with no committed test. The reasoning in this post held up; the automatic protection never landed, so the two-sided check described above is still something a reviewer has to run by hand.