Found by walking the #593 UI in a browser against a real server.
What it looks like
A class named pedestrian crossing marker accepting four shapes renders in the annotator's
Classes panel as:
pe… box · tag · polygon · polyline 5
The name is the identity of the row. The shape list is metadata about it. The flex layout gives
all of its slack to the metadata and truncates the identity to two characters.
Measured
class-row-<name>-name reports a laid-out width of 34.1px against a scrollWidth of 176px,
so about 19% of the name is rendered. It does not improve with viewport width — measured
identically at 1440px and 1280px, because the panel is a fixed-width column (w-72, 2xl:w-80)
and the shape list is sized by its content.
Two shapes is already tight; three or four is unusable. The same string renders in full in the
Annotations panel's tag chip immediately below, which is what makes the row look broken rather
than constrained.
Why it is not just cosmetic
Picking the right class is the annotator's most frequent decision, and the row is where it is
made. A hover title is not a substitute for a list you scan. The digit hotkey (5 here) is stable
and does help, but only once somebody already knows which class is which.
Directions, not a prescription
- Give the name the slack and truncate the shape list instead — it degrades gracefully,
because box · polygon · … still communicates how many shapes, and the armed row already
expands into a full picker.
- Or drop the shape list from the unarmed row entirely and keep it only on the armed one, where
it is already rendered as chips and is actually actionable.
- Or wrap to a second line for classes with three or more shapes.
The armed row is a separate case and currently works well: it drops tag (not drawable) and shows
the drawable shapes as chips.
Not in scope here
DESIGN.md states a ceiling on class-name length. That ceiling is a reasonable thing to have, and
this is not a request to remove it — the row should degrade in the other order.
Found by walking the #593 UI in a browser against a real server.
What it looks like
A class named
pedestrian crossing markeraccepting four shapes renders in the annotator'sClasses panel as:
The name is the identity of the row. The shape list is metadata about it. The flex layout gives
all of its slack to the metadata and truncates the identity to two characters.
Measured
class-row-<name>-namereports a laid-out width of 34.1px against ascrollWidthof 176px,so about 19% of the name is rendered. It does not improve with viewport width — measured
identically at 1440px and 1280px, because the panel is a fixed-width column (
w-72,2xl:w-80)and the shape list is sized by its content.
Two shapes is already tight; three or four is unusable. The same string renders in full in the
Annotations panel's tag chip immediately below, which is what makes the row look broken rather
than constrained.
Why it is not just cosmetic
Picking the right class is the annotator's most frequent decision, and the row is where it is
made. A hover title is not a substitute for a list you scan. The digit hotkey (
5here) is stableand does help, but only once somebody already knows which class is which.
Directions, not a prescription
because
box · polygon · …still communicates how many shapes, and the armed row alreadyexpands into a full picker.
it is already rendered as chips and is actually actionable.
The armed row is a separate case and currently works well: it drops
tag(not drawable) and showsthe drawable shapes as chips.
Not in scope here
DESIGN.mdstates a ceiling on class-name length. That ceiling is a reasonable thing to have, andthis is not a request to remove it — the row should degrade in the other order.