-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-writing-modes-4][css-flexbox-1] Orthogonal column flex containers #4221
Comments
@tabatkins flexbox isn't REC yet, so it's not a dependency of writing-modes-3. Can we tag this against writing-mode level 4, or is this something that must be fixed in L3? |
I don't care what it's tagged to, but if we do come up with something for this soonish, we should make the edits in WM3 as well. ^_^ |
Retagged to WM4, made L3 undefined in this aspect (so that it's only defining sizing on CSS2.1 display types). |
Spec for WM4: https://www.w3.org/TR/css-writing-modes-4/#orthogonal-layout The original thought behind passing infinite available space through vs using the viewport as a cap:
So there are two interesting questions here:
|
The CSS Working Group just discussed
The full IRC log of that discussion<emilio> topic: Orthogonal column flex containers<TabAtkins> quote from the issue: If you have a column flexbox that is orthogonal to its parent, and whose flex items are parallel (not orthogonal), per spec we pass the parent's infinite available block size to the flexbox's inline size, which then passes to the flex item, giving the flex item an infinite available inline size without the flex item itself being orthogonal. <emilio> fantasai: so originally if you have a horizontal document with a section with vertical text, and that box is a block container, we apply this implicit height on it so that the line doesn't become super-high <TabAtkins> <!DOCTYPE html> <TabAtkins> <div style="display: flex; writing-mode: vertical-rl; flex-flow: column; border: 40px double;"> <TabAtkins> <span>foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo </span> <TabAtkins> <span>foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo </span> <TabAtkins> <TabAtkins> <style> <TabAtkins> span { border: orange solid 40px;; } <emilio> ... [ok, what TabAtkins just pasted :-)] <emilio> fantasai: so in flex and grid you have a bunch of items so you don't really have this need to restrict the height of the flex container <emilio> ... you could just allow it to get tall <emilio> ... but it's kinda simple when you're setting up the orthogonal flow to apply the restriction without looking at whether its a block <emilio> ... so the question is do we want to cap the height of the orthogonal box, or the height of orthogonal blocks? <emilio> ... the other question is whether we do want to change behaviors if we choose the later <emilio> TabAtkins: at least impls are interoperable on clamping flex containers <emilio> ... the flex container gets the ICB clamping as is currently spec'd <emilio> florian: I suspect there's no reason to change, the viewport size is an arbitrary measure <emilio> ... if we have interop I don't see a huge motivation for changing <emilio> TabAtkins: that was our thoughts as well <emilio> ... we should probably spec the interop <emilio> ... probably some small tweaks in flexbox+writing-modes <emilio> fantasai: I think mostly writing-modes <emilio> RESOLUTION: Specify current behavior (clamp the orthogonal box, not propagate the clamping to block children) <emilio> fantasai: the most common situation where I'd expect this to show up is if you have a vertical-text table (because you can put more content) <emilio> ... if you have a vertical-wm table in an horizontal document you prevent the table from growing <emilio> florian: only when max-content > icb height, not min-content right? <emilio> fantasai: right, is shrink-to-fit on the viewport |
…the closest block container descendant, matching implementations. #4221
If you have a column flexbox that is orthogonal to its parent, and whose flex items are parallel (not orthogonal), per spec we pass the parent's infinite available block size to the flexbox's inline size, which then passes to the flex item, giving the flex item an infinite available inline size without the flex item itself being orthogonal.
Implementations don't seem to do this. They apply the ICB clamping to the flexbox itself, then the flex items just lay out into that (finite, definite) size.
Assuming this is what we want, we'll need to tweak Flexbox's wording a little bit, and possibly Writing Modes to match.
Repro:
The text was updated successfully, but these errors were encountered: