[css-multicol] how does absolute positioning work in a containing block that was split by a column-span?

[dbaron]

I'm filing this based on a discussion I just had with @neerjapancholi. It is related to #1072.

It's not clear to me from the spec how absolute positioning works when the containing block for absolutely positioned elements is split by a column-span.

In particular, if you have markup like:

<div style="column-count: 3">
  <div style="position: relative">
    ... position A ...
    <h2 style="column-span: all">... position B...</h2>
    ... position C ...
  </div>
</div>

then it should be clear what the absolute containing block is for elements at position A, at position B, or at position C. (Consider use of both top and bottom.)

I haven't tested what current implementations do.

One possibility is that they act as though the div with style position:relative was split into three parts, and elements at positions A, B, and C position relative to the appropriate part. Another is that behavior happens at positions A and C, but elements at position B fall back to the next absolute containing block outside of the outermost div.

[Loirooriol]

Has the CSSWG already decided what should happen in the simpler case of a multicol not split by a column-span?

[rachelandrew]

This doesn't appear to be specified. So I built an example to look at this: https://codepen.io/rachelandrew/pen/rYeagj?editors=1100

Currently it doesn't seem to make any difference if there is a spanner or not, and we don't have interop.

Firefox 58 will always act as if the abspos items are in the first column, so that is the containing block. If the items are positioned right, it puts them at the right hand edge of that column. Stacking them up.

Chrome 64 will act as if the first column is the containing block if items are positioned top, and the last column if items are positioned bottom. So left and right are the relative to that column, again stacked up.

Safari 11 acts like Chrome, except for the item that is inside the spanner. It seems to take context from the viewport.

Edge 16 matches Safari.

I'd be interested in anyone's thoughts/use cases as to what would be the best way to resolve this.

[css-meeting-bot]

The Working Group just discussed How does abspos work in a containing block split by a spanner, and agreed to the following resolutions:

• RESOLVED: Behavior already defined in CSS Fragmentation; file any issues there.

The full IRC log of that discussion

<TabAtkins> Topic: How does abspos work in a containing block split by a spanner
<TabAtkins> rachelandrew: It's not clear how abspos works when the containing block is split by a spanner
<TabAtkins> rachelandrew: I built an exmaple, we dont' ahve interop, it's all very strange
<TabAtkins> rachelandrew: How should we resolve this?
<fantasai> github: https://github.com//issues/1894
<fantasai> TabAtkins: My first instinct is that the contianing block is generated by the fragments
<TabAtkins> dbaron: that's the easiest to implement for us, and what we were planning to do unless someone disagreed
<TabAtkins> Rossen: It's not what we do
<TabAtkins> iank_: We were looking at multicol and abspos; dunno if webcompatible, but would be nice to have the fragment that contains the abspos do it.
<TabAtkins> dbaron: What's hard about that is the only case where you don't know the abspos cb at the tim eyou construct it.
<fantasai> TabAtkins: Situation ian was talkinga bout erlier, a large containing block at the end of a column, part of it is at the top of the next column
<fantasai> TabAtkins: what happens there?
<Rossen> https://codepen.io/rachelandrew/pen/rYeagj?editors=1100
<fantasai> dbaron: That happens during fragmentation, and this happens during frame construction
<fantasai> dbaron: fragmentation happens during layout
<TabAtkins> TabAtkins: CSS doesn't treat those two separately...
<TabAtkins> TabAtkins: per spec
<TabAtkins> dbaron: In ours you have to duplicate the logic then, in each place
<TabAtkins> iank_: Ah, we do some layout.
<TabAtkins> dbaron: The other two options are (1) always use first fragment, (2) union the fragments
<TabAtkins> TabAtkins: Dont' union, that's bad
<TabAtkins> dbaron: I think the "per fragment" is the sanest thing. Did the tests show something else?
<TabAtkins> rachelandrew: I think authors would prefer what grid does, unsure what tests show
<TabAtkins> rachelandrew: In grid, if you have an abspos grid item, the grid area generates the containing block
<TabAtkins> rachelandrew: Unsure about usage in multicol right now
<TabAtkins> TabAtkins: (because multicol sucks on the web)
<TabAtkins> iank_: Is there use-cases for wanting an abspos to span across a spanner?
<TabAtkins> dbaron: There's another set of issues we haven't resolved yet; if you have an abspos whose cb is part of a pagination sequence, and it has a large negative or positive top that pushes it up or down into a different fragment, i don't think we've defined that yet.
<TabAtkins> iank_: It would be nice if a box has fragmented, and the abspos is in that fragment, we consider that fragment as the cb
<TabAtkins> fantasai: What you want is that if you have a page in screen media and it's in abspos, you want it to paginate in a sane way, and you can't get that with this
<TabAtkins> fantasai: We want a page that is laid out with abspos to print out well for the user.
<TabAtkins> dbaron: The other model that gets you something in that direction is you consider the db to be the entire fragment chain
<florian> q+
<TabAtkins> TabAtkins: What's meant by that?
<TabAtkins> dbaron: Pretend all the fragmentes are together; top is relative to first frag, bottom is relative to last, etc...
<fantasai> fantasai: This is all defined in css-break-3
<TabAtkins> florian: Can I ask what we're trying to solve here? If we want to solve printing pages as they exist, I think Fragmenting gets it right; something else, what?
<TabAtkins> dbaron: Less about that, more figure out what engines should do for a feature that's alreayd been specced for a decade.
<TabAtkins> fantasai: I'm okay with that behavior (spanner causing the break) being different form the general fragmentation behavior. I think that's a weird case.
<TabAtkins> fantasai: IMportant to make regular fragmentation make sense.
<TabAtkins> dbaron: I think it makes sense to make this agree; I just didn't thinka bout that when I filed th eissue, because impl-wise it's separate in our code.
<TabAtkins> [dbaron draws an example]
<jensimmons> q-
<fantasai> There are three columns, split by a spanner
<fantasai> there's an element which starts in the second column above the spanner, then continues into the third column above the spanner, then finishes parway through the first column after the spanner
<TabAtkins> dbaron if an abspos is in the element, and you say "top:0; bottom:0", it'll start in the second column, span across the third, and across the first after the spanner.
<TabAtkins> rachelandrew: Are we happy to resolve on that behavior?
<TabAtkins> [general agreement]
<florian> q-
<TabAtkins> florian: I think most of these use-cases are best solved by page floats, not abspos, but if you have a use-case not solved, please bring it up
<TabAtkins> RESOLVED: Behavior already defined in CSS Fragmentation; file any issues there.

[rachelandrew]

Closing as this is defined in Fragmentation as resolved at the meeting. If anyone has additional concerns these should be raised against that spec.