text-overflow: ellipsis: implement in Blitz paint, or in Parley?

[LinuxBoy-96]

text-overflow: ellipsis (and the string form) is parsed by Stylo but has no
effect in Blitz today: overflowing lines in a clipping inline root are simply
clipped.

I have a working implementation and would like to know where you want it
before opening a PR, because there are two reasonable homes for it.

Option A — paint-time truncation in Blitz (what I have)

• blitz-dom records the marker on the inline root's TextLayout when style
  asks for one (overflow other than visible + text-overflow): None for
  clip, "…" for ellipsis, the given string otherwise. One value applies
  to the inline-end side; two values name start then end.
• blitz-paint::text::stroke_text gets an optional TextOverflowClip
  (content-box width + marker). For each line wider than the content box,
  glyphs ending past max_width - marker_advance are dropped and the marker is
  drawn once after the kept glyphs, with the first run's font/size/colour
  (looked up through skrifa charmap + metrics; fonts without U+2026 fall
  back to ...).
• Layout, selection and hit testing keep the full text, as the spec describes
  (the ellipsis is a rendering effect).

Pros: self-contained in Blitz, no Parley API change, ~150 lines.
Cons: decorations (underline) are still drawn full-width; the marker is
shaped outside Parley; only the inline-end side is handled (no RTL/start
marker); other Parley users don't benefit.

Option B — truncation as a Parley layout feature

Parley would expose something like Layout::truncate_lines(max_width, marker) (or a LineBreaker option) that rewrites the overflowing line's runs
and shapes the marker in the right font, so decorations, selection geometry
and bidi come out right by construction. Blitz would only pass the option.

Pros: correct for all consumers, RTL and decorations handled once.
Cons: a Parley change first, larger scope.

Question

Would you take Option A now as an interim (with the limitations listed and
tracked), or would you rather see this land in Parley first? If the latter,
I'm happy to open the Parley issue/PR with the same design and keep the
Blitz side to the TextLayout::text_overflow plumbing.

WPT dirs to measure either way: css/css-overflow/text-overflow-*,
css/css-ui/text-overflow-*.

[yinnho]

Data point from an independent implementation: this week I landed text-overflow: ellipsis + white-space: nowrap in diting (the renderer in aginxbrowser, blitz/obscura lineage) — e1fc588. It took the Option A route (paint/raster-time truncation), and the experience mostly confirms the trade-offs listed above:

• Paint-time truncation is the right home. Per CSS UI §5.2 the ellipsis is a rendering effect: layout rects, getBoundingClientRect, scrollWidth, caret and selection all keep the full text. That falls out naturally when truncation happens at raster time — our tests assert scrollWidth still reflects the untruncated content width while paint ink clips at the limit.
• The nowrap interplay matters more than the marker itself. Without white-space: nowrap, ellipsis almost never triggers in practice (wrapped text doesn't overflow its inline root). Riding wrap_at = infinity through the text pipeline and gating truncation on the classic trio (overflow non-visible + nowrap + ellipsis) matched Chrome on our probes.
• Glyph-boundary fallback for unbreakable words: when a single unbreakable word doesn't fit whole, Chrome still fills the remaining space char by char before the marker. Worth copying — naive "drop the whole word" leaves visibly ragged gaps.
• Marker details: draw the ellipsis in the first kept run's own font params, and keep it undecorated — underline/strikethrough stop before the marker, matching Chrome. On the Option A "cons" list: decoration truncation was cheap since our decoration pass already iterates the kept token list, so underline doesn't run full-width under the marker.

Total cost was ~200 lines including white-space: nowrap parsing/inheritance, so the ~150-line estimate for ellipsis-only in paint looks right.

[LinuxBoy-96]

@yinnho Thanks for the feedback :)

Plz take a look to my PR (Sticky)

I'm stupid and now I need blitz to mature a little bit faster because I use it in production. :(

[nicoburns]

@LinuxBoy-96 What are you using Blitz in production for? (if you don't mind sharing - it's just cool to hear about my work actually being used)

[LinuxBoy-96]

@nicoburns It's a simple and minimalist mail manager in quite secure environments.