The layout bug that vanished when I changed the copy

The bug that only existed between 1024px and 1280px

The bug showed up as a horizontal scrollbar on a Gate Seal product page, but only on screens between 1024px and 1280px. Below that, the layout was fine. Above that, also fine. At exactly 1120px, the container would overflow by 14 pixels and trigger a horizontal scroll.

The section was a two-column layout with a product image on the left and a “Key Features” list on the right.

I spent an hour in DevTools hunting for a margin, padding, or min-width that could explain those extra 14 pixels.

When the CSS is technically correct

The CSS for the layout was straightforward:

• A grid with grid-template-columns: 1fr 1fr;
• gap: 2rem (Tailwind’s gap-8)
• The image set to max-width: 100%;
• The text column with no fixed width

I checked the computed styles, the box model, and the paint layers. Nothing exceeded its container. No child reported a width larger than the grid. The overflow was invisible in the DOM because it was not a layout property causing it; it was a content property.

The invisible constraint: one very long “word”

The culprit was a single feature list item:

“Corrosion-resistant marine-grade stainless steel construction with dual-sealing technology.”

In the client’s brand font at 1.125rem, that string rendered at 1012px wide on the specific Chromium engine used by the QA tester. Because the text was a single unbroken conceptual unit, it refused to wrap naturally at the hyphenation points. The browser treated it as one massive word that pushed the column beyond its 1fr allocation.

I wrote about this earlier in CSS Flexbox For Adaptive Fitness Dashboards That Don’t Suck On Mobile.

The overflow was not caused by a CSS property like min-width or a rogue width. It was caused by the typography’s relationship with the content’s syllable structure.

The grid was fine. The English was too wide.

Fixing the layout by fixing the sentence

Once that became clear, the fix was simple. I changed the copy to:

“Marine-grade stainless steel. Dual-sealing design.”

The period created a natural break. The line wrapped. The column shrank back to its grid allocation. The horizontal scrollbar vanished.

The client thought I had fixed a browser bug. I told them I had fixed a sentence. They laughed. But it is the most accurate description of what happened. The layout was not broken; the content was too long for the layout’s grammar.

Defensive CSS is still useful

After the copy change, I added one line to the component as a defensive measure:

.feature-list {
  overflow-wrap: break-word;
}

This gives the browser permission to break long words if it has to. It is a safety net for situations where some future piece of content might again behave like one giant word.

More on this in my article Content breakpoints for a single hero component.

But the real fix was still the copy. The CSS rule is a guardrail. The sentence rewrite is what actually brought the layout back in line with the design intent.

The longest string as a layout constraint

This bug changed how I think about “finished” layouts. It taught me that the longest string in a component is an implicit layout constraint. The longest word, or the longest unbroken phrase, often dictates the minimum practical width of a column more decisively than any min-width property I could write.

I now paste the client’s raw text into the layout before I finalize the CSS, because that is the only way to see the real constraints. If the marketing copy stacks five adjectives, three nouns and a trademark into one bullet point, the layout has to absorb that somehow. Or the copy has to change.

Content, design and CSS are not separate layers

This is a small example, but it shows how content, design and CSS are not really independent. On this page:

• The design said: two equal columns, image and key features.
• The CSS said: 1fr / 1fr grid, fluid, no fixed widths.
• The content said: I am one long technical brag, and I refuse to break nicely.

The bug only appeared at a specific viewport width because that is where these three forces lined up in exactly the wrong way. A slightly narrower screen would have forced a different wrap. A slightly wider screen gave the text enough space. Only at 1120px did the sentence grow just enough to push the column 14 pixels too far.

Read also Why I Prototype Motion Before Polishing Layout.

Frontend debugging is often linguistic, not just mathematical. You are not only balancing percentages and pixels. You are also negotiating with the shapes and breaks of actual language in a specific font.

Designing for real sentences

One practical takeaway: treat copy as a structural element, not as filler. If a component is likely to contain long technical phrases, legal text, or brand slogans, design and build for that from the start.

• Test layouts with the client’s raw, worst-case strings.
• Agree on sensible line lengths and bullet styles with whoever writes the copy.
• Use defensive CSS like overflow-wrap in places where long strings are likely.
• Be willing to say: “This sentence is breaking the design. Can we rewrite it?”

On the Gate Seal page, the grid implementation was fine. The design intent was fine. The content needed one extra period. That was enough to turn a layout bug into a non-issue.