Skip to content

[text-box-trim] - #78741

Open
alanbaradlay wants to merge 2 commits into
WebKit:mainfrom
alanbaradlay:eng/text-box-trim-overline-position
Open

alanbaradlay wants to merge 2 commits into
WebKit:mainfrom
alanbaradlay:eng/text-box-trim-overline-position

Conversation

@alanbaradlay

@alanbaradlay alanbaradlay commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

6630190

[text-box-trim] Overline of a trimmed inline box is drawn at the trimmed edge
https://bugs.webkit.org/show_bug.cgi?id=329370
<rdar://problem/191255274>

Reviewed by NOBODY (OOPS!).

The decorating box of a trimmed inline box is moved to its trimmed edge (textBoxEdgeAdjustmentForUnderline), and
underlineOffsetForTextBoxPainting subtracts that adjustment again so that the underline stays where it would be
without text-box-trim. overlineOffsetForTextBoxPainting did not, so the overline moved down with the trim.

Subtract the adjustment for the overline too.

This progresses the horizontal cap and ex variants of text-box-trim-inline-box-text-decoration-001.html.

* LayoutTests/TestExpectations:
* Source/WebCore/style/InlineTextBoxStyle.cpp:
(WebCore::overlineOffsetForTextBoxPainting):

cd20818

[text-box-trim] Inline boxes in vertical-lr trim the line-over side for trim-start
https://bugs.webkit.org/show_bug.cgi?id=329340
<rdar://problem/191239706>

Reviewed by NOBODY (OOPS!).

text-box-trim trims the block-start and block-end sides of an inline box, but textBoxAdjustedInlineBoxHeight
always applied trim-start to the line-over side (ascent) and trim-end to the line-under side (descent). In
vertical-lr, where lines are inverted, the block-start side is the line-under side, so the wrong side got trimmed.

Map trim-start and trim-end through WritingMode::isLineInverted(), the same way line box trimming already does
in LayoutIntegrationLineLayout.

This progresses the vertical-lr variants of text-box-trim-inline-box-00{1,2,4,5}.html and the vertical-lr,alphabetic
variants of text-box-trim-inline-box-text-decoration-00{1,2}.html. Their vertical-lr,ideographic-ink variants now
trim the line-under side with the (unimplemented) ideographic-ink edge, which asserts in debug builds.

* LayoutTests/TestExpectations:
* Source/WebCore/layout/formattingContexts/inline/InlineLineBoxBuilder.cpp:
(WebCore::Layout::textBoxAdjustedInlineBoxHeight):

6630190

Misc iOS, visionOS, tvOS & watchOS macOS Linux Windows Apple Internal
✅ 🧪 style ✅ 🛠 ios ✅ 🛠 mac ✅ 🛠 wpe ✅ 🛠 win ✅ 🛠 ios-apple
✅ 🧪 bindings ✅ 🛠 ios-sim ✅ 🛠 mac-cmake-debug loading 🧪 wpe-wk2 ⏳ 🧪 win-tests ✅ 🛠 mac-apple
✅ 🧪 webkitperl ⏳ 🧪 ios-wk2 loading-orange 🧪 api-mac ✅ 🧪 api-wpe ✅ 🛠 vision-apple
⏳ 🧪 ios-wk2-wpt ⏳ 🧪 api-mac-cmake-debug ⏳ 🧪 jsc-wpe
⏳ 🧪 api-ios ⏳ 🧪 mac-wk2 ✅ 🛠 gtk3-gcc
✅ 🛠 ios-safer-cpp ⏳ 🧪 mac-cmake-debug-wk2 ✅ 🛠 gtk
✅ 🛠 vision ✅ 🧪 mac-wk2-stress ⏳ 🧪 gtk-wk2
loading 🛠 vision-sim ⏳ 🧪 mac-intel-wk2 ✅ 🧪 api-gtk
loading 🧪 vision-wk2 ✅ 🛠 mac-safer-cpp ⏳ 🛠 playstation
✅ 🛠 tv ✅ 🧪 mac-site-isolation
✅ 🛠 tv-sim
✅ 🛠 watch
✅ 🛠 watch-sim

…or trim-start

https://bugs.webkit.org/show_bug.cgi?id=329340
<rdar://problem/191239706>

Reviewed by NOBODY (OOPS!).

text-box-trim trims the block-start and block-end sides of an inline box, but textBoxAdjustedInlineBoxHeight
always applied trim-start to the line-over side (ascent) and trim-end to the line-under side (descent). In
vertical-lr, where lines are inverted, the block-start side is the line-under side, so the wrong side got trimmed.

Map trim-start and trim-end through WritingMode::isLineInverted(), the same way line box trimming already does
in LayoutIntegrationLineLayout.

This progresses the vertical-lr variants of text-box-trim-inline-box-00{1,2,4,5}.html and the vertical-lr,alphabetic
variants of text-box-trim-inline-box-text-decoration-00{1,2}.html. Their vertical-lr,ideographic-ink variants now
trim the line-under side with the (unimplemented) ideographic-ink edge, which asserts in debug builds.

* LayoutTests/TestExpectations:
* Source/WebCore/layout/formattingContexts/inline/InlineLineBoxBuilder.cpp:
(WebCore::Layout::textBoxAdjustedInlineBoxHeight):
…med edge

https://bugs.webkit.org/show_bug.cgi?id=329370
<rdar://problem/191255274>

Reviewed by NOBODY (OOPS!).

The decorating box of a trimmed inline box is moved to its trimmed edge (textBoxEdgeAdjustmentForUnderline), and
underlineOffsetForTextBoxPainting subtracts that adjustment again so that the underline stays where it would be
without text-box-trim. overlineOffsetForTextBoxPainting did not, so the overline moved down with the trim.

Subtract the adjustment for the overline too.

This progresses the horizontal cap and ex variants of text-box-trim-inline-box-text-decoration-001.html.

* LayoutTests/TestExpectations:
* Source/WebCore/style/InlineTextBoxStyle.cpp:
(WebCore::overlineOffsetForTextBoxPainting):
@alanbaradlay alanbaradlay self-assigned this Oct 29, 2026
@alanbaradlay alanbaradlay added the New Bugs Unclassified bugs are placed in this component until the correct component can be determined. label Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

New Bugs Unclassified bugs are placed in this component until the correct component can be determined.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants