CSS Inline text-box, text-box-trim, text-box-edge

[kojiishi]

WebKittens

@fantasai @nt1m

Title of the proposal

CSS Inline text-box, text-box-trim, text-box-edge

URL to the spec

https://drafts.csswg.org/css-inline-3/#leading-trim

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

https://kojiishi.github.io/explainers/text-box-trim

TAG Design Review URL

w3ctag/design-reviews#1021

Mozilla standards-positions issue URL

mozilla/standards-positions#1105

WebKit Bugzilla URL

No response

Radar URL

No response

Description

To achieve optical balance of text content, the text-box-trim and text-box-edge properties, along with the text-box shorthand property, make finer control of vertical alignment of text possible.

[nt1m]

I'll mark this as position: support pending objections week from now.

[Schweinepriester]

Shipping this already is probably even better than just marking as support? :D

https://webkit.org/blog/16301/webkit-features-in-safari-18-2/

Originally called "leading trim", this feature is now simply text-box. It's a shorthand for two longhands properties--- text-box-trim and text-box-edge --- which you can declare separately if you need to control how each cascades. Safari 18.2 is the first browser to ship Text Box

👏

[argyleink]

ISSUE 12 in the spec draft says "Do not ship (yet)."?

https://drafts.csswg.org/css-inline-3/#leading-trim

[Schweinepriester]

ISSUE 12 in the spec draft says "Do not ship (yet)."?

https://drafts.csswg.org/css-inline-3/#leading-trim

Chrome is also just shipping :D

• https://groups.google.com/a/chromium.org/g/blink-dev/c/4NeTpgsi64A/m/hDMkvOs2AQAJ
• https://chromestatus.com/feature/5174589850648576

[jensimmons]

Safari shipped text-box, text-box-trim, and text-box-edge today, Dec 11, 2024.

[yisibl]

@jensimmons @fantasai I was wondering if Safari supports ideographic and ideographic-ink? I haven't seen a demo for it.

[yisibl]

@kojiishi I've noticed that it works differently in Chrome canary than Safari, can you investigate this before Ship?

https://codepen.io/jensimmons/full/gbYMERz/d04ddec1bd31a5ce3792d3bfcb34dffb

[bramus]

@kojiishi I've noticed that it works differently in Chrome canary than Safari, can you investigate this before Ship?

Please file a bug over at https://crbug.com/ so that this is tracked. Thank you.

[nt1m]

@jensimmons @fantasai I was wondering if Safari supports ideographic and ideographic-ink? I haven't seen a demo for it.

It should.

[nt1m]

@kojiishi I've noticed that it works differently in Chrome canary than Safari, can you investigate this before Ship?

https://codepen.io/jensimmons/full/gbYMERz/d04ddec1bd31a5ce3792d3bfcb34dffb

This looks like a bug in Chromium fwiw.

text-box: trim-start cap seems to be computed as text-box: trim-start auto, where text-box-edge gets the wrong value (see the computed style pane).

[bramus]

Thanks for chiming in everyone, I have filed https://issues.chromium.org/issues/385160696 and CC’d @yisibl and @kojiishi on the bug.

[kojiishi]

@nt1m

@kojiishi I've noticed that it works differently in Chrome canary than Safari, can you investigate this before Ship?
https://codepen.io/jensimmons/full/gbYMERz/d04ddec1bd31a5ce3792d3bfcb34dffb

This looks like a bug in Chromium fwiw.

text-box: trim-start cap seems to be computed as text-box: trim-start auto, where text-box-edge gets the wrong value (see the computed style pane).

Please take a look at w3c/csswg-drafts#10703. It looks like the spec hasn't updated for this resolution. @fantasai

In this case, it has text-box-edge: cap. The cap value can't be doubled (i.e., it's not a valid value for the under side), so two values are required. Since it's missing, the text-box-edge is invalid, making it to the initial value.

[nt1m]

@nt1m

@kojiishi I've noticed that it works differently in Chrome canary than Safari, can you investigate this before Ship?
https://codepen.io/jensimmons/full/gbYMERz/d04ddec1bd31a5ce3792d3bfcb34dffb

This looks like a bug in Chromium fwiw.
text-box: trim-start cap seems to be computed as text-box: trim-start auto, where text-box-edge gets the wrong value (see the computed style pane).

Please take a look at w3c/csswg-drafts#10703. It looks like the spec hasn't updated for this resolution. @fantasai

In this case, it has text-box-edge: cap. The cap value can't be doubled (i.e., it's not a valid value for the under side), so two values are required. Since it's missing, the text-box-edge is invalid, making it to the initial value.

@kojiishi It's possible WebKit needs to update for this resolution, but in that case, I think Chromium still has a bug with the shorthand:

text-box: trim-start cap; still successfully parses in Chromium, with text-box-trim being successfully applied to trim-start, despite the text-box-edge value being incorrect. If the text-box-edge value is incorrect, it should invalidate the whole shorthand, and text-box: trim-start cap should not do anything (not even apply text-box-trim: trim-start).

[fantasai]

@kojiishi I am pretty sure I updated the spec? https://www.w3.org/TR/css-inline-3/#text-edges

That said, text-box: trim-start cap is a very reasonable thing to write and we might want to make it valid, at least in the shorthand if not in both places.

[fantasai]

@argyleink Yeah, we needed to resolve some issues around fragmentation, inheritance, etc. that were still up in the air. But with @kojiishi's help we got through those issues, and I just finally updated the spec.

[jensimmons]

I've been building demos of text-box for the last couple weeks, and have come to the conclusion that requiring authors to define both edges in the shorthand is a mistake. These should work:

• text-box: trim-start cap
• text-box: trim-start ex
• text-box: trim-end alphabetic

I'll file an issue at the CSSWG about this, but meanwhile I do not believe browsers should implement these rules as invalid.

[nt1m]

I'm not sure how I feel about making the shorthand parsing different from the longhand parsing. I'd rather have those 2 be identical. I don't really have a strong opinion whether to require two values though.

[kojiishi]

Whether to require two values or not is due to the lack of consensus at w3c/csswg-drafts#10703. Both sides have reasonable points and supporters that it wasn't easy to reach a consensus.

I think we can get more feedback and stats when developers started using this feature, which can help us to reach a consensus. Until then, I think more restrictive implementation is safe, as whichever change won't break existing sites.

[jensimmons]

I wrote up the issue today at w3c/csswg-drafts#11460