Overflow behavior must be specified separately by content type

What it is

What happens when a slot cannot hold its content cannot be one global “ellipsis on overflow.” Content-typed overflow is a per-type loss policy in the package: personal names, money, identifiers, times, addresses, and image crops each declare what may be dropped and what must be kept. Handing every overflow to the same ellipsis is handing the loss function to whoever implements the screen.

This does not replace drawing the long and short ends. Those frames show whether space was considered. Type policy shows which part is allowed to die when space runs out. When both are missing, a button’s trailing ellipsis gets copied onto a price.

Why it happens

Overflow is directed information loss. Dropping a family name is not the same as dropping a given name, and some writing systems refuse a break inside a word. Ellipsizing the middle of a money amount forges the number; money should wrap, resize, or move to a full read-only layer, not become 1,23.... Identifiers (order ids, hashes) often lose less in the middle than at the ends, so middle ellipsis or a monospace scroll preserves more than a tail clip. A URL is recognized by its host; a timestamp, when zones collide, by its offset. Image overflow is a crop, not a character strategy.

Type also decides whether the loss is reversible. Text ellipsis without a “show all” path is permanent. Money that cannot be opened as a full figure is a bad decision in one tap. If the package does not write policy per type, engineering sees one text-overflow and every slot inherits the same CSS. Harmless on a title; an incident on a price.

Where it stops holding

A decorative hero crop is art direction, not data overflow; field policy should not govern it. When a whole table scrolls sideways, loss happens at the viewport, not inside the cell: write freeze-columns and a scroll cue at table level instead of ellipsizing every cell. When a type is already a truncation by convention (a checksum shown as first and last four characters), that is the type’s normal writing, not a rescue — mark it “intentionally partial” so implementation does not stack a second ellipsis. A policy measured in one language and one font fails under a different average glyph width; bind it to rendered width, not character count.

Applying it

• Label every data slot in the package with a content type, and lock that type’s overflow action: wrap, tail ellipsis, middle ellipsis, resize type, cap line count, scroll horizontally, or open a full-text view. Only an explicit subset is legal.
• Forbid tail ellipsis on high-consequence types such as money, stock, and permission names. If space is insufficient, wrap or jump to a complete read-only view.
• Give identifiers a monospace treatment and middle ellipsis (or a copyable full value on press). Do not reuse a title’s trailing ellipsis.
• For each type, inject a record that must overflow. In the built UI, a price must not show an ellipsis, and an order id must not clip only the tail and leave an ambiguous prefix. If one type inherited another type’s action, write that slot’s policy into the package.

Related

• Same group: R2.05.1 Handoff must show both extreme-long and extreme-short content · R2.05.2 Zero, one, and many each need their own defined layout · R2.05.3 Whatever is left unspecified will be invented by the implementer · R2.05.4 Bound values come from real distributions, not imagined extremes · R2.05.6 Stacked edge cases need their own frames
• Adjacent: S1.01 Text Expansion and Layout Resilience · R2.01 Annotation and asset export
• Search terms: content-typed overflow · overflow policy · semantic truncation