- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Oct 2018 10:21:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Improve column-fill and make it backward-compatible`. <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: Improve column-fill and make it backward-compatible<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/3224<br> <gregwhitworth> fantasai: we should chat during a break<br> <fantasai> kk :)<br> <heycam> rachelandrew: this was recently raised by Morten Stenshorn, basically saying that we seem toh ave interop with chrome/edge/webkit column-fill:auto about balancing<br> <heycam> ... when block-size is unconstrained, balancing is forced<br> <heycam> ... it says Gecko doesn't force balancing in this case<br> <heycam> ... and Gecko appears to follow what's now in the spec<br> <heycam> ... I did some digging, the spec was changed in 2012 by Hakon, commented out some text, which led to this interop issue<br> <heycam> ... Morten is suggesting that we should fix the new spec and make it backwards compat, so column-fill:auto forces balancing if the block size is unconstrained<br> <heycam> florian: another consideration here is I don't know whether we only do this for compat reasons, or if it's use case driven<br> <heycam> ... the issue was discovered by trying to fix one of the problems of what the interop impls do<br> <heycam> ... column-fill auto is supposed to say don't balance<br> <heycam> ... fill the first column as much as you can<br> <heycam> ... except it doesn't do that unless you contrain the height<br> <heycam> ... if you're in a grid, or if you have a min-height, maybe you do want to start not balancing and take the min-height into consideration<br> <heycam> ... height was not fixed to a number, but it is contrained is size<br> <heycam> ... so we're trying to patch our way out of that<br> <heycam> ... if we start with the Gecko behavior, filling as much as you can, then wrap, that solves that problem<br> <heycam> ... the fact that we have mostly interop, not full interop, we can decide<br> <heycam> rachelandrew: I've run into the issue of wanting to have a min-height<br> <heycam> ... if you have a small amount of text, andi t's going to fragment into 3 columns, weithout being able to do the min-height thing, you get short bits of text<br> <heycam> ... but if you want to say make it at least this height<br> <heycam> ... that behavior is useful<br> <heycam> florian: if you have the Gecko behavior as a starting point, you would use max-height instead<br> <heycam> ... when it reaches that it starts wrapping<br> <heycam> rachelandrew: certainly a use case for that<br> <heycam> dbaron: the issue you raised about grid reminds me of an issue we talked on last week's telcon<br> <heycam> ... seems like the same thing<br> <heycam> fantasai: I think morten was suggesting it balances only when it's uncontrained<br> <heycam> ... if you have a min/max height that's a type of contraint<br> <heycam> florian: it's not what they currently do<br> <heycam> ... if min/max/height are all auto, but you are contrained by being a grid item...?<br> <heycam> fantasai: that's contrained<br> <heycam> florian: that would work for me<br> <heycam> fantasai: you could say if height is max-content or equivalent in behavior, then we consider that unconstrained<br> <heycam> ... and it balances<br> <heycam> rachelandrew: that makes sense<br> <heycam> florian: seems to me that would work, and not be too disruptive, I'm not convinced it's more useful<br> <heycam> ... are we trying to minimize the cost of changing impls?<br> <heycam> florian: that plus web compat plus the idea that when you give something an auto height, it's supposed to fit it to content<br> <heycam> ... balancing as part of that kind of makes sense<br> <heycam> ... Morten is also suggesting "don't ever balance" should get its own value<br> <heycam> s/... Morten/fantasai: /<br> <heycam> fantasai: the proposal is to accept Morten's suggestion that column-fill:auto does balance only when the height is uncosntrained, which emanse the beahviour is equivalent to min-content<br> <heycam> florian: I think I agree, just confused about min vs max-content<br> <heycam> fantasai: I think they're defined to be the same thing?<br> <heycam> florian: this is one of hte cases where they might want to mean a different thing<br> <heycam> ... the min would reasonably be the wrapped size, and the max be the unwrapped size<br> <heycam> ... and it's the unwrapped size that makes sense here<br> <heycam> dbaron: I think this is probably going in a direction that would be too vague<br> <heycam> ... so not worth getting to that detail<br> <heycam> ... if you want a proposal for switching, it needs to be clear about figuring out which case you're in<br> <heycam> ... the way you just defined it there are still ambiguous cases<br> <heycam> ... if you ahve a min/max height that probably isn't going to apply in your situation but might in another ?<br> <heycam> ... if you're in a block where you have this much content, and you have a max-height that's way down there, ...<br> <heycam> fantasai: ??<br> <heycam> dbaron: there are a pile of situations like this<br> <heycam> rachelandrew: I'd be happy to have a go at writing these situations down<br> <heycam> florian: just to be clear the reason we're going after the Gecko behavior is to minimize the cost of changing?<br> <heycam> ... or any other reason?<br> <heycam> fantasai: it's called auto...<br> <heycam> rachelandrew: I'll bring these back to the group after writing it up<br> <heycam> fantasai: current proposal, if there's no min/max constraint, and the height is specified to be an automatic size, it's equivalent to min-content<br> <fantasai> s/size, it's/size that's/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3224#issuecomment-431780623 using your GitHub account
Received on Monday, 22 October 2018 10:21:35 UTC