[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

fantasai: we split property into 2
fantasai: one detail we should clarify : when you paint an inline box what edge to you use to paint the box
fantasai: when text-box-trim is on, we should use the edge to paint the background
fantasai: what edge do we use to size the text ?
fantasai: do we use the painted edge ? or we still size it against the line-fit-edge ?
fantasai: if text-box-trim is off, and we have border/background, what edge to we draw them ? (line-fit or text edges)
fantasai: in the new line box model, we want to use the visible edges of the box to show the contribution of the box
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
fantasai: otherwise that creates inconsistency between box used for sizing and box used for background
q?
PROPOSED: text-box-trim trims inline to the text-box-edge; otherwise use the line-fit-edge; both for sizing and for painting
(except when line-fit-edge is normal and we do the weird old thing)
RESOLVED: text-box-trim trims inline to the text-box-edge; otherwise use the line-fit-edge; both for sizing and for painting
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, Some text and Some text must have identical rendering, no matter what styles are applied to .

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 ) affects its line height contribution, it cannot be less than the contribution of an unstyled 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

fantasai: Was making the edits for this and noticed we have an issue around
… resolution wasnt 100% clear.
… have two different line height sizing modes
… depending on line fit
… we resolveed to make t-b-trim affect inline boxes
… and it definitely affects where the content edge is drawn
fantasai: we have a transparency principle
fantasai: an unstyled span around some text should not affect layout
So, for example, Some text and Some text must have identical rendering, no matter what styles are applied to .
Sorry, have to drop
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).
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 \) affects its line height contribution, it cannot be less than the contribution of an unstyled 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.

[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 does not change height contribution of inline
• ACTION: fantasai to make testcase and report back on WebKit/Chrome implementation status
• RESOLVED: 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

The full IRC log of that discussion

https://github.com//issues/10834#issuecomment-2540644321
fantasai: problem statement is at (link in chat)
... we have a transparency principle that an unstyled inline should have no effect on layout
... if I have some text in an and insert a that should not affect formatting
Some text vs Some text must be identical
... that means properties need to be inherited if they affect inline layout
... q is what does text-box-trim do on inlines
... backgrounds and bortders on inlins traditionally do not affect layout and that's fine
... we also talked about text-box-trim impacting height of line on an inline
s/bortders/borders/
... my conclusion is I don't think we should do that
... because if we set text-box-trim on an inline, e.g. on a span, that will affect the line height because the inner element now has a taller height
... I think we have to specify that when we are in default line height mode, text-box-trim can change how backgrounds and borders are drawn
... but it does not change the height contribution of the inline
... which remains based on line-height property
astearns: dbaron commented on different effects on blocks and inlines
fantasai: we have a distinction, it's called line-fit-edge
... that's a separate property which allows it to trim
... Proposal Part A: text-box-trim does not change height contribution of inline
Part A sounds good to me
Proposed: text-box-trim does not change height contribution of inline
RESOLVED: text-box-trim does not change height contribution of inline
fantasai: next part: we have a line-fit-edge property; it changes to a new inline layout model
... where instead of using line-height as height contribution, we use margin box edge
... in addition, it also lets you control which edge you use, effectively setting default edge to be used
... and that inherits
... what we could do is have a negative margin
... negative margin ran into this transparency issue
... to solve it, we said negative margin is propagated to descendant of inline box
... if we say text-box-trim is applied to this box and changes where borders and padding are drawn, then it should correspondingly affect height contribution
... but since it doesn't inherit, we somehow need to propagaste
... in the same way as a negative margin would be
... Proposal is that, in this mode, the amount by which text-box-trim reduces margin box is propagated as a negative margin
astearns: is this propagation of negative margins a new thing?
PROPOSAL: 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
fantasai: the line-fit-edge negative margin is a new thing, yes
astearns: concerned this new thing may have side effects
dbaron: Right now we already have these rules for special proagation of negative margins when you have line-fit-edge in non-default value
... proposal is that, when you use text-box-trim, in this case where line-fit-edge has non-default value, then negative margin gets propagated to descendants? in addition to other negative margin?
fantasai: yes
dbaron: I think this makes sense, but we need to think about the line-fit-edge model some more and test it some more
... but this proposal does seem to make sense to me
fantasai: agree 100%
astearns: Restating: the effect of text-box-trim contributes to the negative margin that is assessed when line-fit-edge is non-default and propagates to descendants
fantasai: correct
astearns: Not sure I understand repercussions, need to take a deep look at this, but I'm fine with resolving on this
chrishtr: re: first resolution: is normal the default?
fantasai: yes
chrishtr: does that have an effect on chromium/webkit implementation of [missed]
s/[missed]/text-box-trim/
fantasai: I haven't tested that, not sure what implementations are doing
... but it's only on inline boxes
chrishtr: could you take an action item to take on that?
ACTION: fantasai to make testcase and report back on WebKit/Chrome implementation status
chrishtr: bonus points for a WPT
Proposed: interaction between line-fit-edge and text-box-trim contributes to a negative margin that is propagated to inline descendants
RESOLVED: 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