- 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
The CSS Working Group just discussed `column-span`. <details><summary>The full IRC log of that discussion</summary> <astearns> topic: column-span<br> <emilio_> github: https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-465362932<br> <emilio_> rachelandrew_: it's a reopened issue that was resolved on but dbaron reopened requesting some clarification<br> <emilio_> rachelandrew_: the example is figure 11 in the spec<br> <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> <astearns> s/11/21/<br> <fantasai> I think this just needs to adopt the same wording as CSS2.1 block-in-inline splits<br> <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> <emilio_> dbaron: a more interesting is what happens when there's an explicit height and how's it distributed<br> <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> <Rossen> q?<br> <emilio_> dbaron: I think everyone pretty much agreed with the outcomes even if there's disagreement on how to describe them<br> <emilio_> florian[m]: there are a couple related aspects<br> <emilio_> florian[m]: <section><div><aside><span>splitted element<br> <emilio_> <section><div><aside column-span: all><br> <emilio_> florian[m]: We thought it could be described like the spanner being oof<br> <emilio_> florian[m]: but forces a fragmentation break<br> <emilio_> florian[m]: so that it doesn't influence min-content and such<br> <emilio_> florian[m]: the div is not affected by the span itself<br> <emilio_> florian[m]: I think it's easier to define the span this way<br> <emilio_> rachelandrew_: I think it's one of the cleanest way to describe it<br> <emilio_> rachelandrew_: and easier to understand<br> <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> <emilio_> florian[m]: it's not quite true that oof don't affect the float -> floats<br> <emilio_> florian[m]: we need to define the specifics, but other than that is out of flow<br> <fantasai> emilio_^: actually, it leaves behind a break opportunity<br> <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> <fantasai> florian: In this case it would be a forced break rather than a break opportunity<br> <fantasai> Rossen: This is the model we use in Edge. We treat it as out-of-flow and force a break<br> <emilio_> Rossen: this is the exact model we use for spanners in edge<br> <emilio_> AmeliaBR: is probably worth referecing it as being similar to a flow wrt. background painting order and co?<br> <emilio_> rachelandrew_: yeah I think I should write some spec text<br> <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