In 2026, when flex items sit in a row, why is text usually the first to get squeezed out on narrow screens?

When flex items sit in one row, the element that gets squeezed out first on narrow screens is often text. This is not a wrong width value; it is two default values at work: flex-shrink defaults to 1, and a child item’s automatic minimum size is determined by min-width: auto. In 2026 project delivery, the diagnostic order matters more than changing properties: first confirm whether the parent is a flex container, then check the main axis and compression ratio, and only then touch width. With this order, most issues can be located within an experience range of half an hour to two hours.

What gets squeezed is not width; it is flex’s default compression and minimum size

Along the main axis of a flex container, a child item’s size is first calculated from flex-basis, width, and content size. When space is insufficient, flex-shrink then allocates compression. The default flex-shrink: 1 makes all compressible child items shrink proportionally, so width is only a starting size, not a fixed size. This is also why repeatedly changing width appears to have no effect.

The second layer comes from min-width: auto. It means a child item usually will not be compressed smaller than its own content. With long English words, unbreakable text, or fixed-size images, compression stops at this content minimum-size line, leading to two opposite phenomena: either it cannot be compressed any further no matter what, or the text is squeezed into a single narrow column. The same rule behaves differently depending on whether the content can break.

• Precondition: the parent must be display: flex or inline-flex; normal block layout does not have this compression rule.
• Direction: compression only happens on the main axis. With flex-direction: row, width is compressed; with column, height is compressed.
• Defaults: flex-grow defaults to 0, flex-shrink defaults to 1, flex-basis defaults to auto, and min-width defaults to auto.
• Diagnostic criterion: if the element becomes narrower but its content remains intact, it is merely being compressed; if content is clipped or overflows, it is stuck at the minimum size, and the fix is different.

Check in order: container first, then compression, and only then the fix location

If you directly change width or add flex-shrink before determining the direction, a common result is that the outer layer is fixed while the inner layer collapses, leading to repeated revisions. Following the four steps below usually converges in one round.

1. Confirm the container and main axis: check whether display is flex and what flex-direction is, first ruling out that it is not a flex container at all.
2. Look at the child item’s flex shorthand: flex: 1 expands to 1 1 0%, with a basis of 0, so it can easily be compressed smaller than its content; flex: auto expands to 1 1 auto, with the basis taken from content size, making it relatively more resistant to compression.
3. Differentiate being compressed from being held up by content: for the former, adjust flex-shrink; for the latter, look at min-width and whether text can break. The two cannot be treated interchangeably.
4. Decide which layer to change: if you do not want an item compressed, give that child flex-shrink: 0 or flex: none; if you want text truncation, then give it min-width: 0 together with overflow and text-overflow.

Acceptance can be concrete: stretch the container width to the typical small-screen range of 320–375px. The key button must still be fully visible, the title must show an ellipsis as expected, and the page must not show a horizontal scrollbar. Only when all three are true is the fix considered complete.

Comparison of three fix approaches: the same squeeze can cause new problems if you choose wrong

Even when child items are squeezed in the same way, there are three common code-level fixes, and they apply to different targets. Before choosing a fix, ask: when the container narrows, should this element change with it, or should it stay fixed?

• flex: none, i.e. 0 0 auto: neither grows nor shrinks; it follows width or content width. Suitable for fixed-width sidebars, icon buttons, and action columns. The trade-off is that it overflows directly when space is insufficient.
• flex-shrink: 0 with width: keeps the ability to grow but does not allow compression. Suitable for elements that should not deform, such as avatars, switches, and status labels.
• min-width: 0 with ellipsis: allows an item to be compressed smaller than its content, then works with overflow: hidden and text-overflow: ellipsis for single-line truncation. Suitable for long text such as titles, addresses, and usernames.
• Long English words or URLs: min-width: 0 alone is not enough to break continuous characters; you usually also need line-breaking handling such as overflow-wrap: break-word.

