There doesn't seem to be any trace in the spec, but I am pretty sure we discussed this at some point during the last 5 years or so. I believe we had resolved to make column span only apply to direct children of the multi-col rather than arbitrary descendants to avoid this exact problem, and due to the lack of use case presented in favor of allowing it. The creation of display:contents since then makes an even stronger case for that solution, as you can get rid of unnecessary wrapper elements.

That said, maybe not. In a document with an old fashioned structure with multiple levels of headings and paragraphs all sibling of each other, then that argument may work, but with a more structured outline and nested sections, you are fairly likely to want a multi-col on a article, nest section elements in it, and want to span a heading that is a child of a section (or of a header element. I can reasonably imagine either spanning the header element instead of the h1 it contains, or applying display:contents to it, but that does not work nearly as well on the section element.

In Blink, column content is completely interrupted by a column spanner (which is non-column content). It's similar to how blocks inside inlines behave, i.e. by interrupting them. Column content (whether it's block or inline doesn't really matter, I think?) and spanners don't interact (apart from a spanner finishing and balancing the preceding column row). No column content border/background is painted in the area occupied by the spanner. Also, the containing block width of the parent of the spanner doesn't matter. What matters is the size of the content box area established by the multicol container (measured before it's divided into columns, obviously).

For this to work sensibly, we cannot just allow any kind of ancestry between the spanner and the multicol container. The spec requires that parents do not establish new formatting contexts (I think we should disallow establishing any kind of formatting context, such as tables or flexbox - and this is what Blink does.). Then, how about relative-positioning and transforms? The most sensible thing would be to let spanners be affected by such parents, right? Or, alternatively, disallow spanners inside such ancestry. Blink ignores offsets caused by relatively positioned parents, FWIW, but I'm inclined to consider that to be a bug, seeing that this is not how blocks inside relatively positioned inlines work.

In Blink, column rows and column spanners are effectively siblings. The containing block of a spanner (and of a column row, really, but they don't have a DOM node, so kind of irrelevant perhaps) is always the multicol container.

Discussed on the call - there was some interest in simplifying to make column-span apply only to direct children of the multicol element. But there was also concern about headings nested in sections and similar use cases. It would be good to find out what browsers do and do not handle a nested heading, and have some test cases added to the test suite.

Tested this on different browsers and posting results with screenshots:
(Let me know if I should add something to this)

Test case: https://jsfiddle.net/5oo2gzLy/8/

Tested on:
Chrome 56.0.2924.87 (64-bit) | Safari 10.0.3 (11602.4.8.0.1) | Edge 38.14393.0.0

Description:

• ‘Column-span: all’ is applied to break a div in two. This div has border, background, padding and margin set to observe how this is broken across the spanner.
• ‘Column-span: all’ is nested inside inside an i tag which has a div tag parent. The i tag has border, background, padding and margin set to observe how this is broken across the spanner.

Observations:

1. Border and background color for div split by column-span is consistent across all three browsers. Also, spanner does not show any indentation or overlap with the background color of the div.
   Screenshot from Chrome but result is same for Edge and Safari -
   

2. Border and background for i tag split by column-span is consistent in Chrome and Edge but in Safari you see an extra line at the top of the first column after the column span with a border and no background.
   Screenshot for Chrome but same as Edge:
   

Screenshot for Safari showing extra line with no background:

3. Spanner nested in i tag does not show any indentation or overlap of background color but it does show the 'Column-span' text italicized in all three browsers. (See screenshots above)

So implementations seem to agree with what Morten said should happen in #1072 (comment), at least in the block case. In the inline case, only safari disagrees, and I have a hard time seeing how that's useful.

Can we agree that:

• margins/padding/borders/backgrounds/outlines of ancestors of the spanner do not apply to and are not affected by the spanner (other than by the fact that it causes fragmentation)

• we should clarify/rephrase the spec to say that:

  The property has no effect on elements that are not within the BFC established by the multicol element.

  (resolving [css-multicol] definition of column-span should say what happens without an ancestor multicol #1074 at the same time)

It's probably also worth testing an example with 'position: relative; left: 100px' to see if the spanning element moves left with the relative positioning of the ancestor that it breaks, similar for a 'transform', and probably also something graphical like 'filter'.

But if all implementations are acting like those elements aren't around the spanning element in those cases as well, then we should probably just stick with that approach.

Here are the screenshots for applying relative positioning, transform and filter to the parent of the column span. In most cases (except transform in chrome shown below), the column-span itself seems unaffected by these changes but apart from that there is a lot of variation so I'm posting almost all the screenshots -

1. Adding Position: relative; left: 100px;
https://jsfiddle.net/5oo2gzLy/10/
All results are similar (with some minor bugs in Safari and Edge) so posting only one screenshot from Chrome:

2. Adding transform: rotate(90deg);
https://jsfiddle.net/5oo2gzLy/12/

Chrome:

Edge:

Safari:

3. Adding filter: grayscale(100%);
https://jsfiddle.net/5oo2gzLy/9/

Chrome:

Edge:

Safari:

Another piece that needs to be defined is the definition of emptiness for a fragment of a block or an inline that is split by a column-span:all element. That is, when you have something like:

      <div style="... maybe something interesting here?...">
          <h2 style="column-span: all">header</h2>
          ... other contents of the div ...
      </div>

under what conditions do you see pieces of the border/background of the div before the h2? Are the rules different for blocks and for inlines? Are the rules different for inlines split by a column-span: all from inlines split by a block? (I'm afraid the answer to both of the last 2 questions may need to be yes.)

It's also worth thinking about the fact that a single inline element might be split both by a block and by a column-span:all element. Those splits propagate up to different levels in the box tree.

I would hope that this would fall out of the rules in css-break, doing the same as if you had a forced break where the <h2> is, which is effectively what's happening here.

Looking at the spec, it does not seem that this behavior is invoked, even implicitly.

Do you think it would this clarification would work? changing in css-multicol's definition of column-span:all from

all: [...] Content in the normal flow that appears before the element is automatically balanced across all columns before the element appears.

to

all: [...] A <a>forced break</a> is introduced as if 'break-before: column' had been specified on the <a>spanning element</a>. Content in the normal flow that appears before <a>forced break is automatically balanced across all columns before the element appears, and the rest resumes after the <a>spanner</a>

I think this would give us a sane and consistent model. Casual testing indicates this does not seem to match what existing implementations do, but then again implementations do not seem to match each other closely either, so I do not know if we need to be bound by compat here.

An added benefit of defining things this way is that it would make clear what happens to the bottom margin of a element immediately preceding the spanner and the top margin of an element immediately following, since they would be adjoining a forced break, and what happens then is defined.

We would probably need to add normative prose supporting the claim made in example 25 that when the spanning element itself is the first thing after an unforced page break, its top margin is truncated. I guess we could do that by clarifying that the forced break is on the place holder left in flow after taking the spanning element out of flow, not on the spanning element itself.

I guess something like this:

all: The element is taken out of flow, and spans across all columns of the nearest multicol ancestor in the same block formatting context. A placeholder is left in its place, and a <a>forced break</a> is introduced as if 'break-before: column' had been specified on the placeholder. Content in the normal flow that appears before <a>forced break is automatically balanced across all columns before the <a>spanner</a>, and the rest resumes after the <a>spanner</a>

This issue was discussed in March on the call (before links were posted to github issues) so adding a link to the minutes here: https://lists.w3.org/Archives/Public/www-style/2017Mar/0037.html

Is there any additional feedback at this point?

The Working Group just discussed column spanning issues, and agreed to the following resolutions:

• RESOLVED: Column span applies to elements lower than the first level of descendants as long as it's part of the same formatting context.

The Working Group just discussed Background and borders for spanners, and agreed to the following resolutions:

• RESOLUTION: If the fragment before the spanner is empty, nothing special happens; the top mbp is above the header, and it's just an empty fragment.

The CSS Working Group just discussed column-span, and agreed to the following:

• RESOLVED: Clarify the spec using the notion that this is an out of flow that leaves a forced break behind

RESOLVED: Clarify the spec using the notion that this is an out of flow that leaves a forced break behind

"Out of flow" is probably not the right term to use in the spec though, since that might mislead people to think that it's "positioned", which means it's an absolute containing block, paints in a separate layer from in-flow content etc. which would be wrong, IMO.

Are floats necessarily positioned?

No, but floats also paint in a separate layer from in-flow content (step 5).

I think it would be more accurate if the spec introduced a concept of abstract "rows" to describe this. The spec can then say that column-span:all introduces a forced "row break" before and after it. Normal fragmentation rules then describes the rest I think. So you get something like this:

<columnset>
  <row><column/><column/>...</row>
  <row><column-span:all/></row>
  <row><column/><column/>...</row>
</columnset>

See also my multicol model suggestion here:
#2203 (comment)

Yeah, I completely agree that @mstensho 's model in that comment is the right one, and very strongly advocate that it be folded into the spec, as the CSSWG resolved. The only question here is about how we capture the way that it's taken out of the columns' fragmentation flow and formatted as a sibling of the column row boxes. Initially the idea was to treat it as a block-in-inline split situation; however dbaron was arguing it should be out-of-flow because then there doesn't need to be some abstract tree structure representing all of the boxes between it and the multi-column container, since that's complicated to implement. I think either concept is good enough, but yes, we should be clear about the effect on the painting order. Probably column spanners should interleave with the row boxes the same as other in-flow content; I guess its an interesting question whether they should form a pseudo-stacking context (like inline blocks) or behave like regular block boxes.

@MatsPalmgren @emilio Floats aren't “positioned” since that's not a defined CSS term... They are out-of-flow, and they are not absolutely-positioned.

We have already resolved to add @mstensho's model. I just haven't done the edits yet.

The issue with the concept of rows is how that impacts our intention to enable multicol overflow in the block dimension for continuous contexts. That's something I'm very keen to move forward on in Level 2 as it would actually make multicol useful on the web.

Personally, I think that describing the spanner as out of flow makes a lot of sense, it's something I could teach to people. It needs describing properly in the specification in terms of what the impact is. Now I'm less busy I'll have a crack at that.

@fantasai Right, my point was that out-of-flow is not anything exclusive to positioned elements. Also I didn't realize that floats and abspos are completely exclusive (if you specify both, float becomes none at computed value time).

So I'm working on editing in @mstensho's model along with this resolution. What I have is a problem of naming things.

We resolved to name the element which has column-count or column-width applied to it the Multi-column/Multicol Container. This means it is the same as a Flex Container or Grid Container so makes sense.

In @mstensho's model we end up with an anonymous wrapper, which he has referred to as a multicol container. Initially I thought we could refer to this as "rows", but having discussed this in SF with @frivoal we are both keen to keep rows for the scenario when we allow for overflow in the block dimension, which would create (in the mind of the author) very definite rows of column boxes, which could themselves contain spanners etc. I think row should be maintained for this use.

So, what do we name the anonymous wrapper? We could use multicol wrapper. In the flexbox spec we have flex lines, so multicol lines? Does anyone have a better suggestion?

Well, it is something that contains one or more rows with columns (and nothing else). So, why not just simply "row container"? I don't think I quite understood the reservation against using the term "row" here, since that's the term that the spec already uses for this.

What would we then name the rows created by block overflow, given that they themselves could contain row containers of column boxes along with spanners? We've changed other terminology in this spec already (multicol container), I'd like to make sure we aren't causing difficulties with a highly likely future addition.

"rows created by block overflow" - is this somewhere in the overflow spec, or what exactly is this about?

as mentioned above:

"The issue with the concept of rows is how that impacts our intention to enable multicol overflow in the block dimension for continuous contexts. That's something I'm very keen to move forward on in Level 2 as it would actually make multicol useful on the web."

Would this be a mode where you effectively (kind of) want to pretend that we have columns:1 and a definite block size? In that case, overflowing content will be placed into additional fragmentainers, wouldn't it? No rows involved, as far as I can understand.

But if this in a draft somewhere, maybe reading that could enlighten me.

This isn't in a draft anywhere yet (although I have some private notes scattered around), but we've been discussing the possibility of introducing some kind of switch to decide what to do with excess content when you've filled you allotted (max) width and (max) height. It'd allow authors to pick between the current behavior (excess content goes to overflow columns appended in the inline progression direction), and a different one where excess content would append a second "row" to the multi-column, in the block progression direction (possibly based on some kind of column-height property rather than the height property, so that it could consume additional layout space). So, you could have 3 (or whatever) columns, of 400px (or whatever) height, and we'd they'd be full, you'd get another 3 x 400px set of columns below them.

article {
  columns: 3 20em;
  column-height: 80vh;
  column-which-way-do-I-go-when-I-am-full: block;
  gap: 1em 2em;
}

******* ******* ******* 
SPANNER-SPANNER-SPANNER
******* ******* *******
******* ******* *******
******* ******* *******


******* ******* ******* 
******* ******* *******
******* ******* *******
******* ******* *******
******* ******* *******


******* ******* *******
******* ******* *******
SPANNER-SPANNER-SPANNER
******* ******* *******
******* ******* **

Regardless of exactly how that ends up working, something along these lines has been brought up multiple times, and it'd be good to avoid painting ourselves into a corner.

In that sort of model, we have two things that could reasonably called "rows":

1. A set of column boxes that go above (or below) a column spanner
2. The box you append in the block direction, which itself contains a bunch of column boxes, possibly horizontally separated by more spanners

******* ******* *******   <-- this is a (1)        |
SPANNER-SPANNER-SPANNER                            |
******* ******* *******   <-- this is another (1)  | <-- This is a (2)
******* ******* *******   |                        |
******* ******* *******   |                        |


******* ******* *******   <-- this is another (1)  | <-- This is another (2)
******* ******* *******   |                        |
******* ******* *******   |                        |
******* ******* *******   |                        |
******* ******* *******   |                        |


******* ******* *******   <-- this is another (1)  |
******* ******* *******   |                        |
SPANNER-SPANNER-SPANNER                            | <-- This is another (2)
******* ******* *******   <-- this is another (1)  |
******* ******* **        |                        |

To some degree, for the current issue, we can do whatever we want, because we're only introducing internal terminology that won't be visible through any property/value/API..., but if we could get sensible names from the get go, that'd be great.

At first, I'd tend to call (1) "rows", and to call (2) "row groups".

However, if we want to make things like the row-gap property apply to multicol eventually, it feels like it'd be a lot more appropriate for it to apply to the spaces between the (2)s than between the (1)s. Same if we want to add a column-row-count, or more of that sort of things.

So if we call (2) "rows", what do we call (1)? "lines" for the analogy with flexbox lines? "group"? "set"? "line" probably feels the best suggestion so far to me, I'm not sure.

I really would like to reserve rows for (2) in @frivoal's example above. I think that it is what authors will tend to think of as a row, and row-gap would make sense to be between these rows and not around spanners.

It seems that this other box, needed for the model we are trying to introduce, probably isn't something authors will worry about. I also like lines, it seems to work as I've been noodling at drafting this.

Thanks. Now I get it! :)
This kind of feels like nested fragmentation, in that what you refer to as (2), feels pretty much like an outer fragmentainer, that contains rows (with columns (fragmentainers)) and spanners.

Would it make sense to spec it in such a manner? We might still want some terminology for the outer fragmentation context. The fragmentainers it generates aren't columns, and not quite pages, either. Or?

This is similar printing a multicol container that gets split into multiple pages, or, even more similar to how Presto (Opera) did paged overflow, where you could also get two fragmentation contexts established by just one element. There used to be some documentation somewhere at opera.com for this, but I can't find it anymore, but essentially:

<div style="columns:3; overflow:-o-paged-y; height:80vh;">...</div>

The DIV would establish an outer (paged) fragmentation context and an inner (multicol) fragmentation context. We'd fill columns in the inline direction until we run out of space, and then we continue to the next page and establish a new row of columns there. And so on.

While that solution was less flexible than what you're presenting here (for one, the Presto solution forces you to put everything inside a scrollable container), it's essentially the same, isn't it?

But does multicol necessarily have to be a part of this?

E.g.:

<div style="column-height:4em; gap:1em; line-height:1em; border:solid;">
  line1<br>
  line2<br>
  line3<br>
  line4<br>
  line5<br>
  line6<br>
</div>

(pretty obvious that the property name 'column-height' wouldn't be ideal, though)

+-----------------------+
| line1                 |
| line2                 |
| line3                 |
| line4                 |
|                       |
| line5                 |
| line6                 |
+-----------------------+

We may call the first fragmentainer (with lines 1-4) one row, and the second fragmentainer (with lines 5-6) another row. But they no longer have anything to do with columns. So there'd be no naming conflict. We have table rows, column rows, and this new thing, that's a different kind of rows (inside a still unnamed type of fragmentation context) - related to fragmentation, but not to multicol. And if we want to support row-gap, that would apply to the outer fragmentation context, and not to column rows created before/after spanners.

Warning: this is a bit of a side track, but it's kind of useful to discuss why the thing discussed in #1072 (comment) is on the horizon if we want to use its probable existence as a justification for how we should name things.

What you're describing in #1072 (comment) is different mechanism that we're also of exploring, and which does have with some degree of lineage to the opera paged overflow you mentioned. A very rough outline of how that might work is in https://drafts.csswg.org/css-overflow-4/#fragmentation, and clearer details about first steps towards that are in https://drafts.csswg.org/css-overflow-3/#fragmentation. In this, max-lines plays the role for which you thought (and I agree) that column-height would be a poor name, and the continue property is responsible for turning the div into a (repeating) fragmentainer.

However, while this is more powerful because it can apply not just to multicol, but also to all sorts of layout systems, it's also way more complicated than something specific to multicol. The thing I described in #1072 (comment) wouldn't really need to be thought of as nested fragmentainers: the columns are the only fragmenting things, and the only question is where we place them. They're either arranged in 1d as today, or this proposes laying them out in 2d, but from the point of view of the content in it, there's no nesting going on (spanners make that a bit more messy, but not that much more messy, so I won't get into that here).

Somewhere around 2012 (at least at the Hamburg F2F), we briefly considered this, and similarly to the comment you made above, though that it wasn't needed because we could use some kind of nested fragmentation on demand, or css-regions (which were still a contender back then). But time has since proven that going that way was much harder, and multicol is still without a reasonable solution for being useful in continuous medium.

Since then, we have also developed, via flexbox, grid, and css-alignment a set of concepts and properties that would readily apply to this kind of 2d layout of columns.

I do expect that we'll eventually solve the problem of generic on-demand fragmentation (and I'll be pushing for it), but I now want the multicol-specific thing as well, and hope to push for it soon. I believe that quite a few people are interested as well.

Of course I can't know before we do it that it'll work out, but if we can pick internal terminology that doesn't make that project more confusing than necessary, that'd be good.

@mstensho I made a first pass at dealing with this, in the PR #3999