Implement rendering support for CSS text-decoration-trim
Categories
(Core :: Layout: Text and Fonts, enhancement)
Tracking
()
People
(Reporter: jfkthame, Assigned: alaskanemily)
References
(Blocks 3 open bugs)
Details
(Keywords: dev-doc-needed, Whiteboard: [jp-mvp], [wptsync upstream])
Attachments
(2 files, 3 obsolete files)
We need to take the text-decoration-trim inset/outset amounts into account when computing decoration line rects.
There might be some trickiness regarding what are the actual ends of the decoration line, as opposed to element/frame boundaries that fall within the scope of a continuous line (and so trimming doesn't apply).
|
||
Updated•2 months ago
|
|
||
Comment 1•2 months ago
|
||
This needs to be documented once implemented. (And it's also worth a release note then.)
Sebastian
|
Assignee | |
Updated•2 months ago
|
|
|
||
Updated•2 months ago
|
|
|
Assignee | |
Comment 2•2 months ago
|
||
|
|
Assignee | |
Comment 3•2 months ago
|
||
|
Reporter | |
Comment 4•1 month ago
|
||
I've been thinking a bit more about what this needs to do. With regard to nested inlines within the scope of a decoration, it's not sufficient to detect that the frame currently being painted isn't the one where the decoration was defined, or that it's "internal" to the decoration range, and therefore omit any trimming. The decoration line for a sub-element might still need to be partially trimmed, but not necessarily by the full amount specified by the property; it depends how close it is to the edge of the complete range where the decoration applies.
Consider something like <u>foo <b>the quick brown fox</b> bar</u>, with a positive text-decoration-trim applied to the <u> element. When we're rendering the textframe for <b>, we don't want to blindly apply the trim amount, because that will break the underline. But suppose the trim amount is larger than the width of "foo "; in that case we do need to apply some trimming at the beginning of the <b> subelement, but only the remaining amount of trim, after accounting for the width that "foo " has absorbed.
One way I think we can handle this is when setting up the parameters in nsTextFrame::DrawTextRunAndDecorations. Rather than passing the StyleTextDecorationTrim value in the parameters (for nsCSSRendering code to resolve), we can compare the rect of the current frame with that of the frame where the decoration was defined (using nsIFrame::GetOffsetTo), and determine if there is any "remaining" trim inset that needs to be applied to this part of the line. So the parameters will have trimStart and trimEnd values that reflect the amount of trim to apply to this segment, not the original values from the style.
(If the trim values are negative -- i.e. extending the line -- then they should just be set to zero for "internal" segments that are not at the edges of the original decorating rect. It's positive values -- trimming the line -- that need to be more carefully tracked in case internal segments have some residual trim to apply.)
|
|
Reporter | |
Comment 5•1 month ago
|
||
Another observation relates to the failure to render "extended" decoration lines (when the trim value is negative). I tried hacking nsTextFrame::UnionAdditionalOverflow to extend the ink-overflow rect in the inline direction when negative trim is present, but this does not result in the extended part of the line getting rendered.
It may still be necessary to update the ink-overflow area in this way for reliable rendering, but it appears it is not sufficient; it looks like there must also be code elsewhere in the rendering path that is still constraining or clipping the decoration line to the width of the text frame.
|
|
Reporter | |
Comment 6•29 days ago
|
||
Ah, see https://searchfox.org/firefox-main/rev/d0ff31da7cb418d2d86b0d83fecd7114395e5d46/layout/generic/nsTextFrame.cpp#7445-7452. We'll need to disable clipping here for edges of decoration lines that are supposed to have negative trim applied (or at least, extend the clip area by the trim amount in that direction).
|
|
Assignee | |
Comment 7•28 days ago
|
||
|
|
Assignee | |
Comment 8•27 days ago
|
||
(In reply to Jonathan Kew [:jfkthame] from comment #6)
Ah, see https://searchfox.org/firefox-main/rev/d0ff31da7cb418d2d86b0d83fecd7114395e5d46/layout/generic/nsTextFrame.cpp#7445-7452. We'll need to disable clipping here for edges of decoration lines that are supposed to have negative trim applied (or at least, extend the clip area by the trim amount in that direction).
As a first pass, I think just disabling it for a negative trim seems simple enough. We'll definitely want to properly extend the clipping area as a followup though.
|
|
||
Updated•27 days ago
|
|
||
Comment 9•27 days ago
|
||
Comment on attachment 9513347 [details]
Bug 1979915 WIP - Use text-decoration-trim for text decoration rect calculation and decoration painting
Revision D264878 was moved to bug 1988793. Setting attachment 9513347 [details] to obsolete.
|
|
Assignee | |
Comment 10•21 days ago
|
||
|
|
||
Updated•10 days ago
|
|
|
||
Updated•10 days ago
|
|
|
||
Updated•7 days ago
|
|
|
||
Updated•7 days ago
|
|
|
Assignee | |
Comment 11•7 days ago
|
||
|
||
Comment 12•6 days ago
|
||
|
|
||
Comment 13•6 days ago
|
||
|
||
Comment 14•6 days ago
|
||
Backed out for causing wr failures
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | /css/css-text-decor/text-decoration-trim-007.html | Testing http://web-platform.test:8000/css/css-text-decor/text-decoration-trim-007.html == http://web-platform.test:8000/css/css-text-decor/reference/text-decoration-trim-007-ref.html
|
|
||
Comment 15•6 days ago
|
||
|
|
Assignee | |
Comment 16•6 days ago
|
||
This failure is caused by some fonts only sometimes having skip-ink (even given the text decoration offset), and the reference case using an invisible copy of the text to shift the decoration. The skip-ink intercepts end up shifted too, which misaligns them.
I've disabled skip-ink for those tests, we already have multiple WPT that test trim values (positive and negative) with skip-ink.
|
|
||
Comment 17•6 days ago
|
||
|
|
||
Comment 18•6 days ago
|
||
[Why is this notable]: New CSS property allowing authors to manipulate the length of text decorations.
[Affects Firefox for Android]: yes
[Suggested wording]: Starting with Firefox x, the text-decoration-trim property is supported, which allows authors to adjust the start and end points of line decorations.
[Links (documentation, blog post, etc)]:
https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-inset-property
https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-trim (doesn't exist yet)
|
|
Assignee | |
Comment 19•6 days ago
|
||
See intent to ship notice: https://groups.google.com/a/mozilla.org/g/dev-platform/c/YrBMtBkbZYo
This won't be enabled until 146.
|
|
||
Comment 20•6 days ago
|
||
I know, the request in comment 18 is for the Nightly release notes.
Sebastian
|
||
Comment 21•5 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/c39ae4580d11
https://hg.mozilla.org/mozilla-central/rev/5013885993a2
Description
•