In terms of experience range, when only one min-width: 0 is changed and small-screen verification is done, the typical handling time is half an hour to two hours; if every element in the row is set to flex-shrink: 0, later rework to troubleshoot horizontal scrolling is more likely to stretch beyond half a day. To judge whether a fix is good, do not look at whether the property was written, but at whether elements that should not deform remain stable as the container continues to narrow, and whether elements allowed to truncate consistently show an ellipsis.

On delivery: why did one width change make the whole row wrap?

In cross-platform H5 list items, the structure is often an avatar, a title, and a status label. The design file was PC-only, and the delivery constraints were that older Android WebView versions still had to be supported and the design could not be changed. The approach at the time was to set min-width: 0 plus an ellipsis on the title, and flex: none on the elements on both sides. It worked on PC, but after release, on some Android models the title was squeezed into a single column of two characters, the status label was pushed off-screen, users could not see the current status, and feedback clustered around the same spot. In the end, switching the title to flex: 1 1 auto and adding a width cap resolved it, costing an extra half day to one day in the experience range. Later, projects like this made small-screen real-device testing a direct acceptance item.

The root cause of rework is usually not the API, but that only the visible layer was handled. Here are several high-frequency pitfalls to check against:

• Changing only a child item’s width without touching flex-shrink means compression still happens.
• Adding flex-shrink: 0 to every child in a row makes the whole row overflow when the container narrows, producing a horizontal scrollbar.
• Writing text-overflow: ellipsis without giving min-width: 0 means the ellipsis never appears.
• In nested flex, changing only the outer layer leaves the inner container still participating in compression with default values.

Applicable scenarios and boundaries where it does not apply

This rule set is suitable for layouts where multiple elements in one row need to scale proportionally and some of them must not deform. It is also suitable for titles or list items that need single-line text truncation. To judge whether it applies, first ask: when the container narrows, which elements should change and which should not? If you can answer that, flex compression control is a good fit.

Conversely, when only two or three fixed-size blocks are placed side by side in a simple row and do not need to scale with the container, grid or normal block layout is more readable, and forcing flex-shrink onto them only increases comprehension cost. Scenarios that need to display multi-line text are also not suitable for being forced into single-line truncation; the result of forcing it is usually missing key information.

There is another boundary: flex compression rules only apply along the main axis of a flex container. If the container is not flex, or the direction that needs compression falls on the cross axis, then no matter what flex-shrink is set to, it will have no effect. In that case, go back to the container layout itself to diagnose.

Common questions

Why is a child element still compressed on narrow screens even though width is set?

Because width is only a starting size on the flex main axis. The default flex-shrink: 1 compresses it proportionally; whether it can be compressed smaller also depends on the default min-width: auto.

After adding min-width: 0, the ellipsis still does not appear. What should I check first?

First check whether any nested flex layer in between also has min-width: 0, then confirm the element has overflow: hidden and text-overflow: ellipsis, and that its width is actually constrained by the container.

How do flex: 1 and flex: auto differ in compression resistance?

flex: 1 expands to 1 1 0%, with a basis of 0, so it is easy to compress smaller than its content; flex: auto is 1 1 auto, with the basis taken from content size, so it is relatively less likely to be flattened.

Does this diagnostic approach also apply to Grid layout?

No. Grid does not have the flex-shrink mechanism. Sizes are determined by tracks, fr, and minmax(), so you need to check track definitions and min-width settings.

Next time flex child items get squeezed, it is advisable to first go through the four-step check to confirm where the rule is acting, then decide whether to add flex-shrink: 0 or min-width: 0, and finally test horizontal scrolling and ellipsis on a small-screen range. If the layout itself is just a few fixed blocks side by side, or needs to display multi-line text, continuing to use flex compression control only increases maintenance cost, and switching to another layout method is simpler. For projects involving multi-platform adaptation, it is advisable to add this acceptance item to the delivery checklist before starting work.