- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 18:44:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-multicol] Do we need column-wrap as well as column-height`, and agreed to the following: * `RESOLVED: leave property in draft, add new default value of auto, and leave this issue open for now` <details><summary>The full IRC log of that discussion</summary> <florian> q+<br> <kbabbitt> rachelandrew: at last F2F, we resolved to star tspecifying overflow for multicol<br> <kbabbitt> ... with column-height set causing columns to wrap<br> <kbabbitt> ... morten's been implementing in Chrome<br> <kbabbitt> ... we feel quite strongly that we want to maintain column-wrap property as trigger<br> <kbabbitt> ... if we have column-wrap, you can set a column-height but not wrap columns and still have spare space in container<br> <kbabbitt> ... also other things we get<br> <bkardell> s/ star tspecifying/start specifying<br> <kbabbitt> ... next issue on agenda lets us use column-height to trigger multicol<br> <kbabbitt> ... if you have column-wrap as well, could have one column wrapping in block directoin<br> <kbabbitt> ... we think it's worth maintaining column-wrap property as trigger<br> <kbabbitt> ... if we don't, we might come back wanting to add these abilities<br> <bkardell> s/directoin/direction<br> <kbabbitt> ... asking for a resolution to make column-wrap remain a trigger<br> <kbabbitt> astearns: this is what spec currently has?<br> <kbabbitt> rachelandrew: that's what is in the draft but not what we resolved on<br> <kbabbitt> ... if you have a column-height and not enough space, suddenly you get wrapping<br> <astearns> ack florian<br> <kbabbitt> ... that could seem magical if not expected<br> <kbabbitt> florian: I don't have an issue with column-wrap<br> <kbabbitt> ... do have strong views on what its values and default should be<br> <kbabbitt> ... probably room for compromise<br> <kbabbitt> ... I think that it is a historical oddity that by default overflow columns are as they are<br> <kbabbitt> ... not so much that it's magical that column-height flips into weird mode<br> <kbabbitt> ... it's that other mode should not be the weird one<br> <kbabbitt> ... for compat reasons, either if you opt into it, or if we're in case that already exists, legacy behavior should remain<br> <kbabbitt> ... but if we have column-wrap, default value should be auto<br> <kbabbitt> ... if you don't set column-height, it does the same thing it always has<br> <kbabbitt> ... whether you want to opt into other behaviors, we can discuss that<br> <kbabbitt> ... I suspect it's possible given example that you set both column height and height of container and that you do want overflow in inline direction<br> <kbabbitt> ... but I don't think this will be typical<br> <kbabbitt> ... typical thing will be for things to go in block direction of document<br> <kbabbitt> ... I think it might also happen that you set the height of your container and don't set height of columns<br> <kbabbitt> ... so if you have too many they will be overflowing<br> <kbabbitt> ... but you'd rather have overflow in block direction than inline direction<br> <kbabbitt> rachelandrew: having opt in makes sense<br> <kbabbitt> florian: I do think default should be that , where we can, as soon as you constrain oclumn height, they overgflow in block direction<br> <kbabbitt> ... taht tells me default value is audo<br> <kbabbitt> ... taht was reqason I didn't want to introduce property, I thought default should be auto<br> <kbabbitt> rachelandrew: I think that's also where morten is going in his comments<br> <kbabbitt> ... that seems reasonable<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: mostly agree with florian<br> <kbabbitt> ... main question I have is, are there any use cases other than wanting shorter column-height that overflows to right, for having htis property exist?<br> <kbabbitt> ... doesn't seem like common case<br> <kbabbitt> ... reasonably intuitively solved with wrapper element<br> <florian> q+<br> <kbabbitt> ... in which case I don't see that the column-wrap propertu is adding much value<br> <bkardell> s/propertu/property<br> <kbabbitt> florian: don't have a strong answer for value of propertyu<br> <kbabbitt> ... but for property itself<br> <astearns> ack florian<br> <bkardell> s/propertyu/property<br> <kbabbitt> florian: use case of wanting columns to wrap but setting column-height to height of container<br> <kbabbitt> fantasai: in that case I suggest addding a keyword to column-height<br> <kbabbitt> ... stretch or auto, which sets to height of container<br> <kbabbitt> ... then we don't need new property<br> <kbabbitt> florian: from a use case point of view, could you wantr columns to overflow in block direction? I think so<br> <astearns> isn’t basic paginated epub-style layout the block direction case?<br> <kbabbitt> ... rachelandrew's use case: set ehight of container and height of column to something smaller use alignment to play with extra space?<br> <kbabbitt> rachelandrew: carousel use case<br> <kbabbitt> florian: interesting but lower priority, would rather deal with it later<br> <fantasai> astearns, depends on the reader, but yeah it's a common case<br> <kbabbitt> rachelandrew: starting with auto is reasonable<br> <kbabbitt> ... magical-ness of just doing this on height is also could cause unexpected things<br> <kbabbitt> florian: not so much magical doing it on height .we should have had it in block direction in the first place<br> <kbabbitt> ... so let's do it<br> <kbabbitt> ... for legacy reasons, cases that behave otherwise but we're stuck with that<br> <kbabbitt> ... should we have keyword in one case wrapper in the other? I don't find it weird<br> <kbabbitt> fantasai:[missed]<br> <kbabbitt> rachelandrew: we have flex-wrap. it maps to how existing things work<br> <kbabbitt> ... if we tie it to behjavior where we have height I think that limits us to things we might want to do in the future<br> <kbabbitt> ...having in the future ability to use alignment adds use cases<br> <bkardell> s/behjavior/behavior<br> <kbabbitt> ... things I see people do with multicol using inline direction overflow now, think it might be useful<br> <kbabbitt> ... I think it's cleaner to say ? makes it wrap<br> <kbabbitt> florian: regardless of single column use case we want alignment propertiers tyo work<br> <kbabbitt> ... distribute extra height through alignment properties<br> <kbabbitt> ...as long as they do work, having them work with single row of columns...sure<br> <kbabbitt> ... if you want column to overflow to right... dont think that's a good design in cases but maybe in carousel case it is<br> <kbabbitt> ... tiny part of system, opt in to something we have anyway<br> <kbabbitt> fantasai: can see argument for ? applying in multicol but ?? seems mostly useless<br> <bkardell> s/propertiers tyo/properties to<br> <kbabbitt> ... the column-wrap property isn't adding much to css<br> <kbabbitt> rachelandrew: helping it behave more like other things in css<br> <kbabbitt> ... use alignment properties similar to how they work in flexbox<br> <kbabbitt> ... we have enough stuff that behaves kind of weirdly<br> <kbabbitt> ... my initial take was to model close to flexbox<br> <kbabbitt> ... benefit to keepingthings like alignment mostly the same<br> <kbabbitt> ... extra propertyu doesn't seem lie a big dea<br> <kbabbitt> fantasai: in flexbox. align-content only works on ? flexboxes<br> <fantasai> s/?/multiline/<br> <fantasai> (although i don't think that was a good decision)<br> <kbabbitt> florian: my only sketch of set of peoprties opn multicol has thi sone<br> <kbabbitt> rachelandrew: think we should do it now and then it's sort of clear what ??<br> <kbabbitt> fantasai: I think we're arguing back and forth, should make a blog post with examples of these things and get more opinions<br> <kbabbitt> florian: right now ED has property with no auto value<br> <kbabbitt> ... would like to introduce auto as initial value<br> <kbabbitt> ... does traditional things if you don't specify column-height, does ?? if you do<br> <kbabbitt> ... if we decide later can change, would rather ED doesn't stay as it is currently<br> <kbabbitt> astearns: 2 people i room think we should have it, 1 who doesn't<br> <kbabbitt> ... I'm ok keeping it<br> <kbabbitt> fantasai: we can draft auto value into spec and ask do we need this property<br> <kbabbitt> ... try to get more feedback on it<br> <kbabbitt> ... think we should have it drafted<br> <TabAtkins> I agree with the 3-value auto/nowrap/wrap suggestion<br> <kbabbitt> astearns: proposed resolution is to leave property in draft, add new default value of auto, and leave this issue open for now<br> <kbabbitt> fantasai: put it in a note and ask people to comment<br> <kbabbitt> rachelandrew: I'll write a post and ask for comments but don't expect much<br> <kbabbitt> astearns: other commments?<br> <kbabbitt> astearns: objections?<br> <kizu> Once there is an experimental implementation, I will try it right away in all variations<br> <kbabbitt> RESOLVED: leave property in draft, add new default value of auto, and leave this issue open for now<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11754#issuecomment-2773412811 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 18:44:57 UTC