1368592 - Value of flex-basis should be set to 0px (not 0%) if it is omitted in flex shorthand

Status: NEW

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Xidorn Quan [:xidorn] UTC+11]

The CSS Flexible Box spec says, if the part of flex-basis is omitted in a declaration of flex shorthand, the specified value of flex-basis should be "0". And given flex-basis accepts "0" as a <width> value, I believe it means "0px" rather than "0%" here.

This is a spec change in https://github.com/w3c/csswg-drafts/commit/2c446befdf0f686217905bdd7c92409f6bd3921b

We was going to change our behavior in bug 1331530 to align with Servo, but it turns out that no browser has adopted this change yet, so we decided not to do so at that moment.

But given it is a spec change, we may want to do it eventually.

Comment 1

[Daniel Holbert [:dholbert]]

[adding "0%" to summary to make this more searchable, since 0% is the old/technically-incorrect-per-spec value]

Comment 2

[Cameron McCormack (:heycam)]

Xidorn, do you think there is a compatibility risk with this change, or any reason not to just go ahead and do it?

(From my reading, 0% when the containing block's size is indefinite would compute to "content" rather than 0px.)

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

TBH I don't know. Probably dholbert knows more about that.

In the old bug we were just trying to avoid changes on behavior with stylo, so there wasn't a real measurement on whether this may have compatibility risk.

From the reading of the spec, I think you are right that that's going to be a case which behavior gets changed. (Although it doesn't seem to me there is any normative statement backing "For example," sentence.)

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

Also it seems to me that Chrome and Safari both haven't switched the behavior to match the new spec. Maybe we should file bug against them or raise this to the working group.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: various scenarios with `flex` shorthand and 0-flavored values

(In reply to Cameron McCormack (:heycam) from comment #2)

Xidorn, do you think there is a compatibility risk with this change, or any
reason not to just go ahead and do it?

(From my reading, 0% when the containing block's size is indefinite would
compute to "content" rather than 0px.)

Just realized I never replied to this. This^ assessment is correct. Here's a testcase to demonstrate that.

If we applied the spec change, then the first two cases here (where flex-basis isn't explicitly specified) would produce a scenario with a thin strip of orange (like the last two cases), rather than being the content-height of the text.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #4)

Also it seems to me that Chrome and Safari both haven't switched the
behavior to match the new spec. Maybe we should file bug against them or
raise this to the working group.

This is still true, FWIW. Blink, WebKit, and Gecko all still use 0% here (which is why they get a content-shrinkwrapping size for the orange area in the first two boxes of my just-attached testcase).

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: now with `overflow:auto`

This is the more-concerning webcompat scenario; it's equivalent to my previous testcase, but I've replaced the hardcoded min-height with overflow:auto on the flex items. (Note that overflow happens to suppress the default content-based minimum size.)

If we were to implement the spec change, then the first two boxes in this testcase would render with no visible content, like the last two boxes do.