Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[css-writing-modes-4][css-flexbox-1] Orthogonal column flex containers #4221

Closed
tabatkins opened this issue Aug 19, 2019 · 5 comments
Closed

[css-writing-modes-4][css-flexbox-1] Orthogonal column flex containers #4221

tabatkins opened this issue Aug 19, 2019 · 5 comments
Labels
Closed Accepted by CSSWG Resolution css-flexbox-1 Current Work css-writing-modes-4 Current Work
Milestone
APAC VF2F-2021-07-29

Comments

@tabatkins
Copy link
Member

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:

<!DOCTYPE html>
<div style="display: flex; writing-mode: vertical-rl; flex-flow: column; border: 40px double;">
 <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>
 <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>

<style>
span { border: orange solid 40px;; }
@frivoal
Copy link
Collaborator

frivoal commented Aug 21, 2019

@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?

@tabatkins
Copy link
Member Author

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. ^_^

@fantasai fantasai changed the title [css-writing-modes-3][css-flexbox-1] Orthogonal column flex containers [css-writing-modes-4][css-flexbox-1] Orthogonal column flex containers Aug 22, 2019
@fantasai
Copy link
Collaborator

Retagged to WM4, made L3 undefined in this aspect (so that it's only defining sizing on CSS2.1 display types).

@fantasai
Copy link
Collaborator

fantasai commented Jun 10, 2021 •
edited
Loading

Spec for WM4: https://www.w3.org/TR/css-writing-modes-4/#orthogonal-layout
Implementations, as Tab mentioned, cap the orthogonal flex/grid container itself rather than passing infinity through and letting descendant block containers cap.

The original thought behind passing infinite available space through vs using the viewport as a cap:

  • For lines of text, laying out as max-content is problematic because it's hard to read such text. It's much, much more useful to wrap it to the viewport size.
  • For flex and grid, laying out at max-content isn't as much of a problem because you're not reading line by line and having to scroll up and down for each line in the same way. (But the flex items should cap at the viewport size if they contain text, for the reason above.)

So there are two interesting questions here:

  • Which do we think is the better behavior for CSS: capping the orthogonal item itself, or capping only block containers?
  • If we think it's better to not cap orthogonal flex and grid containers themselves (but rather the block containers within them), is it worth asking implementations to change?

@astearns astearns added this to the APAC VF2F-2021-07-29 milestone Jul 24, 2021
@astearns astearns modified the milestones: APAC VF2F-2021-07-29, EUR VF2F-2021-04-06, EUR VF2F-2021-07-27 Jul 24, 2021
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Orthogonal column flex containers, and agreed to the following:

  • RESOLUTION: Specify current behavior (clamp the orthogonal box, not propagate the clamping to block children)
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

fantasai added a commit that referenced this issue Aug 11, 2021
@fantasai
[css-writing-modes-4] Apply ICB clamping on the orthogonal flow, not …
de44f98 
…the closest block container descendant, matching implementations. #4221
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-flexbox-1 Current Work css-writing-modes-4 Current Work
Projects
None yet
Milestone
APAC VF2F-2021-07-29
Development

No branches or pull requests
5 participants
@frivoal @tabatkins @fantasai @astearns @css-meeting-bot