Your Component Fits. But Is It Still Useful?
Responsive interfaces usually answer a geometric question:
Does this component fit in the available space?
But there is another question that is much harder to express:
Is the content still useful at that size?
Those two questions are not always equivalent.
A simple example
Imagine a dashboard panel with these constraints:
{
minWidth: 120,
minUsefulWidth: 180
}
At 200px, everything is fine.
The panel fits, and its content has enough room to remain useful.
At 150px, something more interesting happens.
The panel still satisfies its geometric minimum. Nothing necessarily overflows. The browser can render it perfectly well.
But perhaps:
- labels become cramped,
- a chart loses enough context to become difficult to interpret,
- controls remain technically accessible but awkward to use,
- or important information becomes harder to understand.
The component still fits.
But its content has started to degrade.
At 100px, the situation changes again: now the component violates its hard minimum width.
These are three different states.
VALID
The component satisfies its geometric constraints and its usefulness thresholds.
DEGRADED
The component still satisfies its hard geometric constraints, but one or more usefulness thresholds are no longer satisfied.
INVALID
A hard geometric constraint has been violated.
That middle state is the interesting one.
Geometry is not usefulness
CSS already gives us extremely powerful mechanisms for responsive design.
Media queries let us respond to viewport conditions.
Container queries let components respond to the dimensions of their containers.
Intrinsic sizing gives the browser sophisticated rules for determining how elements should occupy available space.
None of those technologies are the problem.
The question I'm interested in sits at a different layer:
What should a layout system do when geometry remains valid, but the content inside that geometry is no longer useful?
Consider a data visualization.
A chart might technically render at 160px wide. No overflow. No violated minimum width.
But perhaps its axis labels collide, the legend dominates the plot, or the amount of visible information becomes too small to communicate anything meaningful.
From the browser's perspective, the layout may still be valid.
From the application's perspective, it may have degraded.
Why model DEGRADED explicitly?
A binary model gives us:
VALID
INVALID
But adaptive interfaces often have a meaningful region between those states:
VALID
↓
DEGRADED
↓
INVALID
Making that middle state explicit gives the application another piece of information to reason about.
For example, a layout engine could decide to:
- reduce lower-priority content,
- switch to a more compact representation,
- move something elsewhere,
- reflow the surrounding layout,
- or simply expose the degraded state and let the application decide.
The important part isn't prescribing one universal response.
It's recognizing that "fits" and "remains useful" describe different constraints.
Exploring the idea with DnDGem
This distinction is what I've been exploring in DnDGem, an open-source adaptive layout engine.
DnDGem separates hard geometric constraints from content-usefulness constraints.
A simplified example looks like this:
{
minWidth: 120,
minUsefulWidth: 180
}
minWidth represents a hard geometric boundary.
minUsefulWidth represents the point below which the content is considered degraded, even though the component may still geometrically fit.
The resulting state becomes information that an adaptive layout system can use when evaluating layout decisions.
The goal isn't to replace CSS, media queries, container queries, or intrinsic sizing.
It's to explore an application-level question those mechanisms don't necessarily answer on their own:
When should an interface react to loss of usefulness rather than only loss of geometric fit?
Try the idea
I've written a more detailed explanation of the model, including the reasoning behind VALID, DEGRADED, and INVALID:
https://dndgem.dev/articles/geometrically-fits-content-remains-useful/
There's also an interactive playground:
https://playground.dndgem.dev/
But I'm particularly interested in how other frontend engineers approach this problem.
When a component technically fits but its content no longer works well, how do you represent that boundary in your applications today?
Top comments (0)