[css-flexbox-1] 9.2. Line Length Determination Issue #11392

gitspeaks · 2024-12-18T17:15:47Z

According to CSS Flexible Box Layout Module Level 1, 9.2. Line Length Determination (3)(C):

"If the used flex basis is content or depends on its available space, and the flex container is being sized under a min-content or max-content constraint (e.g. when performing automatic table layout [CSS21]), size the item under that constraint. The flex base size is the item’s resulting main size."

Problems:

It is unclear what constitutes a "used flex basis value that depends on its available space", as none seem relevant in this context aside from the value content.
When a used flex-basis value is derived from a percentage that is resolved against an indefinite containing block (e.g., the flex container in this case), the resulting used value is content.

References:

According to CSS Box Sizing Module Level 3:

"intrinsic sizing keywords such as max-content are indefinite"
According to CSS Flexible Box Layout Module Level 1, Section 7.2.3:

"percentage values of flex-basis are resolved against the flex item’s containing block (i.e. its flex container); and if that containing block’s size is indefinite, the used value for flex-basis is content."

However, in practice, when a flex-basis used value of content is derived from a percentage resolved against an indefinite size flex container, flex items are not consistently sized under the same constraint set on the flex container (e.g., max-content), as specified in 9.2(3)(c).

Test (Chrome and Firefox)

<!DOCTYPE html>
<style>
  body,
  html {
    height: 100%;
    margin: 0;
  }
  .flex {
    display: flex;
    flex-flow: row nowrap;
    width: max-content;
    background: red;    
  }
  .flex > div {
    background: green;    
    /* flex-basis: content behaves as expected. */    
    flex-basis: 50%;
  }
</style>
<div class="flex">
  <div>1234 56789</div>
</div>

The text was updated successfully, but these errors were encountered:

gitspeaks · 2024-12-19T09:40:48Z

Regarding point 4 in the same section:

Determine the main size of the flex container using the rules of the formatting context in which it participates. For this computation, auto margins on flex items are treated as 0.

It’s unclear why this step appears after calculating the flex base size and hypothetical main size of each item. Excluding the note about the automatic block size of a block-level flex container, this instruction seems more appropriate in point 2, as the flex container's definite main size establishes the available main space for the flex items. Perhaps the intention here is to determine the main size of an indefinite flex container based on the sum of the hypothetical main sizes of its flex items?

Loirooriol · 2025-01-03T17:28:12Z

It is unclear what constitutes a "used flex basis value that depends on its available space", as none seem relevant in this context aside from the value content.

There are things like fit-content and stretch.

flex items are not consistently sized under the same constraint set on the flex container

Your testcase doesn't show that. Flex items can re-resolve their percentages after the final size of the flex container is known.

gitspeaks · 2025-01-03T18:36:18Z

There are things like fit-content and stretch.

How are these values applicable in this context?

The specification for flex-basis lists its possible values as 'content | <'width'> with an initial value of auto. The link for <'width'> which directs to the CSS 2.1 specification defines the valid values as:
<length> | <percentage> | auto | inherit.

Your testcase doesn't show that. Flex items can re-resolve their percentages after the final size of the flex container is known.

What do you mean it doesn't show that?

Here is the render from the current version of Chrome:

Clearly, this is not resolved as max-content.

Flex items can re-resolve their percentages after the final size of the flex container is known.

Are you suggesting that a flex container sized under min-content or max-content transitions from indefinite to definite size mid-algorithm, causing the layout algorithm to restart?

Where is this behavior specified in the algorithm details?

Loirooriol · 2025-01-03T18:42:47Z

CSS 2.1 specification defines the valid values as: <length> | <percentage> | auto | inherit

First, you are looking at an old TR from 2018. Not that the draft is up-to-date with latest resolutions either, but at least if you checked https://drafts.csswg.org/css-flexbox-1/#flex-basis-property you would get a link to a syntax of width which is more modern than CSS 2.1.

But then for stretch and fit-content you need to check Sizing L4: https://drafts.csswg.org/css-sizing-4/#sizing-values

Are you suggesting that a flex container sized under min-content or max-content transitions from indefinite to definite size mid-algorithm, causing the layout algorithm to restart?

Yes, that's kind of the idea. Please read about cyclic percentages in CSS Sizing.

gitspeaks · 2025-01-03T18:59:26Z

What do you mean I'm referencing an outdated TR from 2018? This is the latest published version, and all the quotes in this issue are taken directly from it. Specifically, the issue regarding "available space" originates from this version.

Why isn't this considered a bug in the specification? While many things in drafts reflect improvements and enhancements, the current published version should, at the very least, be correct, shouldn't it?

For example, why hasn't the link for width been updated? How can common reader make sense of things ? If the logic is to always goto the latest draft to verify things, than what's the value of the published version ?

gitspeaks · 2025-01-03T19:12:16Z

Yes, that's kind of the idea. Please read about cyclic percentages in CSS Sizing.

So point 9.2(4) is effectively goto 9.2(2) when the flex container has an indefinite size to make it definite ?

Loirooriol · 2025-01-03T19:35:49Z

Yeah the latest published thing is from 2018, so I'm calling it old.

always goto the latest draft to verify things

I mean, not always. But if you want to discuss the spec details, then looking at an old thing isn't much productive.

