F2.08.2card chrome spatial taxdesign

Card strokes and shadows spend a lot of space

Aliases: card chrome · elevation tax · nested padding

What it is

Every card pays: the seam to the next card, the stroke or the shadow’s spread, and an inner padding so type does not kiss the frame. On a phone, eight cards can spend a quarter of the viewport on pixels that are not content. A news app that wraps each headline in 16 px padding plus a drop shadow turns six first-screen items into three. The tax is the headlines you no longer see.

This leaf only keeps the spatial books. It does not judge whether the objects should have been cards. When they should, the tax is still due; it may be worth paying.

Why it happens

A card is a nested coordinate system. Outer gap separates cards, stroke and shadow draw the object, inner padding keeps matter off the edge. All three are chrome; none carry fields. The narrower the viewport, the larger chrome’s share: 16 px padding is quiet on 1440 and already a line of type on 375. Shadows also demand extra keep-out, or the neighbour’s umbra sits in this card’s content.

Nesting multiplies the tax: a card in a card is two paddings and two seams. That is the “thick, few words” look.

Where it stops holding

Shadows that mean elevation — projection, a pick-up for drag — are semantic, not waste. Ten-foot TV and stage displays use frames so people can grab objects from far away; space is cheap. A box on a printed poster is composition.

Strokeless, shadowless, fill-only “cards” pay less, but fill still wants inner padding. The bill shrinks; it does not vanish.

Applying it

  • At the target width, paint outer seams, strokes, shadows and inner padding as blocks and measure their share of the viewport. On content-heavy surfaces, above about a quarter, start cutting: fill instead of shadow, one step down on padding, fold the outer seam into the between-group scale instead of adding a ring.
  • Ban card-in-card unless the inner object is truly pick-up-able.
  • How to check: screenshot a screen, mask all type and images, leave frames and empty. What remains is chrome. Count how many extra rows a list of the same height would show. If those extra rows would help the task (one more comparable title), cut chrome. If the screen was always about a handful of objects, keep the chrome and write down that you bought object-hood, not throughput.

Related

  • Same group: F2.08.1 Cards earn their keep on heterogeneous, independently usable units · F2.08.3 Homogeneous lists in cards are a net loss
  • Nearby: F3.06 Shadow and elevation · F2.07 Information density · F2.02 Columns, gutters and margins
  • Search terms: card padding · elevation shadow · chrome tax · viewport budget

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/F2.08.2