Part 2

Size and resize behaviour

Panes try to work at any width, and mostly do. But “works” has edges, and they are worth knowing before you commit to a layout. Everything on this page was measured by resizing a real pane, not estimated.

How a pane responds

A pane watches its own container, not the browser window. It re-measures whenever that container changes size, whatever caused the change — a window resize, a sidebar opening, a drag handle, a CSS grid reflowing, a dialog being shown. You do not need to tell it anything.

What it does with the space, for a service inventory pane:

Columns collapse from the right as space runs out. Each collapsed column moves into the row's expandable drawer, so no information is lost — it moves one click away.
The first column never collapses. It is the one that identifies the row, so it keeps its place at every width. This is why the order you put in data-lp-attributes matters: lead with what identifies the resource.
Six columns is the cap, regardless of how wide the pane is or how many attributes you name. A pane can lower that for itself; none raise it.

What the widths do

A six-attribute EC2 inventory pane, in a container stepped through fourteen widths:

Container	Columns	What you see
200 px	1	Content spills outside the pane and it scrolls sideways. Broken.
240 px	1	Clean, but the name column alone. Everything else is in the drawer.
280 px	2	Name plus one. The narrowest width every kind of pane handles.
360 px	3	Enough to read a row without expanding it. A sensible floor.
480 px	4	Comfortable. A good width for a dashboard tile.
560 px	5
720 px	6	Every column the pane will show. Nothing is in the drawer but detail.
900 px +	6	No further change. The pane stretches; the information does not grow.

Exact widths shift with the pane — long resource names and more attributes both push the steps later — but the shape is the same for every inventory pane: one column at the floor, all six by around 700 px, and no change above that.

Width	Meaning
280 px — hard floor	Below this, compound panes push content outside their own box. Treat it as a `min-width`, not a target.
360 px — comfortable minimum	Three columns on an inventory pane and every compound pane settled. This is the right number for the `minmax()` in a responsive grid.
480–720 px — the sweet spot	Four to six columns. Where a dashboard tile wants to be, and roughly what a pane opens at in a windowed desktop.
~1400 px — practical maximum	Nothing breaks beyond it, but nothing improves either, and some panes get taller as they widen. Full-bleed panes on a wide monitor are mostly whitespace.

The ceiling is about reading, not breaking

A pane at 1920 px is perfectly stable — it just shows exactly what it showed at 720 px, with the cells spread much further apart, so the eye has further to travel to pair a resource with its state. On a wide screen, two panes side by side at 700 px each beat one pane at 1400 px.

Compound panes differ at the bottom end

Service inventory panes stay clean down to 240 px. Compound panes — cost summaries, posture boards, anything with charts and summary tiles — spill at 240 px and are clean from 280 px up.

If your layout mixes both kinds, which it probably does, design to 280 px as the absolute floor and 360 px as the working one. A grid cell that can reach 240 px will look fine in testing right up until someone drops a cost pane into it.

Height

By default a pane is as tall as its content. You set the width; it decides the height. For most pages that is what you want.

Two things follow from it that surprise people:

A narrower pane is a taller pane. Same rows, less width, more wrapping. One posture pane measured 2,025 px tall at 360 px wide and 1,566 px at 720 px — the same content, 460 px shorter.
A very wide pane can also be taller. Panes with charts scale them with the width. One cost pane bottomed out around 515 px tall at 480 px wide and grew to 815 px at 1920 px. Wider is not reliably shorter.

When you need a pane to fit a space you control — a fixed dashboard cell, a window, a column that must not grow — use data-lp-fill. The pane becomes a fixed header, a single scrolling body and a fixed footer, sized to whatever height the container gives it.

<div style="height:420px">
  <div data-lp-service="ec2"
       data-lp-account="YOUR_ACCOUNT_HANDLE"
       data-lp-fill="true"></div>
</div>

<!-- or "paged": one page at a time, pager pinned to the footer -->
<div style="height:420px">
  <div data-lp-service="ec2"
       data-lp-account="YOUR_ACCOUNT_HANDLE"
       data-lp-fill="paged"
       data-lp-page-size="25"></div>
</div>

data-lp-fill needs the container to have a real height. In a plain block container with no height set, there is nothing to fill and the pane falls back to its content height.

Hidden panes, moved panes

Panes survive being hidden and moved, which is what makes tabs, drawers and overlays straightforward.

A pane inside a display:none parent renders. It measures zero width and keeps all its columns rather than collapsing to one.
Showing the parent is enough. The pane re-measures and lays out for the real width with no API call and no re-render on your part.
Moving a pane in the DOM works — including moving it into a <dialog> and opening it. It picks up the new container's width, and keeps tracking it if the dialog is then resized.

So a tabbed dashboard can put every pane in the DOM up front, and a lightbox can move a pane into an overlay and back. Part 4 builds both.

Three things not to do

Do not set a fixed height and hope

A pane without data-lp-fill is as tall as its content, and its content depends on how many resources you have. A height: 300px on the container clips it. Either let it size itself, or use fill mode and let it scroll.

Do not put a pane in a container narrower than 280 px

The usual way this happens is not a narrow column but a wide one with padding on a phone: a 320 px viewport with 24 px of padding each side leaves 272 px. Check the inner width, not the viewport.

Do not style the inside of a pane

The markup inside a pane belongs to the runtime and changes between releases. A rule reaching into pane internals will break without warning and in a way that looks like a LightPane bug. Style the container — size, position, margin, border, background — and leave the rest alone.