[css-inline-3] inline boxes and line-fit-edge vs text-box-trim/edge

[fantasai]

Now that we've split line-fit-edge (inherited) and text-box-edge (non-inherited), there's an interesting question of how these two features interact when applied to inline boxes, particularly if they have conflicting "opinions".

Inline boxes currently have two sizes:

• the size used to calculate their "fit" within the line box
• the sized used to draw backgrounds and borders

In the existing line height model, these two are not the same: block-axis margin/padding/borders are ignored completely for sizing, in favor of line-height.

In the newer line-height model, as part of making inline layout more controllable, we want to use the margin box for sizing. That means line-fit-edge has to trim down the content box, not an imaginary other box, otherwise it's confusing (to size by applying margin/padding to one set of edges, but draw by applying it to a different set of edges). Thus by default, we need to apply trimming to inline boxes.

The initial value of text-box-trim is none. Should we:

1. Make text-box-edge ignored by inline boxes and always trim to the line-fit-edge?
   • This means authors can only ever use line-fit-edge to control the sizing of an inline box; but line-fit-edge inherits and might not be appropriate if they want to change the value on one item in order to draw its border differently.
2. Make text-box-edge apply to inline boxes regardless of text-box-trim? (Its initial value already defers to line-fit-edge.)?
3. Make text-box-edge apply to the sides indicated by text-box-trim only, using line-fit-edge otherwise?
4. Something else?

What would be useful and understandable?

[fantasai]

In consideration of #10904 I think we should go with the third option for the text-box properties: make text-box-edge apply to the sides indicated by text-box-trim on the inline box, and use that to draw the box decorations.

I'm still unsure how we should interact with line-fit-edge, but I think if we go with the principle that the edge used for painting and the edge used for layout should match in the new line layout model, then that means drawing to the line-fit-edge when not trimming.

In other words, the proposal is to go with option 3.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] inline boxes and line-fit-edge vs text-box-trim/edge, and agreed to the following:

• RESOLVED: text-box-trim trims inline to the text-box-edge; otherwise use the line-fit-edge; both for sizing and for painting

The full IRC log of that discussion

<matthieud> fantasai: we split property into 2
<matthieud> fantasai: one detail we should clarify : when you paint an inline box what edge to you use to paint the box
<matthieud> fantasai: when text-box-trim is on, we should use the edge to paint the background
<matthieud> fantasai: what edge do we use to size the text ?
<matthieud> fantasai: do we use the painted edge ? or we still size it against the line-fit-edge ?
<matthieud> fantasai: if text-box-trim is off, and we have border/background, what edge to we draw them ? (line-fit or text edges)
<matthieud> fantasai: in the new line box model, we want to use the visible edges of the box to show the contribution of the box
<matthieud> fantasai: to be consistent, text-box-edge should trim an inline box according to text-box-trim. if not, the edge use for drawing and sizing is the edge specified by line-fit-edge
<matthieud> fantasai: otherwise that creates inconsistency between box used for sizing and box used for background
<Rossen16> q?
<fantasai> PROPOSED: text-box-trim trims inline to the text-box-edge; otherwise use the line-fit-edge; both for sizing and for painting
<fantasai> (except when line-fit-edge is normal and we do the weird old thing)
<fantasai> RESOLVED: text-box-trim trims inline to the text-box-edge; otherwise use the line-fit-edge; both for sizing and for painting
<florian> seems fine

[fantasai]

Thinking more on this issue, one problem we need to avoid is breaking CSS's “Transparency Principle”: that inserting an unstyled inline in an inline formatting context should have no effect on styling.

So, for example, <em>Some text</em> and <em><span>Some text</span></em> must have identical rendering, no matter what styles are applied to <em>.

The height of a line box is the height of all its inline boxes regardless of nesting level. And text-box-trim does not inherit. That means that, to whatever extent text-box-trim on an element (such as an <em>) affects its line height contribution, it cannot be less than the contribution of an unstyled <span> wrapping all or any of its contents. Thus, the line height contribution of an inline with text-box-trim cannot be less than if text-box-trim were not specified on that inline.

So we can trim its content-box area for painting, but we cannot trim its height contribution. We can only increase it.

[fantasai]

Proposal Part A: When line-fit-edge is normal, we ignore the margin/border/padding and just use the line-height for sizing. In this case, text-box-trim changes the content edge (affecting backgrounds and borders), but does not change the height contribution of the inline (which continues to be based on line-height).

I think this is the most reasonable thing we can do here, given the constraints and the precedent of existing behavior.

Proposal Part B: When line-fit-edge is not normal, we use an inline's margin-box edge as its height contribution. In this case, text-box-trim indirectly affects its height contribution, by affecting the margin edges as resolved above--and in addition, if text-box-trim reduces the effective height of the inline box compared to line-fit-edge, that amount is propagated as a negative margin (the same way as a specified negative margin is propagated) to inline descendants.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] inline boxes and line-fit-edge vs text-box-trim/edge.

The full IRC log of that discussion

<bramus> fantasai: Was making the edits for this and noticed we have an issue around
<bramus> … resolution wasnt 100% clear.
<bramus> … have two different line height sizing modes
<bramus> … depending on line fit
<bramus> … we resolveed to make t-b-trim affect inline boxes
<bramus> … and it definitely affects where the content edge is drawn
<noamr> fantasai: we have a transparency principle
<noamr> fantasai: an unstyled span around some text should not affect layout
<fantasai> So, for example, <em>Some text</em> and <em><span>Some text</span></em> must have identical rendering, no matter what styles are applied to <em>.
<noamr> Sorry, have to drop
<fantasai> Proposal Part A: When line-fit-edge is normal, we ignore the margin/border/padding and just use the line-height for sizing. In this case, text-box-trim changes the content edge (affecting backgrounds and borders), but does not change the height contribution of the inline (which continues to be based on line-height).
<JakeA> Thank you all! Have a good break

[dbaron]

The height of a line box is the height of all its inline boxes regardless of nesting level. And text-box-trim does not inherit. That means that, to whatever extent text-box-trim on an element (such as an \<em\>) affects its line height contribution, it cannot be less than the contribution of an unstyled <span> wrapping all or any of its contents. Thus, the line height contribution of an inline with text-box-trim cannot be less than if text-box-trim were not specified on that inline.

So we can trim its content-box area for painting, but we cannot trim its height contribution. We can only increase it.

text-box-trim is defined to have somewhat different effects for blocks and inlines. This makes me wonder if these two different effects should be two separate properties so that the effect for inlines can be inherited. (That said, this is already a lot of properties, and I have trouble keeping track of what's what already!)

[dbaron]

That said, it's not clear to me what the effects on inlines are supposed to be. The definition of text-box-trim says they're defined in the section on logical line height contributions, which doesn't mention text-box-trim at all.