-
Notifications
You must be signed in to change notification settings - Fork 672
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
Comments
The CSS Working Group just discussed
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// |
Proposed definition:
Agenda+ to confirm as requested by previous discussion. |
The CSS Working Group just discussed
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 |
On the name question: we don't actually use “leading” to describe space between lines anywhere in CSS, do we? Could this be (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”.) |
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. |
The current definition of
leading-trim
relies on the concept of “first formatted line”. This was done for two reasons:However, it might be a bit too aggressive, as it also drills through styled block boxes. Consider
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.
The text was updated successfully, but these errors were encountered: