You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-multicol] definition of column-span should say what happens without an ancestor multicol #1074
The definition of column-span: all should say what happens if there is no "nearest multicol ancestor in the same block formatting context". This is relatively straightforward; the column-span property doesn't do anything in that case. However, the spec should say so.
Also probably worth noting that invalid spanners don't force creation of new block formatting contexts and things like that, so that e.g. the following passes:
<!-- Not inside a multicol container. -->
<p>No red should be seen.</p>
<div style="float:left; width:20px; height:20px; background:green;"></div>
<div style="column-span:all; width:20px; height:20px; background:red;"></div>
This isn't particularly related to #1072, and I think it's trivial enough that it can be resolved at editor discretion if the existing implementations do the obvious thing.
So it looks like Chrome is the odd one here, right? In a way I find it strange that a property meant to be used inside multicol containers only has any effect on elements not inside such a container, but the spec does say that column-span applies to "in-flow block-level elements". The spec needs to become clearer. I have no strong opinions when it comes to the exact resolution, other than the fact that it should either be:
A: Chrome has a bug - fix the spec to say that column-span:all outside of multicol still establishes a new block formatting context (on that note: issue #1071 points out that "block formatting context" isn't good wording)
B: Beef up the spec and have the other browsers align with Chrome's behavior
The case to think about here is, what if the designer had a two-column layout and then switched to a one-column layout. What's least likely to cause breakage? BFCs have to main behaviors that are relevant here: containing floats, and collapsing margins with children. Floats inside column-spanners might be a bit rare, but margins are common. It would imho make sense to preserve the BFC-ness to ensure the children of the spanner don't start collapsing with their parent.
@atanassov I've already made the edit almost a week ago (a8634b9) and closed the bug. I guess this Needs Editslabel is a mistake, and that you hadn't seen this was done already. If you actually want some more edits, please let me know what.
@yisibl Thanks for the quick fix in chrome. Would you have some Test cases to submit while you're at it? I'll review them ASAP if you do submit something. Btw, the relevant bug for the #1179 PR is #1071, not this one.
Activity
mstensho commentedon Mar 6, 2017
Also probably worth noting that invalid spanners don't force creation of new block formatting contexts and things like that, so that e.g. the following passes:
<!-- Not inside a multicol container. -->
<p>No red should be seen.</p>
<div style="float:left; width:20px; height:20px; background:green;"></div>
<div style="column-span:all; width:20px; height:20px; background:red;"></div>
tantek commentedon Mar 7, 2017
Agenda+ing just to make sure the WG is ok with this proposal. Figuring we're going to talk a lot of multicol this week.
astearns commentedon Mar 8, 2017
Removing agenda+ until #1072 is resolved
dbaron commentedon Mar 8, 2017
This isn't particularly related to #1072, and I think it's trivial enough that it can be resolved at editor discretion if the existing implementations do the obvious thing.
neerjapancholi commentedon Mar 25, 2017
Tested the case suggested by @mstensho on different browsers and posting results with screenshots:
Test case:
https://jsfiddle.net/Ld86cuwk/
Screenshot of Chrome:

Screenshot of Safari (same for Edge):

frivoal commentedon Mar 27, 2017
Firefox agrees with Chrome.Ignore me, that's just because FF does not implement column-span yet.
frivoal commentedon Mar 27, 2017
Unfortunately, not all do. So we do need to talk…
mstensho commentedon Mar 28, 2017
So it looks like Chrome is the odd one here, right? In a way I find it strange that a property meant to be used inside multicol containers only has any effect on elements not inside such a container, but the spec does say that column-span applies to "in-flow block-level elements". The spec needs to become clearer. I have no strong opinions when it comes to the exact resolution, other than the fact that it should either be:
A: Chrome has a bug - fix the spec to say that column-span:all outside of multicol still establishes a new block formatting context (on that note: issue #1071 points out that "block formatting context" isn't good wording)
B: Beef up the spec and have the other browsers align with Chrome's behavior
fantasai commentedon Mar 29, 2017
The case to think about here is, what if the designer had a two-column layout and then switched to a one-column layout. What's least likely to cause breakage? BFCs have to main behaviors that are relevant here: containing floats, and collapsing margins with children. Floats inside column-spanners might be a bit rare, but margins are common. It would imho make sense to preserve the BFC-ness to ensure the children of the spanner don't start collapsing with their parent.
dbaron commentedon Apr 7, 2017
In Wednesday's WG teleconference the group resolved:
yisibl commentedon Apr 9, 2017
PR: Becomes a formatting context: #1179
Chrome fixed it in: https://bugs.chromium.org/p/chromium/issues/detail?id=709362
frivoal commentedon Apr 11, 2017
@atanassov I've already made the edit almost a week ago (a8634b9) and closed the bug. I guess this
Needs Editslabel is a mistake, and that you hadn't seen this was done already. If you actually want some more edits, please let me know what.@yisibl Thanks for the quick fix in chrome. Would you have some Test cases to submit while you're at it? I'll review them ASAP if you do submit something. Btw, the relevant bug for the #1179 PR is #1071, not this one.