- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Oct 2020 14:15:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `containing block of column spanners`, and agreed to the following: * `RESOLVED: CB chain goes straight from spanner to the multicol container` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: containing block of column spanners<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/5612<br> <TabAtkins> rachelandrew: Good details in the issue<br> <TabAtkins> rachelandrew: We dont' have interop<br> <TabAtkins> rachelandrew: If you have abspos in a column spanner, not clear the what containing block should be<br> <TabAtkins> rachelandrew: Three different options currently<br> <TabAtkins> rachelandrew: In the issue it came down that probably either #2 or #3 would be most likely, either viewport (WebKit and EdgeHTML) or the column spanner itself<br> <Rossen_> q?<br> <TabAtkins> rachelandrew: I suspect authors would assume the spanner is the containing block, or at least would want that ability<br> <TabAtkins> rachelandrew: Option 1 is probablematic anyway<br> <TabAtkins> rachelandrew: In gecko it would be harder to implement option 2<br> <TabAtkins> rachelandrew: So it's between 2 and 3, viewport and spanner<br> <Rossen_> q<br> <Rossen_> q+<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I think option 3 is a little weird - it doesn't ahve relpos<br> <Rossen_> q-<br> <TabAtkins> fantasai: And so unless there's something particularly interesting happening on, like transform, elements dont' trap abspos unless they're relpos<br> <TabAtkins> fantasai: So I'm totally fine with skipping the fragmenting grandparent<br> <TabAtkins> fantasai: But I think it woudl be weird to stop at the spanner and not go up to the multicol itself if *that* has relpos<br> <TabAtkins> fantasai: and otherwise fall up to the ICB<br> <TabAtkins> iank_: Chrome broadly agrees with that<br> <TabAtkins> florian: I was thinking as well<br> <TabAtkins> Rossen_: EdgeHTML as well, the spanner is nothing special, you just walk the ancestor chain as normal until you find a positioned element<br> <TabAtkins> florian: That's a little different from what fantasai described, i think<br> <TabAtkins> florian: If you have a relpos parent of the spanner, if you go by ancestry in the tree, that would capture the abspos<br> <TabAtkins> florian: elika was talkinga bout skipping past that straight to the multicol, to avoid fragmentation issues<br> <TabAtkins> iank_: Part of the problem is that the spanner isn't really positioned in flow, it's positioned by the multicol, so option 2 is kinda in that direction<br> <TabAtkins> fantasai: I think from an author's perspective, yeah, skipping from spanner to multicol would make the most sense since the spanner isn't fragmented<br> <TYLin> q+<br> <TabAtkins> fantasai: That's option 2, yeah; option 3 makes the spanner the containing block regardless of its 'position'<br> <TabAtkins> fantasai: So the CB chain should go spanner -> multicol -> normal ancestry from there<br> <TabAtkins> florian: I'm confused, option 2 says viewport<br> <TabAtkins> astearns: if you read the text it goes into more detail<br> <astearns> ack TYLin<br> <TabAtkins> fantasai: there's no relpos in the example, that's why it goes up to viewport<br> <astearns> ack emilio<br> <TabAtkins> TYLin: I think option 2 is best, Gecko is buggy in edge cases<br> <TabAtkins> astearns: So it sounds like option 2 has consensus, cb chain goes spanner -> multicol and then normal from there<br> <TabAtkins> astearns: objections?<br> <chris> q+<br> <TabAtkins> RESOLVED: CB chain goes straight from spanner to the multicol container<br> <astearns> ack chris<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5612#issuecomment-715369246 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 October 2020 14:15:13 UTC