Bug 261137 – text-box-trim leading radically different results from Figma

• Status: RESOLVED
• Resolution: INVALID
• Component: CSS

Created attachment 467549 [details]
comparison

Hi,

We are currently considering using text-box-trim as a progressive enhancement, to ensure the spacing looks consistent across a wide range of fonts.

Figma recently introduced support for text-box-trim/text-box-edge, unfortunately there is a big discrepancy between what Figma renders and what Safari TP renders. I have no idea which one is incorrect, but the Safari result is unfortunately unusable (so I hope Safari is wrong).

Figma internally uses "cap" for text-box-edge and "both" for text-box-trim. I think the choice to use cap instead of cap alphabetic is to ensure it works best even when all the text is in uppercase.

I have attached a screenshot of the differences. I also set a minimum test case that reproduce the odd alignment on Safari: https://codepen.io/bakura10/pen/jOXVNpj

[fantasai]

If you want to trim to the cap height on the top and alphabetic baseline on the bottom, you need to specify those metrics. Trimming to the cap height and alphabetic baseline only works in some writing systems--it works fine for English, for example, but not for Chinese. So the default behavior doesn't cut into the space reserved by the font, it only removes the half-leading added by 'line-height'.

[fantasai]

The spec for text-box-trim is here, btw: https://www.w3.org/TR/css-inline-3/
If Figma is defaulting to the cap height and alphabetic baseline, then it's not following the spec.

[Radar WebKit Bug Importer]

<rdar://problem/115338864>

[fantasai]

Also, if you're trimming the span that won't have any effect on the paragraph. You need to trim the paragraph to affect the paragraph.