Geometrically Fits ≠ Content Remains Useful

Minimum size isn't always minimum useful size

A layout constraint might say:

minWidth: 120

Below 120 pixels, the component cannot satisfy its hard minimum width.

But an application may have another threshold:

minWidth: 120
minUsefulWidth: 180

Now we can describe something that a single minimum dimension cannot express.

Assuming no other constraint is violated:

width ≥ 180px
→ VALID

120px ≤ width < 180px
→ DEGRADED

width < 120px
→ INVALID

At 240px, the component fits and has enough useful space.

At 150px, it still geometrically fits, but it has crossed its usefulness threshold.

Below 120px, its hard geometric constraint can no longer be satisfied.

That gives us three meaningfully different states:

VALID
    hard geometry is satisfied
    usefulness constraints are satisfied

DEGRADED
    hard geometry is still satisfied
    one or more usefulness constraints are missed

INVALID
    one or more hard geometric constraints cannot be satisfied

DEGRADED is the interesting state.

Without it, two different questions tend to collapse into one:

Can I place this component here?

Should this component remain like this?

They aren't equivalent.

Responsive layout isn't only about breakpoints

Media queries and container queries are powerful mechanisms for adapting presentation to available space.

The question here is different.

How should an application reason about the quality of the layout that currently exists?

Imagine several components sharing a constrained workspace.

Each component may have:

• hard minimum dimensions;
• useful minimum dimensions;
• preferred dimensions;
• user placement intent;
• available container space.

Changing one component can affect what remains feasible for several others.

Resizing the container can do the same.

At that point, responsive behaviour isn't only about selecting another CSS presentation.

It also becomes a constraint problem.

Dragging introduces intent

Now allow the user to drag those components.

A drag operation is no longer just:

pointer moved
→ update x/y

An accepted drop tells the layout system something important:

the user intended this element to be here.

That information should not disappear simply because another component moves later.

But it shouldn't become an unconditional pin either.

Imagine that the user places a metric below a chart, moves the table somewhere else, and then makes the workspace substantially smaller.

What should survive?

The system now has to reason about several different kinds of information:

user intent
hard constraints
content-usefulness constraints
generated placement
previous layout state
available space

Treating all of these as equivalent coordinates loses information.

A more useful model is:

An accepted drag is strong intent, not a permanent pin.

The placement becomes durable Source Intent.

Subsequent reflows should preserve that intent when it remains feasible.

When the available geometry makes that impossible, however, hard constraints and the layout solver still have authority.

The problem therefore becomes:

Preserve user intent when feasible, while maintaining the strongest layout the current constraints allow.

Determinism matters

Once layout becomes a constraint problem, predictability becomes important.

Given identical Core inputs, the solver should produce the same result.

That property makes layout behaviour reproducible.

It makes failures easier to diagnose.

It allows transitions between states to be tested rather than visually guessed.

And it keeps layout validity explainable in terms of explicit constraints.

The layout may adapt.

The result should not be arbitrary.

This is the problem behind DnDGem

I've been exploring this model while building DnDGem, an open-source adaptive drag-and-drop and layout engine for JavaScript applications.

Its central idea is deliberately simple:

GEOMETRICALLY FITS ≠ CONTENT REMAINS USEFUL

DnDGem separates hard geometric constraints from content-usefulness constraints and uses a deterministic Core to evaluate and resolve layouts.

Framework adapters sit around that Core rather than defining the layout domain itself.

The distinction becomes particularly visible when the available space changes.

A layout can transition through:

VALID
    ↓
DEGRADED
    ↓
INVALID

or recover in the opposite direction as space becomes available again.

That means a layout doesn't have to pretend everything is fine until the moment something physically stops fitting.

There is an intermediate state where the geometry is still feasible but the content has already crossed a meaningful usability threshold.

Try the distinction

I've built the DnDGem playground so this can be observed rather than just described.

The basic experiment is:

Resize → Observe → Drag

Resize the workspace and watch the solver state.

You can move between VALID and DEGRADED while the components still geometrically fit.

Then drag components and resize again to see how accepted placement intent interacts with subsequent reflow.

Playground: https://playground.dndgem.dev/

Source: https://github.com/davideagosti-dev/dndgem

The broader question

DnDGem is one implementation, but the architectural question is broader than the library:

How should frontend systems represent the point where a component still fits, but no longer has enough space to remain useful?

Do you encode that boundary inside individual components?

Do you handle it entirely through responsive CSS?

Do you model usefulness as part of the layout system?

Or does your application mostly discover that boundary through visual testing?

I'm interested in how other frontend engineers approach it.