Fixed vs Flexible Layouts: Content-Based Sidebar Width with CSS Grid

1 Requirements

The goal is to add a project sidebar to the pipeline detail page. When the window widens, the main content should gain the extra space while the sidebar keeps a width suitable for navigation text.

2 Initial Implementation

The first version used a two-column layout with the sidebar taking 34% of the container and the main content using the rest. The sidebar contained project entries; the main area displayed pipeline information.

Figure 1: Sidebar width changes proportionally with the container.

3 Problem Analysis

3.1 Main Issues

When the window widens, the sidebar continues to grow even though the menu text does not increase; that space could be used for the pipeline main body. When the window narrows, the sidebar may shrink below a readable width for the text.

The percentage relationship expresses that both columns scale together, but it does not describe each area's content needs.

3.2 Design Principles

Areas that need to scale together can use proportions. Areas with stable content requirements should have their width determined by content first, letting other areas take the remaining space.

Cards with known suitable widths can also set a maximum width and shrink only when space is insufficient. This discussion focuses on layout decisions; CSS Grid can still be used to implement the fixed-and-flexible combination.

4 Optimized Implementation

4.1 Area Responsibilities

In this example the sidebar is set to 180px, and the main content uses the remaining space. The 180px is chosen after confirming that navigation text is readable at the target font size, then verifying that the main area can accommodate stages and run information.

Card interiors can still arrange their own column widths based on content; they do not need to share the outer navigation's proportion.

4.2 CSS Implementation

.project-layout {
  display: grid;
  grid-template-columns: 180px minmax(0, 1fr);
  gap: 18px;
}
.project-main { min-width: 0; }

min-width: 0

allows the main area to shrink, but it does not automatically handle long strings inside. Artifact URLs still need wrapping; tables can adopt controlled scrolling depending on use case.

4.3 Narrow-Screen Switching

Continuously narrow the window and observe where the menu, stages, and actions start to not fit; then decide when to fold the menu or change the arrangement.

180px is the content-based width for this example; it does not mean every screen must force the same sidebar width. After switching on narrow screens, also verify navigation accessibility and current-location indication.

5 Effect Verification

Figure 2: Sidebar width determined by content; main area grows flexibly.

The images show the allocation change on the same canvas; the responsive behavior must be verified on the actual page.

☐ On wide screens, most new space goes to the main content.

☐ Menu text displays normally at the current sidebar width.

☐ Narrow-screen switching and long-address handling do not cause whole-page horizontal overflow.

6 Application & Practice

Continuously adjust the pipeline page width and record where the menu, run table, and deployment cards each start to break.

Deliver a region-division diagram that marks fixed widths, flexible widths, maximum widths, and switching conditions, and explains how each relates to the content.