[css-multicol] How do elements between column-span and its multicol ancestor appear around the span

@tabatkins

The definition of column-span doesn't appear to say anything about what happens to the elements that are ancestors of the element with column-span: all but descendants of the "nearest multicol ancestor in the same block formatting context" (i.e., the element that establishes the columns being spanned).

What happens to the backgrounds, padding, borders, and margins of these elements where the column span interrupts them? Do they appear as though they were a block ancestor of the column-spanning element? (What if they were inline elements?) Does relative positioning on these elements apply to the column-spanning element? Transforms? etc.

This situation is in some ways analogous to the situation that happens when an inline contains a block, which is defined reasonably thoroughly in CSS Level 2, except that this situation is a bit more general since the ancestors being split can be either inlines or blocks, whereas in the block-in-inline situation the split ancestors are only inlines.

I'd note that failing to display the background of an ancestor behind the column-spanning element could violate accessibility expectations related to colors and backgrounds.

What do existing implementations do? (IIRC, Gecko is the last engine to implement column-span, which would have made me expect the spec to be in better shape than it appears to be.)

/cc @tabatkins @gregwhitworth @neerjapancholi

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:

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 -
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:

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.

@mstensho

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":

A set of column boxes that go above (or below) a column spanner
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.

@frivoal

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

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

Navigation Menu

Repository navigation

[css-multicol] How do elements between column-span and its multicol ancestor appear around the span #1072

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-multicol] How do elements between column-span and its multicol ancestor appear around the span #1072

Description

Activity

frivoal commented on Mar 4, 2017

frivoal commented on Mar 4, 2017

mstensho commented on Mar 6, 2017

astearns commented on Mar 8, 2017

neerjapancholi commented on Mar 20, 2017

frivoal commented on Mar 27, 2017

dbaron commented on Apr 5, 2017

neerjapancholi commented on Apr 6, 2017

dbaron commented on May 4, 2017

frivoal commented on May 4, 2017

frivoal commented on May 4, 2017

27 remaining items

rachelandrew commented on May 1, 2019

mstensho commented on May 1, 2019

rachelandrew commented on May 1, 2019

mstensho commented on May 1, 2019

rachelandrew commented on May 1, 2019

mstensho commented on May 1, 2019

frivoal commented on May 15, 2019

rachelandrew commented on May 15, 2019

mstensho commented on May 15, 2019

frivoal commented on May 15, 2019

rachelandrew commented on Jun 3, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions