W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

[csswg-drafts] [css-multicol] Containing block of column spanners (#5612)

From: Alison Maher via GitHub <sysbot+gh@w3.org>
Date: Tue, 13 Oct 2020 16:57:33 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-720542668-1602608252-sysbot+gh@w3.org>
alisonmaher has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-multicol] Containing block of column spanners ==
In the following example, we have an abpos element nested inside a column [spanner](https://drafts.csswg.org/css-multicol/#spanner). In this case, it becomes unclear what the containing block of the abspos element should be:

```
  <div style="columns:2; column-gap:0;">
    <div style="position:relative;">
      <div style="break-inside:avoid; height:50px;"></div>
      <div style="height:10px;"></div>
      <div style="column-span:all; width:100px; height:100px; background:red;">
	<div id="abs" style="position:absolute; top:0; width:100px; height:100px; background:green;"></div>
      </div>
    </div>
  </div>
```
The confusion around this case stems from the fact that column spanners are taken [out of the normal flow](https://drafts.csswg.org/css-multicol/#spanner) of the column and are positioned as children of the mutli-column container. The question then is: what should we consider to be the containing block of the abspos in the example above?

Based on the varying behavior from browser implementations, we have a few options:

### Option 1: The containing block should be the relpos ancestor
**Browser support**: Blink
**Implications**: Handling the abspos this way might make the most sense at first glance, but determining when to fragment the abspos can become messy. If the OOF is within the margin box of the column spanner, don't fragment since the spanner doesn't fragment. Otherwise, fragment, unless we're above or below the multicol container. Given this, this option becomes difficult to implement and results in strange behavior when fragmenting.

### Option 2: The containing block should be the viewport
**Browser support**: Webkit, EdgeHTML
**Implications**: This option is straightforward from an implementation perspective and is relatively intuitive. The spanner is taken out-of-flow, so don't consider column content when determining the containing block. However, if we decide that the viewport is the correct containing block because the column spanner is out-of-flow, then given that floats are also [out-of-flow](https://drafts.csswg.org/css-display-3/#out-of-flow ), we should consider similar scenarios for floating elements.

For example:
```
  <span style="position:relative;">
    <div style="display:inline-block; width:50px; height:100px; background:red;"></div>
    <div style="float:left; width:50px; height:100px; background:green;">
      <div style="position:absolute; left:0; width:50px; height:100px; background:green;"></div>
    </div>
  </span>
```
In this case, all browser implementations currently treat the relpos ancestor as the containing block of the abspos descendant. If we are to go with option 2, should we still treat the relpos ancestor as the containing block, even though floats are also out-of-flow?

### Option 3: The containing block should be the column spanner
**Browser support**: Gecko
**Implications**: This option is straightforward from an implementation perspective but is not intuitive based on the definition of a [containing block](https://drafts.csswg.org/css-display-3/#containing-block).

My initial preference is to go with option 2 given that it is intuitive and straightforward to implement. However, as mentioned, if we are to go this route, we will likely need to consider if this behavior applies to floats, as well.

(+@mstensho)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5612 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 October 2020 16:57:35 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:20 UTC