# How the card reflows at different widths

The card does not get to choose how wide it is. A dragged sidebar can be a fraction of the width of the activity tab, and both are showing the same customer. So the card measures its own box rather than the browser window, and re-measures as that box changes.

Layout is the only thing width changes. The type size, the number of values a row shows and how much of a value is printed are identical in all three bands.

## Three bands

| **Width of the card itself** | **Layout**                                                                                                                                 |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Under about 380 pixels       | Each field's label sits above its value.                                                                                                   |
| About 380 pixels and wider   | The label moves beside the value, in a label column with a ceiling on it, so every extra pixel goes to the value rather than to the label. |
| About 700 pixels and wider   | The stacked fields flow into two columns.                                                                                                  |

![What decides the layout](https://help.gocapable.com/images/att1438711862.svg)

## No placement can force a layout

None of the three placements pins the card to a particular shape. The activity tab is not permanently wide and the sidebar is not permanently narrow: both reflow on the width they are actually given, which is what a reader dragging the sidebar wider sees happen under their hands.

The same is true of the preview an administrator sees while configuring the card. That preview is the real card and it measures its own frame, so resizing it shows the layout changes the real panel will make.

## Two columns flow, they do not align

In the widest band the fields flow down the first column and then continue down the second, rather than being laid out left to right in a grid. That keeps a field which wraps to six lines from leaving a block of empty space beside it. It also means the field alongside a given row has nothing to do with it.

## Height and scrolling

The card never sets its own height and nothing inside it scrolls vertically. It grows as tall as its content needs and the surrounding Jira surface handles the rest. Nor does a wide row produce a horizontal scrollbar inside the card: long, unbreakable strings such as web addresses and identifiers are broken across lines rather than being allowed to widen the card or be cut off.

## The one thing that does follow width

The threshold at which a single long value is folded to four lines is worked out from how wide the card actually is, and is never below 80 characters. So the same description can fold in a narrow sidebar and not fold in a wide activity tab. Everything else, including the eight-value cap on a long list and the 16-character rule that decides lozenges from lines, is one number at every width.

---

## A few things worth knowing

* A reader who drags the issue sidebar past about 380 pixels changes the card's layout mid-ticket. Nothing is broken and nothing has been hidden; the labels have moved beside their values.
* Two columns are not a table. A field sitting beside another field is not related to it, because the rows flow down the first column before continuing down the second.
* The narrowest band is what the card assumes for the first frame if it has not managed to measure itself yet. A stacked row briefly drawn wide looks sparse; a two-column row drawn narrow would overflow the panel, which is why the guess goes the way it does.

---

## Related

[What the card shows](https://help.gocapable.com/attio-for-jira/what-the-card-shows.html)

[Linked records on the card](https://help.gocapable.com/attio-for-jira/linked-records-on-the-card.html)

---

_The card measures; nobody gets to tell it._