https://drafts.csswg.org/css-multicol/#spanning-columns
In order to become a spanner, we just require that the column-span:all element otherwise participate in the formatting context established by the multicol container / columns.
#elm becomes a spanner here:
<div style="columns:2;">
<div>
<div id="elm" style="column-span:all;">
#elm does NOT become a spanner here:
<div style="columns:2;">
<div style="display:flow-root;">
<div id="elm" style="column-span:all;">
But what about this one:
<div style="columns:2;">
<div style="transform:rotate(45deg);">
<div id="elm" style="column-span:all;">
A transform root establishes a containing block for all descendants, according to https://drafts.csswg.org/css-transforms/#transform-rendering :
For elements whose layout is governed by the CSS box model, any value other than none for the transform property also causes the element to establish a containing block for all descendants.
It does seem strange to allow a column spanner to escape a containing block established by a transform ancestor. Yet, here's what the multicol spec says:
The containing block of the spanner is the multicol container itself. Consequently, in cases where the spanner itself does not establish a containing block for absolutely positioned boxes inside the spanner, their containing block chain skips directly to the multicol container (skipping any ancestors between the spanner and the multicol container).
Could we just change the multicol spec to require that there's nothing in the ancestry between the spanner candidate and the multicol container that establishes a containing block for fixed-positioned descendants? That would guard against transforms and filters (anything else?). Paint and layout containment are already fine, as they trigger creation of a new formatting context.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4