- From: Roman Komarov via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 10:08:22 +0000
- To: public-css-archive@w3.org
I agree with @frivoal that using `(max-)height`/`block-size` for this feels weird, especially when you start thinking about stuff like `calc-size()` and animating the block-size of the columns’ container with `interpolate-size: allow-keywords`. And yes, “If it doesn't have scrollable overflow, the overflow will just overlap with subsequent content and look bad.” is something we'd want to avoid, and the case with the `overflow` is a good one, as I don't think we want the element to have different outer dimensions based on if it is `visible` or `auto`, for example. - - - There is another thing that I would like to throw in. It could be totally to be something for the future level of the spec, but I felt that this is something that also points to using a different property to control the block direction rather than the `height`/`block-size`. It is that there might be cases where you'd want each row created this way to be _different_. If we'd want to control this via something similar to `grid-template-rows`, where we could define either a static value (as described now), or a pattern that would include `repeat()`, it could unlock some more interesting layouts. If we think about the overflow in block direction as “pages” and think about print, then this is not a use case that comes to mind, but when translated to a web page, having dynamic rows can make more sense. Although, maybe at this point we're going closer to regions :) But I wanted to mention this possible extension as something that would be harder to do with just `height`/`block-size`. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2621199351 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 10:08:23 UTC