W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2017

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Nov 2017 00:48:34 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-342673130-1510102111-sysbot+gh@w3.org>
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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: How does abspos work in a containing block split by a spanner<br>
&lt;TabAtkins> rachelandrew: It's not clear how abspos works when the containing block is split by a spanner<br>
&lt;TabAtkins> rachelandrew: I built an exmaple, we dont' ahve interop, it's all very strange<br>
&lt;TabAtkins> rachelandrew: How should we resolve this?<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/1894<br>
&lt;fantasai> TabAtkins: My first instinct is that the contianing block is generated by the fragments<br>
&lt;TabAtkins> dbaron: that's the easiest to implement for us, and what we were planning to do unless someone disagreed<br>
&lt;TabAtkins> Rossen: It's not what we do<br>
&lt;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.<br>
&lt;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.<br>
&lt;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<br>
&lt;fantasai> TabAtkins: what happens there?<br>
&lt;Rossen> https://codepen.io/rachelandrew/pen/rYeagj?editors=1100<br>
&lt;fantasai> dbaron: That happens during fragmentation, and this happens during frame construction<br>
&lt;fantasai> dbaron: fragmentation happens during layout<br>
&lt;TabAtkins> TabAtkins: CSS doesn't treat those two separately...<br>
&lt;TabAtkins> TabAtkins: per spec<br>
&lt;TabAtkins> dbaron: In ours you have to duplicate the logic then, in each place<br>
&lt;TabAtkins> iank_: Ah, we do some layout.<br>
&lt;TabAtkins> dbaron: The other two options are (1) always use first fragment, (2) union the fragments<br>
&lt;TabAtkins> TabAtkins: Dont' union, that's bad<br>
&lt;TabAtkins> dbaron: I think the "per fragment" is the sanest thing. Did the tests show something else?<br>
&lt;TabAtkins> rachelandrew: I think authors would prefer what grid does, unsure what tests show<br>
&lt;TabAtkins> rachelandrew: In grid, if you have an abspos grid item, the grid area generates the containing block<br>
&lt;TabAtkins> rachelandrew: Unsure about usage in multicol right now<br>
&lt;TabAtkins> TabAtkins: (because multicol sucks on the web)<br>
&lt;TabAtkins> iank_: Is there use-cases for wanting an abspos to span across a spanner?<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> fantasai: We want a page that is laid out with abspos to print out well for the user.<br>
&lt;TabAtkins> dbaron: The other model that gets you something in that direction is you consider the db to be the entire fragment chain<br>
&lt;florian> q+<br>
&lt;TabAtkins> TabAtkins: What's meant by that?<br>
&lt;TabAtkins> dbaron: Pretend all the fragmentes are together; top is relative to first frag, bottom is relative to last, etc...<br>
&lt;fantasai> fantasai: This is all defined in css-break-3<br>
&lt;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?<br>
&lt;TabAtkins> dbaron: Less about that, more figure out what engines should do for a feature that's alreayd been specced for a decade.<br>
&lt;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.<br>
&lt;TabAtkins> fantasai: IMportant to make regular fragmentation make sense.<br>
&lt;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.<br>
&lt;TabAtkins> [dbaron draws an example]<br>
&lt;jensimmons> q-<br>
&lt;fantasai> There are three columns, split by a spanner<br>
&lt;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<br>
&lt;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.<br>
&lt;TabAtkins> rachelandrew: Are we happy to resolve on that behavior?<br>
&lt;TabAtkins> [general agreement]<br>
&lt;florian> q-<br>
&lt;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<br>
&lt;TabAtkins> RESOLVED: Behavior already defined in CSS Fragmentation; file any issues there.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1894#issuecomment-342673130 using your GitHub account
Received on Wednesday, 8 November 2017 00:48:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 November 2017 00:48:44 UTC