W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2020

Re: [csswg-drafts] [css-inline-3] leading-trim through to descendant line boxes (#5237)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Tue, 28 Jul 2020 21:27:14 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-665292525-1595971633-sysbot+gh@w3.org>
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`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: leading-trim through to descendant line boxes<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/5237<br>
&lt;emilio> fantasai: leading-trim relies on the concept of "first formatted line", which is needed to deal with anon blocks and also nested blocks<br>
&lt;emilio> ... however it may be a bit too aggressive as it also drills into styled boxes<br>
&lt;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<br>
&lt;emilio> ... it doesn't seem like the author would spec<br>
&lt;AmeliaBR> This definitely sounds like something that should match up with margin collapsing rules.<br>
&lt;emilio> ... so I think we should do what margin collapsing does and don't drill into boxes with non-zero border / padding<br>
&lt;emilio> dbaron: do you want to make it also condition on the margin-collapsing definition or just reuse it?<br>
&lt;emilio> ... I think you should intersect the definition<br>
&lt;emilio> ... because otherwise you'd apply it to some empty lines and it'd be bad<br>
&lt;emilio> q+<br>
&lt;emilio> iank_: there's a lot of complications round floats and margin-collapsing, which you may be very careful of<br>
&lt;astearns> ack faceless2<br>
&lt;dbaron> yeah, it might be better to take the relevant parts of the margin-collapsing definition rather than actually referring to it<br>
&lt;astearns> ack emilio<br>
&lt;faceless2> q-<br>
&lt;astearns> ack faceless<br>
&lt;heycam> emilio: would it be better to say anonymous block boxes inherit this property?<br>
&lt;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<br>
&lt;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<br>
&lt;emilio> fantasai: I think I'll try to spec this and then come back<br>
&lt;dbaron> another fun question is whether there are any interactions with 'clear'<br>
&lt;emilio> RESOLVED: Don't drill through in a way we can  block boxes with non-zero padding / border in the block axis<br>
&lt;emilio> err<br>
&lt;emilio> s/in a way we can//<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5237#issuecomment-665292525 using your GitHub account
Received on Tuesday, 28 July 2020 21:27:16 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:12 UTC