what's the value of the published version?

See https://www.w3.org/policies/process/#maturity-stages. In particular, editor's drafts are lacking in some areas:

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C.

So point 9.2(4) is effectively goto 9.2(2) when the flex container has an indefinite size to make it definite ?

Seems like that could be it. Not sure if it's clearly explained somewhere, I'm not that familiar with the flexbox spec, I know grid better (explained in https://drafts.csswg.org/css-grid/#layout-algorithm)

Note re-resolving percentages isn't specific of flexbox/grid, it's the same for the contents of an inline-block (in the inline axis only).

gitspeaks · 2025-01-03T19:51:07Z

I mean, not always. But if you want to discuss the spec details, then looking at an old thing isn't much productive.

It's not just about discussing the details — it's about pointing out errors in the current version to ensure they get 'patched' For example, shouldn't the incorrect width link be fixed? What's the policy regarding the correctness of the existing published version?

Seems like that could be it. Not sure if it's clearly explained somewhere, I'm not that familiar with the flexbox spec, I know grid better (explained in https://drafts.csswg.org/css-grid/#layout-algorithm)

So, who actually knows? And who should be asked about this?

gitspeaks · 2025-01-03T23:44:28Z

@tabatkins Is point 9.2(4) effectively a reference back to 9.2(2) for the case when the flex container has an indefinite size, to make it definite after the flex items main sizes have been determined?

Loirooriol · 2025-01-04T11:48:21Z

shouldn't the incorrect width link be fixed?

It's not incorrect. It's just that the definition of width in CSS Sizing supersedes the one from CSS2.

So, who actually knows? And who should be asked about this?

You can file an issue asking for this to be clarified, like #3418 did for grid.

gitspeaks · 2025-01-04T12:35:33Z

It's not incorrect. It's just that the definition of width in CSS Sizing supersedes the one from CSS2.

I disagree. In the context of this issue (e.g published version), the provided link for width in 7.2.3 is incorrect.

I initially asked:

It is unclear what constitutes a "used flex basis value that depends on its available space", as none seem relevant in this context aside from the value content.

You replied:

There are things like fit-content and stretch.

To which I responded:

The specification for flex-basis lists its possible values as 'content | <'width'> with an initial value of auto. The link for <'width'> which directs to the CSS 2.1 specification defines the valid values as:
<length> | <percentage> | auto | inherit.

Given this, how can one interpret "used flex basis value that depends on its available space" as anything other than content without prior knowledge that fit-content and stretch are relevant values?

Possible solutions:

Update the link to point to a more current and relevant definition of width.
Explicitly include fit-content and stretch in the list of valid flex-basis values.

gitspeaks · 2025-01-04T18:52:39Z

What's the reason for the downvote?

I repeat:

According to CSS Flexible Box Layout Module Level 1, 9.2. Line Length Determination (3)(C):

"If the used flex basis is content or depends on its available space, and the flex container is being sized under a min-content or max-content constraint (e.g. when performing automatic table layout [CSS21]), size the item under that constraint. The flex base size is the item’s resulting main size."

It's unclear what "or depends on its available space" means here, given that the possible values for flex-basis are limited to content and the width as defined in CSS2.

The only other relevant value that depends on the available space according to the CSS2 specification is percentage values, which, as noted, are resolved to content in this context. Therefore, there are no other valid candidates for the used value of flex-basis besides content that are relevant to this paragraph given the published definitions.

You pointed out that the definition of width was extended in draft and the new values in css-sizing-4 . I'm simply suggesting backporting a link to these definitions into the published version of the spec for clarity. Why the pushback?

gitspeaks mentioned this issue Jan 3, 2025

ETA for css-flexbox-2 initial draft #11432

Closed

Loirooriol added the css-flexbox-1 Current Work label Jan 3, 2025

Loirooriol closed this as completed Jan 3, 2025

Loirooriol added the Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. label Jan 3, 2025

svgeesus mentioned this issue Jan 4, 2025

[css-flexbox-1] Time for a CR Draft of Flexbox 1 #11435

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-flexbox-1] 9.2. Line Length Determination Issue #11392

[css-flexbox-1] 9.2. Line Length Determination Issue #11392

gitspeaks commented Dec 18, 2024

gitspeaks commented Dec 19, 2024

Loirooriol commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

Loirooriol commented Jan 3, 2025 •

edited

Loading

gitspeaks commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

Loirooriol commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

Loirooriol commented Jan 4, 2025

gitspeaks commented Jan 4, 2025

gitspeaks commented Jan 4, 2025 •

edited

Loading

[css-flexbox-1] 9.2. Line Length Determination Issue #11392

[css-flexbox-1] 9.2. Line Length Determination Issue #11392

Comments

gitspeaks commented Dec 18, 2024

gitspeaks commented Dec 19, 2024

Loirooriol commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

Loirooriol commented Jan 3, 2025 • edited Loading

gitspeaks commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

Loirooriol commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

gitspeaks commented Jan 3, 2025

Loirooriol commented Jan 4, 2025

gitspeaks commented Jan 4, 2025

gitspeaks commented Jan 4, 2025 • edited Loading

Loirooriol commented Jan 3, 2025 •

edited

Loading

gitspeaks commented Jan 4, 2025 •

edited

Loading