Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
fantasai opened this issue Jun 18, 2020 · 5 comments
Closed

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

fantasai opened this issue Jun 18, 2020 · 5 comments

Comments

@fantasai
Copy link
Collaborator

fantasai commented Jun 18, 2020

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
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Member

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

@AmeliaBR
Copy link
Contributor

AmeliaBR commented Sep 2, 2020

On the name question: we don't actually use “leading” to describe space between lines anywhere in CSS, do we? Could this be line-height-trim or something similar?

(I myself initially assumed it was “leading” meaning “trim off the starting bit, above the first line”, not “trimming off the extra lead/metal from your type pieces so you can pack them in more compactly”.)

@zed-vector
Copy link

Amelia, 'leading' means (a) the strips of lead added between lines of type to increase the line spacing, and (b) the amount by which the line height is so increased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants