W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

Re: [csswg-drafts] [css-multicol] How do elements between column-span and its multicol ancestor appear around the span (#1072)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 Feb 2019 00:33:46 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-468087733-1551314025-sysbot+gh@w3.org>
The CSS Working Group just discussed `column-span`.

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> topic: column-span<br>
&lt;emilio_> github: https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-465362932<br>
&lt;emilio_> rachelandrew_: it's a reopened issue that was resolved on but dbaron reopened requesting some clarification<br>
&lt;emilio_> rachelandrew_: the example is figure 11 in the spec<br>
&lt;emilio_> rachelandrew_: the initial thing was mentioned was essentially a clarification. The situation is when margins paddings and borders are split by the spanner, but an empty fragment ends up before the spanner<br>
&lt;astearns> s/11/21/<br>
&lt;fantasai> I think this just needs to adopt the same wording as CSS2.1 block-in-inline splits<br>
&lt;emilio_> dbaron: a bunch of the clarifications was just to say what happens for elements that are both descendants of the multicol and ancestors of the spanner when they're split by the spanner<br>
&lt;emilio_> dbaron: a more interesting is what happens when there's an explicit height and how's it distributed<br>
&lt;emilio_> fantasai_: simplest is to treat the split as creating a fragmentation break, but computes padding borders as if the spanner didn't exist<br>
&lt;Rossen> q?<br>
&lt;emilio_> dbaron: I think everyone pretty much agreed with the outcomes even if there's disagreement on how to describe them<br>
&lt;emilio_> florian[m]: there are a couple related aspects<br>
&lt;emilio_> florian[m]: &lt;section>&lt;div>&lt;aside>&lt;span>splitted element<br>
&lt;emilio_> &lt;section>&lt;div>&lt;aside column-span: all><br>
&lt;emilio_> florian[m]: We thought it could be described like the spanner being oof<br>
&lt;emilio_> florian[m]: but forces a fragmentation break<br>
&lt;emilio_> florian[m]: so that it doesn't influence min-content and such<br>
&lt;emilio_> florian[m]: the div is not affected by the span itself<br>
&lt;emilio_> florian[m]: I think it's easier to define the span this way<br>
&lt;emilio_> rachelandrew_: I think it's one of the cleanest way to describe it<br>
&lt;emilio_> rachelandrew_: and easier to understand<br>
&lt;emilio_> fantasai_: I think out of flow stuff in CSS is taken out of the flow, the rest of the stuff is supposed to ignore it. an oof span in a paragraph doesn't cause a break on the parent<br>
&lt;emilio_> florian[m]: it's not quite true that oof don't affect the float -> floats<br>
&lt;emilio_> florian[m]: we need to define the specifics, but other than that is out of flow<br>
&lt;fantasai> emilio_^: actually, it leaves behind a break opportunity<br>
&lt;fantasai> emilio_: At least in Gecko, Webkit and Blink, out-of-flows do create break opportunities. I believe it's a bug. Edge does it right.<br>
&lt;fantasai> florian: In this case it would be a forced break rather than a break opportunity<br>
&lt;fantasai> Rossen: This is the model we use in Edge. We treat it as out-of-flow and force a break<br>
&lt;emilio_> Rossen: this is the exact model we use for spanners in edge<br>
&lt;emilio_> AmeliaBR: is probably worth referecing it as being similar to a flow wrt. background painting order and co?<br>
&lt;emilio_> rachelandrew_: yeah I think I should write some spec text<br>
&lt;emilio_> RESOLVE: Clarify the spec using the notion that this is an out of flow that leaves a forced break behind<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-468087733 using your GitHub account
Received on Thursday, 28 February 2019 00:33:48 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:44 UTC