2050141 - [text-box-trim] Set layout.css.text-box.enabled for all users

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, task)

Description

[Sajid Anwar [:sajidanwar]]

Launch text-box (and text-box-trim and text-box-edge) for all users.

Release Note Request
[Why is this notable]: New CSS feature, parity with Chrome and Safari
[Affects Firefox for Android]: Yes
[Suggested wording]: Firefox now supports the text-box-trim and text-box-edge CSS properties, and the associated text-box shorthand. These properties allow you to control the leading space above and below text, enabling simpler and consistent vertical spacing and alignment.
[Links (documentation, blog post, etc)]:

• https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-box-trim
• https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-box-edge

Comment 1

[Sajid Anwar [:sajidanwar]]

Attachment: Bug 2050141 - Set layout.css.text-box.enabled for all users. r=#layout-reviewers

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/517c4de13f8f
https://hg.mozilla.org/integration/autoland/rev/2ffeda8700f8
Set layout.css.text-box.enabled for all users. r=layout-reviewers,dshin

Comment 3

[Sajid Anwar [:sajidanwar]]

One thing to note for the dev-doc-needed flag, text-box-edge had its syntax changed to always allow a single value: https://drafts.csswg.org/css-inline-3/#typedef-text-edge. If a single value is provided, then it's used as both over and under if that keyword works for both (true for text, ideographic, and ideographic-ink); otherwise, text is used for the other value (for cap, ex, and alphabetic). Chrome is also incorrectly marked as not supporting alphabetic, cap, and ex, it looks like.

Here's the other list of Gecko / Blink / WebKit differences I'm aware of that I put in the Intent to Ship:

• Gecko supports the ideographic and ideographic-ink edges, which are not supported by Blink or WebKit.
• Gecko supports trimming of multi-column containers, which is supported by Blink but not by WebKit.
• Gecko supports trimming of inline boxes, which is supported by WebKit but not by Blink.
• Gecko does not support trimming of line-clamp-ed boxes (Bug 2043012), which is also not supported by WebKit but which is supported by Blink.

Comment 4

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/2ffeda8700f8

Comment 5

[Sebastian Zartner [:sebo]]

Sajid, I see Firefox differing from Chrome and Safari on https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-box-trim#interactive_text-box-trim_and_text-box-edge_value_comparison. The rendering of text-box: none text is different to text-box: trim-both text in Firefox, while in Chrome and Safari they are the same.

Reading the spec text, I think Chrome and Safari don't actually use the text-over / text-under baselines when text-box-trim is set to a non-none value but rather still include the leading. So Firefox seems to be correct here. Though I'm not totally sure here.
Could you explain the difference? And is there already a WPT testing this? Skimming through them, I can't seem to find one.

Sebastian

Comment 6

[Sajid Anwar [:sajidanwar]]

Thank you Sebastian for testing this and catching this case! This is an oversight from me, I was mostly relying on the WPTs and my default system font for the text case when comparing against other engines and didn't see this discrepancy.

I actually believe that my implementation is wrong and that the other browsers are correct. Firefox is trimming both the external leading from the line height and the internal leading in the font itself, whereas Chrome and Safari are trimming just the external leading. I believe what they're doing is actually the correct definition of the text-over / text-under baselines, which is to use the font-metric-based height of the content box (which in all browsers is the font's maximum ascent/descent, not the em-ascent/descent). The vertical-align: text-top/text-bottom values also use the same text-over and text-under baselines, so the test case I've attached confirms that my baseline choice for text is wrong — trimming the block to the text edges should match up to where the <canvas> elements are positioned. Chrome and Safari match, whereas Firefox trims too far.

This difference didn't manifest in the WPTs since the test fonts, including the common Ahem font, don't have any internal leading. I'm going to file a bug for this and will publish a patch plus additional WPTs to catch this case.

Comment 7

[Sajid Anwar [:sajidanwar]]

Attachment: text-box-edge-text-demo.html

Test case where a block contains some text and two <canvas> elements, one with vertical-align: text-top and the other with vertical-align: text-bottom. The block's font is Arial, which I confirmed on my macOS system has a non-zero internal leading (using HarfBuzz's hb-info to see that the ascent plus descent is larger than the units-per-em).

• On Firefox Nightly, the block is trimmed too far beyond the true text-over and text-under baselines (top of the first canvas and bottom of the second canvas, respectively).
• On Chrome and Safari, the block is trimmed to exactly the top and bottom of the canvas elements.

(The text-over and text-under baselines are font-dependent, so for example, on macOS with my default Helvetica font, there actually is no internal leading so the trimming is the same across browsers. I think this is part of why I missed this.)

Comment 8

[Sajid Anwar [:sajidanwar]]

Filed Bug 2055372 to fix this text edge metric.

Comment 9

[Sajid Anwar [:sajidanwar]]

Fix has landed on Nightly, Firefox is now matching Chrome and Safari on the MDN example for the text edge. Thanks again, Sebastian!

Comment 10

[Dave Letorey]

Related pull requests

• BCD PR
• Firefox Release PR