[css-inline-3] leading-trim through to descendant line boxes

[fantasai]

The current definition of leading-trim relies on the concept of “first formatted line”. This was done for two reasons:

• it drills down through unstyled block boxes, which is helpful to the author and absolutely necessary given the way we generate anonymous block boxes
• it correctly aborts on nested formatting contexts, replaced elements, etc.

However, it might be a bit too aggressive, as it also drills through styled block boxes. Consider

  <section style="leading-trim: start">
     <div class="warning" style="border: solid 10px; padding: 0.2em">...</div>
     <p>Whatever normal paragraph.</p>
  </section>

The .warning would probably be a bit surprised if the section trimmed its half-leading when it didn't request such trimming itself.

I think we might want to borrow the logic from margin collapsing, and not drill into boxes with non-zero padding/border. Whether or not the margins could have collapsed seems closely related to whether or not this block’s own content edge is adjacent to its descendant's first/last line box and therefore whether it should be controlling the leading on that line.

[css-meeting-bot]

The CSS Working Group just discussed leading-trim through to descendant line boxes, and agreed to the following:

• RESOLVED: Don't drill through in a way we can block boxes with non-zero padding / border in the block axis

The full IRC log of that discussion

<fantasai> Topic: leading-trim through to descendant line boxes
<fantasai> github: https://github.com//issues/5237
<emilio> fantasai: leading-trim relies on the concept of "first formatted line", which is needed to deal with anon blocks and also nested blocks
<emilio> ... however it may be a bit too aggressive as it also drills into styled boxes
<emilio> ... see the example in the issue, the leading-trim of the outer box ends up affecting the leading of the "warning" box even though it was already styled
<emilio> ... it doesn't seem like the author would spec
<AmeliaBR> This definitely sounds like something that should match up with margin collapsing rules.
<emilio> ... so I think we should do what margin collapsing does and don't drill into boxes with non-zero border / padding
<emilio> dbaron: do you want to make it also condition on the margin-collapsing definition or just reuse it?
<emilio> ... I think you should intersect the definition
<emilio> ... because otherwise you'd apply it to some empty lines and it'd be bad
<emilio> q+
<emilio> iank_: there's a lot of complications round floats and margin-collapsing, which you may be very careful of
<astearns> ack faceless2
<dbaron> yeah, it might be better to take the relevant parts of the margin-collapsing definition rather than actually referring to it
<astearns> ack emilio
<faceless2> q-
<astearns> ack faceless
<heycam> emilio: would it be better to say anonymous block boxes inherit this property?
<emilio> fantasai: I think you may want to apply it to non-anonymous boxes as well, like chapter -> paragraph, specially if those margins are collapsed
<emilio> florian: another one would be the notes in specs, some of them have paragraphs inside some don't, and you want to treat them equally
<emilio> fantasai: I think I'll try to spec this and then come back
<dbaron> another fun question is whether there are any interactions with 'clear'
<emilio> RESOLVED: Don't drill through in a way we can block boxes with non-zero padding / border in the block axis
<emilio> err
<emilio> s/in a way we can//

[fantasai]

Proposed definition:

Trim the block-start side of the first formatted line to the corresponding 'text-edge' metric of its root inline box. If there is no such line, or if there is intervening non-zero padding or borders, there is no effect.

Agenda+ to confirm as requested by previous discussion.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] leading-trim through to descendant line boxes, and agreed to the following:

• RESOLVED: Accept the proposed text
• RESOLVED: Rename the property from leading-trim to trim-leading

The full IRC log of that discussion

<dael> Topic: [css-inline-3] leading-trim through to descendant line boxes
<dael> github: https://github.com//issues/5237
<dael> fantasai: WG wanted to reconfirm
<fantasai> https://github.com//issues/5237#issuecomment-673312639
<dael> fantasai: I left it as first formatted line and no interveneing non-0 padding or borders. Whatever we take for margin we should take here. This is the current text
<fantasai> s/Whatever/whatever clarifications/
<dael> dholbert: one question [missed]
<dael> dholbert: If you have an inline level span with a border sounds like that would cause the leading trim to be excldued. I think intent was only block level
<dael> fantasai: You're trimming the line's leading to the text of root inline box which is by definition unstyled. We can clarify that
<dael> smfr: Are we stuck with name?
<dael> fantasai: no
<drousso_> +1 to name change
<dael> smfr: Can we cal it trim-leading? I think people will read it as leading trim not leading trim
<astearns> OK with name change
<dael> Rossen_: Any reasons why we shouldn't do that?
<TabAtkins> We don't usually do verbs, but this is a confusing term in the first place.
<dael> plinss: Not opposed but I think it'll have the same problem with trim-leading
<dael> fantasai: I'm also open to other terms. That's the first one we came up with
<TabAtkins> ledding
<dael> Rossen_: WE can resolve on the rename. What about proposed definition? Can we resolve on that?
<dael> Rossen_: Objections?
<dael> RESOLVED: Accept the proposed text
<dael> Rossen_: Rename to trim-leading. Objections?
<dael> RESOLVED: Rename the property from leading-trim to trim-leading