Summary
In the record-highlights strip (record:highlights), a Field.percent() column renders a fixed-width progress bar plus the numeric text, but the chip that contains them is narrow and clips with truncate. The bar wins the space and the number — the thing the chip exists to show — is cut off.
Measured on a fresh database (@objectstack/console 17.0.0-rc.1, Chromium 1194, viewport 1440×900, locale zh-CN):
| |
|---|
| stored value | 33.33 |
| DOM text | 33% |
| on screen | 3 |
| clipping box width | 79px |
| text node width | 32px |
| text overflow past the clipping box | 25px |
The chip's label reads 「供应量占比(%)」 and the chip shows a bar followed by a lone 3.
Reproduced with a Playwright getBoundingClientRect() probe and a screenshot, because reading the DOM alone gives the wrong answer — the DOM carries the correct 33%; the loss is purely visual:
{ label: "供应量占比(%)", domText: "33%", hasBar: true,
cellW: 144, valueW: 79, textW: 32, textOverflowRight: 25 }
Why this matters
This is a silently wrong number, not a cosmetic glitch. A supply share of 33% presented on screen as 3 is a value someone reads out loud in front of a customer. There is no error, no ellipsis in the accessible name, nothing that signals truncation — the chip just shows a smaller, plausible number.
Mechanism
Two platform pieces combine:
The percent display renderer (ui-components, the percent / progress entry of the field-display map) always emits:
<divclassName="flex items-center gap-2"><divclassName="h-1.5 w-16 rounded-full bg-muted … shrink-0"role="progressbar"…><divclassName="h-full rounded-full bg-primary"style={{width: `${clamped}%`}}/></div><spanclassName="tabular-nums whitespace-nowrap">{formatted}</span></div>The bar is w-16 (64px) and shrink-0; the value span is not.
The record-highlights chip (plugin-detail, the highlights panel) wraps whatever the renderer returns in a clipping box:
<divclassName="group flex flex-col gap-1 min-w-[7rem] px-5 … basis-[9rem] max-w-[16rem]">
…
<spanclassName="block min-w-0 truncate text-sm font-semibold …">{renderer}</span></div>basis-[9rem] (144px) minus px-5 (40px) ≈ 104px of content, and the chips shrink toward min-w-[7rem] (112px → ~72px of content) as more chips are added. Bar (64) + gap-2 (8) = 72px, so the value gets between ~0 and ~32px, and truncate silently removes the remainder.
Nothing about this is specific to our app's metadata: any percent field in any highlights strip hits it, and the more highlight chips a record has, the worse it gets.
Reproduce
- Author an object with a
Field.percent() column holding a two-digit value with decimals (e.g. 33.33). - Put it in a
record:highlights slot alongside 5+ other fields. - Open the record in the console at 1440px and screenshot the strip.
Expected: 33% (or 33.33%) legible.
Actual: a 64px bar and a clipped 3.
Suggested fixes (any one closes it)
- Give the value span priority:
shrink-0 on the text and let the bar shrink (min-w-0 flex-1 on the bar wrapper) — the bar is decorative, the number is the content. - Drop the bar below a container-width threshold (
@container is already on the highlights <section>, so a container query is available). - Let the highlights chip opt out of
truncate for renderers that are not single-line text, or measure before clipping.
Application-side workaround we were forced into
We override the field's render type in the page's highlights slot so the platform picks the plain number renderer instead of the percent one:
properties: {fields: […,{name: 'supply_share',type: 'number'},…]}This works because record:highlights normalizes each entry to {name, label, icon, type} and the chip resolves type ?? schemaField.type. The cost is that we lose the % glyph and the bar entirely, and we have to carry the unit in the field label instead. Downstream tracking: yinlianghui/hotcrm-heimao#59.
Summary
In the record-highlights strip (
record:highlights), aField.percent()column renders a fixed-width progress bar plus the numeric text, but the chip that contains them is narrow and clips withtruncate. The bar wins the space and the number — the thing the chip exists to show — is cut off.Measured on a fresh database (
@objectstack/console17.0.0-rc.1, Chromium 1194, viewport 1440×900, localezh-CN):33.3333%3The chip's label reads 「供应量占比(%)」 and the chip shows a bar followed by a lone
3.Reproduced with a Playwright
getBoundingClientRect()probe and a screenshot, because reading the DOM alone gives the wrong answer — the DOM carries the correct33%; the loss is purely visual:Why this matters
This is a silently wrong number, not a cosmetic glitch. A supply share of 33% presented on screen as
3is a value someone reads out loud in front of a customer. There is no error, no ellipsis in the accessible name, nothing that signals truncation — the chip just shows a smaller, plausible number.Mechanism
Two platform pieces combine:
The percent display renderer (
ui-components, thepercent/progressentry of the field-display map) always emits:The bar is
w-16(64px) andshrink-0; the value span is not.The record-highlights chip (
plugin-detail, the highlights panel) wraps whatever the renderer returns in a clipping box:basis-[9rem](144px) minuspx-5(40px) ≈ 104px of content, and the chips shrink towardmin-w-[7rem](112px → ~72px of content) as more chips are added. Bar (64) +gap-2(8) = 72px, so the value gets between ~0 and ~32px, andtruncatesilently removes the remainder.Nothing about this is specific to our app's metadata: any
percentfield in any highlights strip hits it, and the more highlight chips a record has, the worse it gets.Reproduce
Field.percent()column holding a two-digit value with decimals (e.g.33.33).record:highlightsslot alongside 5+ other fields.Expected:
33%(or33.33%) legible.Actual: a 64px bar and a clipped
3.Suggested fixes (any one closes it)
shrink-0on the text and let the bar shrink (min-w-0 flex-1on the bar wrapper) — the bar is decorative, the number is the content.@containeris already on the highlights<section>, so a container query is available).truncatefor renderers that are not single-line text, or measure before clipping.Application-side workaround we were forced into
We override the field's render type in the page's highlights slot so the platform picks the plain number renderer instead of the percent one:
This works because
record:highlightsnormalizes each entry to{name, label, icon, type}and the chip resolvestype ?? schemaField.type. The cost is that we lose the%glyph and the bar entirely, and we have to carry the unit in the field label instead. Downstream tracking: yinlianghui/hotcrm-heimao#59.