Closed Bug 1941090 Opened 1 month ago Closed 1 month ago

[wpt-sync] Sync PR 50036 - [line-clamp] Place the line-clamp ellipsis during line breaking

Categories

(Core :: Layout: Scrolling and Overflow, task, P4)

Product:
Core
Component:
Layout: Scrolling and Overflow
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
136 Branch
Tracking Flags:
Tracking Status
firefox136 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 50036 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/50036
Details from upstream follow.

Andreu Botella <abotella@igalia.com> wrote:

[line-clamp] Place the line-clamp ellipsis during line breaking

The current behavior of both text-overflow: ellipsis and
(-webkit-)line-clamp with respect to positioning the ellipsis is
that after the inline items are positioned, glyphs and other inline
items will be truncated from the visual end of the line until there is
enough space for the ellipsis to fit in the line box, and then the
ellipsis is placed at that position.

For (-webkit-)line-clamp, this disagrees with the upcoming
specification, which says that rather than truncating glyphs one by
one, instead all inline content should be truncated until the last
break opportunity where the ellipsis would fit. Furthermore, inline
content should be truncated logically, rather than visually.
And there is an open discussion in
https://github.com/w3c/csswg-drafts/issues/10844 about where the
ellipsis should be positioned in bidi content, which might not be at
the visual end of the line.

This means that the ellipsis should be taken into account at the line
breaking phase. We tried laying out the ellipsis as part of
LineBreaker and somehow including it in the InlineItemResults it
produces, but we found it was not always feasible. Instead, we shape
the ellipsis in the InlineLayoutAlgorithm, pass its width to
LineBreaker, and then in LogicalLineBuilder we add a
LogicalLineItem for the ellipsis just before bidi reordering.

This also fixes a long-standing bug where lines with the line-clamp
ellipsis were not properly aligned or justified (bug 40265829). This
happened because the line content was only trimmed, and the ellipsis
was only shaped, after every LogicalLineItem was positioned
according to the alignment and justification. With this patch, since
the trimming and ellipsis shaping happens during line breaking, and
the ellipsis LogicalLineItem is created at the same time as other
LogicalLineItems, the ellipsis behaves the same as any other inline
content for alignment and justification.

Some WPT and internal tests break with this change. Some of them are
tests that were written expecting the previous behavior, and probably
need to be updated. But others show that this implementation is
incomplete. Therefore, we are putting this behind the runtime feature
CSSLineClampLineBreakingEllipsis.

Bug: 40336192, 40265829
Change-Id: I2d5a645899734b8dea5b0929906b7835b45bd50e
Reviewed-on: https://chromium-review.googlesource.com/6106171
WPT-Export-Revision: b45f095508bbfd9fd6da5f68180d5b157ad0c991

Component: web-platform-tests → Layout: Scrolling and Overflow
Product: Testing → Core

CI Results

Ran 9 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 12 tests

Status Summary

Firefox

FAIL: 12

Chrome

PASS: 5
FAIL: 7

Safari

PASS: 4
FAIL: 8

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

Firefox-only Failures

New Tests That Don't Pass

Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0cc4421f8f90 [wpt PR 50036] - [line-clamp] Place the line-clamp ellipsis during line breaking, a=testonly https://hg.mozilla.org/integration/autoland/rev/3b4d05d5cc09 [wpt PR 50036] - Update wpt metadata, a=testonly

https://hg.mozilla.org/mozilla-central/rev/0cc4421f8f90
https://hg.mozilla.org/mozilla-central/rev/3b4d05d5cc09

Status: NEW → RESOLVED
Closed: 1 month ago
status-firefox136: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch
You need to log in before you can comment on or make changes to this bug.