The Toolbar Redesign That Looked Finished Until It Rendered

The primary reader is a frontend engineer redesigning an existing application through CSS. The lesson is why structural compatibility does not guarantee visual compatibility.

The assumption that seemed reasonable

An established diagram editor already had working controls, IDs, keyboard shortcuts, and event handlers. The safest redesign strategy was therefore to preserve its markup and add a final stylesheet that changed palette, spacing, typography, and layout.

That assumption was mostly correct. The editor loaded, its canvas filled the workspace, and every control retained its event target. Because the tool strip used flex layout and already supported horizontal overflow, reducing button padding seemed sufficient to make the interface compact.

When it failed

The first real desktop screenshot showed a strip of colliding words. Select, Hand, Pen, Line, Rectangle, Polygon, Text, Wire, Measure, Lock, Smooth, Group, Ungroup, Straighten, Delete, and several style controls all remained visible.

The DOM reported no page overflow. The toolbar itself fit its assigned width. Automated functional checks all passed. Yet the interface was visibly unusable because text inside the controls collided and lost its grouping.

This is a useful category of failure: the box model can be valid while the information inside the boxes is not.

What was actually wrong

The old toolbar and the new toolbar served different interaction models. The original was label-first and roomy. The redesign was an instrument rack modeled on professional CAD software, where repeated creation tools are icon-first and grouped by stable position.

Reducing padding changed dimensions but did not change the information hierarchy. Every button still tried to explain itself continuously, even though its title, icon, section, and fixed location already carried that explanation.

The stylesheet had compressed containers without deciding which content should survive the compression.

What got removed

Visible text labels inside the lower tool rack were removed from layout. They were not deleted from markup, and the buttons retained descriptive title attributes and IDs. Section names such as Draw, Arrange, Style, Scale, Background, and Export remained visible.

.tool-strip .button .label {
  display: none;
}
.tool-strip .button {   width: 28px;   min-width: 28px;   justify-content: center; }

Inputs kept visible values because a color, stroke width, scale, or unit cannot be inferred from an icon alone. Document-level actions in the upper strip retained short labels at desktop widths and hid them only on narrower screens.

What replaced it

The toolbar became a two-level vocabulary. Group labels explain the category. Icons and stable position identify the action. Tooltips provide the full name on demand. A cyan active state shows what the next canvas gesture will do.

The browser verification then measured both the page and the toolbar:

const result = [...document.querySelectorAll('.tool-strip')].map(el => ({
  viewportWidth: el.clientWidth,
  contentWidth: el.scrollWidth,
  height: el.clientHeight,
}))

A second screenshot confirmed the human result: controls were distinct, group boundaries were readable, and the canvas remained dominant.

Why the automated checks missed it

Functional checks correctly answered whether tools still worked. Geometry checks answered whether the page overflowed. Neither could decide whether adjacent labels formed readable language.

Visual review was not a ceremonial final step; it tested a dimension that the existing suites did not model. Technical editors need both levels. Stable selectors and event tests protect behavior, while screenshots expose density, contrast, collision, and hierarchy.

The verification sequence that worked

The corrected pass used a production build rather than reading source files directly. That mattered because the application shell loads editor markup dynamically, and the deployment process copies a public tool into several destinations. A source stylesheet can be correct while a generated surface still serves an older copy.

The browser opened at a desktop viewport first. It recorded the rectangles for both tool strips, the canvas, and the navigation dock, then captured the full rendered page. The same page was resized to a narrow phone viewport. The test asserted that document scroll width still matched client width, the symbol library occupied a bounded share of the screen, and the canvas remained available behind it.

The right inspector exposed a separate specificity bug during this pass: its class changed to open, but a theme-scoped closed-position rule kept it offscreen. That defect would have escaped a test that inspected class names alone. Measuring the panel's right edge against the viewport closed the gap between internal state and visible behavior.

This sequence—production build, functional checks, computed geometry, desktop screenshot, and mobile screenshot—became the appropriate definition of done for a visual-system change. No one layer substituted for another.

The generalizable lesson

When transforming an existing interface, preserve behavioral contracts but reevaluate the information contract. Content designed for one layout does not automatically belong in another simply because CSS can squeeze it into place.

Compact design is subtraction with intent. Decide which labels teach structure, which values convey state, and which repeated actions can rely on icon, tooltip, and position. Then render the real interface before calling the redesign complete.