[css-inline-3] It's impossible to use text-box-trim without changing line progression within the paragraph

[litherum]

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

Name:	text-box-trim
Value:	none | start | end | both

...
start
For block containers: trim the block-start side of the first formatted line to the corresponding text-box-edge metric of its root inline box.

The two properties text-box-trim and text-box-edge have very different purposes. One changes the spatial relationship of blocks with respect to each other, whereas the other changes the progression of lines within a block. At a fundamental level, these purposes are orthogonal. If an author just wants to change their blocks' positions, they shouldn't have to change the progression of lines within their blocks.

Philosophically, there is no reason to connect text-box-trim and text-box-edge the way they're linked in the spec now. Instead, we'd like to propose changing the grammar to be something like (cribbed from the text-box-edge property):

Name:	text-box-trim
Value:	leading | [ text | cap | ex | ideographic | ideographic-ink ] [ text | alphabetic | ideographic | ideographic-ink ]?

This would allow text-box-trim and text-box-edge's behavior to be orthogonal to each other.

[fantasai]

I think this is related to (possibly a duplicate of) #8696 ?

[litherum]

No. That other issue is about adding a 3rd CSS property. That's not what we are suggesting. We are suggesting keeping 2 properties, but changing the value space of one of them.

[fantasai]

Discussed this with @litherum and [WebKit] Alan. The suggestion is to fix this issue and #8696 by:

• Shifting the line-box-affecting aspects of text-box-edge to a new property (e.g. text-line-edge).

• Combining text-box-edge and text-box-trim into a shorthand property (e.g. text-box) that sets both, so that an author can get trimming to, for example, the cap height and alphabetic baseline in a single declaration.

Open questions:

• Whether or not the longhands should exist. (Their main benefit is for internationalization, since they allow the edges to cascade independently of whether or not the trimming happens.)

• Whether there should be an auto value that maps text-box-edge to text-line-edge or something like that; and whether it should be the initial value.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] It's impossible to use `text-box-trim` without changing line progression within the paragraph, and agreed to the following:

• RESOLVED: Three longhand properties as proposed with two linked by a shorthand, names to be bikeshed, one issue for each to work them out

The full IRC log of that discussion

<emeyer> fantasai: Two issues are open on the fact that the current way we’ve set up this trimming feature depends on a property that has two different effects
<emeyer> …I’ll call one the leading-trim effect
<emeyer> …This is the effect of taking the first line box and trimming down to some metric rather than the full ascent of the font and half-leading and so on
<emeyer> …Same thing on the bottom edge
<emeyer> …The second, the line-box-contain effect
<emeyer> …Line boxes can grow, but this effect allows us to say for an inline box, rather than using ascent metrics, use another metric like the cap-height
<emeyer> …That way an accent on top of a character can leak outside the line box and that’s okay
<emeyer> …The issues say it would b e useful to separate these two
<emeyer> …An author might want to use one over the other
<emeyer> [some things missed]
<emeyer> …Proposal is to split text-box-edge into text-box-edge and text-line-edge (names subject to bikeshed)
<emeyer> …Does this make sense or do we need more description?
<emeyer> astearns: It makes sense to have separate properties; the neames should give an idea of the connection between them
<emeyer> …Not sure ‘box’ and ‘line'
<emeyer> …do that
<emeyer> jensimmons: Use case: I might be an author who wants my paragrtaph box to line up with a floated image, so I need to chop off the paragrpah’s top whitespace
<emeyer> …So I use text-box-edge and chop it to the cap height or x-height or whatever
<emeyer> …Separate, there are accent marks or super/subscripts and I get weirdness where extra line box height happens
<emeyer> …I want the spacing to be regular throughout the text so the vertical rhythm is consistent
<emeyer> …I need to be able to say I want to use this different font metric than is used to line up block edges with floats or whatever
<florian> q+
<emeyer> dbaron: It wasn’t clear to me which property you were proposing to split
<emeyer> fantasai: Right now, leading-trim works at the intersection text-box-trim (which looks up text-box-edge)
<emeyer> …text-box-edge says what metric you care about: ascent, cap-height, something else
<emeyer> dbaron: And that only applies to inlines?
<emeyer> fantasai: Right
<florian> q-
<florian> q+
<emeyer> dbaron: You want to let people set inline and block trimming differently
<emeyer> fantasai: Yes
<emeyer> jensimmons: I think it will become best practice for authors to put into resets a thing to change how box models work for lines and line boxes
<emeyer> …Separately, you might need to do something different in certain places
<emeyer> dbaron: The one that interacts with text-box-trim needs to be narrowed?
<emeyer> jensimmons: I think so, yeah
<emeyer> dbaron: Okay, this makes sense
<astearns> ack florian
<emeyer> florian: Even if you’re not looking at different font metrics, in the old model you had to turn on line re-jiggling
<emeyer> …With this you can say this is what I do to boxes, leave the lines alone
<emeyer> jensimmons: I do think authors think of these things differently
<florian> s/on line re-jiggling/on line re-jiggling to be able to access the box trimming
<emeyer> …Having them tied together doesn’t quite make sense
<emeyer> fantasai: Going into the re-jiggling of the properties, we end up with three longhands
<emeyer> …text-line-edge to measure line edges
<emeyer> …text-box-edge
<emeyer> …text-box-trim, which sets the side you trim
<emeyer> …From there, we can create a shorthand which sets side and trim in one shot
<emeyer> …So an author who want to affect line sizing would set tex-tline-edge, which inherits
<emeyer> …An author could set text-box-edge to say which boxes are trimmed
<emeyer> …We can also eliminate the longhand of text-box and have a property that just sets the sidess with the trim
<emeyer> …The advantage of longhand is that you can set these things separately without needing variables
<emeyer> …That’s an open question of whether to have the longhands, or just have the shorthand
<florian> q+
<emeyer> …Another open question is whether the initial value of etext-box-edge shoudl be an auto that looks up text-line-edge
<emeyer> s/shoudl/should/
<astearns> ack florian
<emeyer> florian: I think we do want the longhands
<emeyer> …One seems to be linguisitcally dependent, the other not
<emeyer> …Not sure what we should call the shorthands, but we can figure that out
<emeyer> astearns: Should we resolve on having three longhand properties and have one issue for each?
<emeyer> fantasai: Seems fine; I would also add the shorthand to encompass two of them
<emeyer> astearns: I would really like to see examples, particularly of the reset things Jen was talking about
<emeyer> …Showing the motivation for having a separate property
<emeyer> …Then another example showing how you would use the properties together
<emeyer> RESOLVED: Three longhand properties as proposed with two linked by a shorthand, names to be bikeshed, one issue for each to work them out