Intent to Prototype and Ship: flex-basis property honors keywords 'content' and 'min/max/fit-content'

[David Grogan]

Contact emails

dgr...@chromium.org

Explainer

https://css-tricks.com/snippets/css/a-guide-to-flexbox/#flex-basis
https://stackoverflow.com/a/51285309/681070

Specification

https://drafts.csswg.org/css-flexbox/#valdef-flex-basis-content

API spec

Yes

Summary

You can now specify the keywords 'content', 'min-content', 'max-content', or 'fit-content' as the value of the 'flex-basis' property and its 'flex' shorthand. 'content' makes flex base size use the default sizing rules as if 'flex-basis' and preferred main size ('width' or 'height') are both 'auto', ignoring any non-auto 'width' or 'height' in the main axis dimension. The other keywords are same as usual and give more options for specifying the flex base size.

Blink component

Blink>Layout>Flexbox

TAG review

Not needed; this has been in the spec for years and Firefox shipped at least a few years ago.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interop: Firefox implemented the current spec except for 'fit-content' mentioned elsewhere. Blink will also implement the current spec. If there are interpretation differences, I'll raise them with the FF team and/or spec authors. WebKit hasn't implemented. Compat: There may be some sites that use these keywords even though Blink hasn't supported them until now. In those cases the sites may look different when Blink support rolls out.

Gecko: Shipped/Shipping (https://wpt.fyi/results/css/css-flexbox?label=master&label=experimental&aligned&q=flex-basis-content)

Firefox has shipped 'content', 'min-content', and 'max-content', but not 'fit-content'. I filed a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1720620.

This fiddle shows Firefox passing the 'min-content' case https://jsfiddle.net/1ua28zLh/

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-July/031922.html)

Web developers: Positive (https://crbug.com/470421) 9 stars on the bug

Activation

Developers can start using these right away in Blink.

Debuggability

devtools will recognize the new keywords as valid for these properties after rolling css_properties.json5 into the devtools frontend repo.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/470421

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5635933158244352

This intent message was generated by Chrome Platform Status.

[Mathias Bynens]

Sounds great, thank you! As a follow-up, I wonder if we (the DevTools team) should tweak the flexbox editor icons UI accordingly. WDYT, +Changhao Han +Peter Müller +Johan Bay?

  

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/470421

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5635933158244352

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOZbSt2v4iHxfQm0ENbo_fQ7Bp2p5M-SonUELuo0i4h6xHRvDw%40mail.gmail.com.

[Mike West]

Shipping the 'content', 'min-content', and 'max-content' values to align with Firefox seems like an excellent thing to do. I'm supportive of doing so, and I agree that a TAG review is unlikely to be beneficial, given that Firefox is already shipping.

That said, I'd like a little more clarity around their intent to ship 'fit-content' as well. Would it be reasonable to wait on shipping that value until we have confirmation that they're going to follow along? Asking for a signal from them as per https://bit.ly/blink-signals might be a good way of determining whether their lack of support was an oversight or intentional.

-mike

On Thu, Jul 15, 2021 at 5:40 AM David Grogan <dgr...@chromium.org> wrote:

--

[Manuel Rego Casasnovas]

On 15/07/2021 10:59, Mike West wrote:
> That said, I'd like a little more clarity around their intent to ship
> 'fit-content' as well. Would it be reasonable to wait on shipping that
> value until we have confirmation that they're going to follow along?
> Asking for a signal from them as per https://bit.ly/blink-signals
> <https://bit.ly/blink-signals> might be a good way of determining
> whether their lack of support was an oversight or intentional.

I have another question about fit-content, are you planning to implement
"flex-basis: fit-content" or "flex-basis: fit-content(100px)" or both?

I know Blink supports "width: fit-content" but that wasn't a 100%
standard value until recently, for example it's not listed here:
https://drafts.csswg.org/css-sizing-3/#preferred-size-properties
However it's in https://drafts.csswg.org/css-sizing-4/#sizing-values but
together with other new values like "stretch" and "contain".

Would we be adding "fit-content" alone? Would it behave like
"fit-content(stretch)" as the spec says? Should we wait and add all
those things to width|height together with other places like flex-basis?

Thanks,
Rego

[David Grogan]

On Thu, Jul 15, 2021 at 9:05 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 15/07/2021 10:59, Mike West wrote:
> That said, I'd like a little more clarity around their intent to ship
> 'fit-content' as well. Would it be reasonable to wait on shipping that
> value until we have confirmation that they're going to follow along?
> Asking for a signal from them as per https://bit.ly/blink-signals
> <https://bit.ly/blink-signals> might be a good way of determining
> whether their lack of support was an oversight or intentional.

So I misunderstood Firefox's behavior. They support 'fit-content' for 'flex-basis' but only as the prefixed keyword '-moz-fit-content'. The prefix isn't specific to 'flex-basis': they haven't unprefixed '-moz-fit-content' for _any_ property.

FF engineers and I discussed this in the mozilla bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1720620#c4 indicates a willingness to unprefix this keyword everywhere and describes behavior that matches Blink. A bug comment is not as formal as a request for position but do you agree that it's sufficient in this case?

I have another question about fit-content, are you planning to implement
"flex-basis: fit-content" or "flex-basis: fit-content(100px)" or both?

I plan to make 'flex-basis' accept all the keywords that are currently accepted by the preferred size properties (aka 'width' from now on in this message), but not more. The problem I'm trying to fix in this Intent is that 'flex-basis' rejects some keywords that 'width' accepts. Notably, flex-basis is defined to accept 'content' + whatever 'width' accepts. (See attached screenshot.) I'm just trying to catch 'flex-basis' up to where 'width' already is.

So because Blink's 'width' implementation currently accepts 'fit-content' but not 'fit-content(100px)', I made 'flex-basis' match that.

I know Blink supports "width: fit-content" but that wasn't a 100%
standard value until recently, for example it's not listed here:
https://drafts.csswg.org/css-sizing-3/#preferred-size-properties
However it's in https://drafts.csswg.org/css-sizing-4/#sizing-values but
together with other new values like "stretch" and "contain".

Would we be adding "fit-content" alone? Would it behave like
"fit-content(stretch)" as the spec says?

Yeah, that's the plan. 'flex-basis: fit-content' will behave the same as 'flex-basis: width'. (Which is 'fit-content(stretch)', as you said.)

 

Should we wait and add all
those things to width|height together with other places like flex-basis?

I don't think so. Waiting would just leave the mismatch between 'width' and 'flex-basis' exposed for longer. When we make 'width' support 'stretch' and 'contain', we'll simultaneously make 'flex-basis' support them also*. My goal with this Intent is to keep 'flex-basis' and 'width' in sync.

*LayoutNG actually gives us this for free, we'll just have to ensure there's css parser support.

Thanks,
  Rego

[David Grogan]

On Thu, Jul 15, 2021 at 8:27 PM David Grogan <dgr...@chromium.org> wrote:

On Thu, Jul 15, 2021 at 9:05 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 15/07/2021 10:59, Mike West wrote:
> That said, I'd like a little more clarity around their intent to ship
> 'fit-content' as well. Would it be reasonable to wait on shipping that
> value until we have confirmation that they're going to follow along?
> Asking for a signal from them as per https://bit.ly/blink-signals
> <https://bit.ly/blink-signals> might be a good way of determining
> whether their lack of support was an oversight or intentional.

So I misunderstood Firefox's behavior. They support 'fit-content' for 'flex-basis' but only as the prefixed keyword '-moz-fit-content'. The prefix isn't specific to 'flex-basis': they haven't unprefixed '-moz-fit-content' for _any_ property.

FF engineers and I discussed this in the mozilla bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1720620#c4 indicates a willingness to unprefix this keyword everywhere and describes behavior that matches Blink. A bug comment is not as formal as a request for position but do you agree that it's sufficient in this case?

I have another question about fit-content, are you planning to implement
"flex-basis: fit-content" or "flex-basis: fit-content(100px)" or both?

I plan to make 'flex-basis' accept all the keywords that are currently accepted by the preferred size properties (aka 'width' from now on in this message), but not more. The problem I'm trying to fix in this Intent is that 'flex-basis' rejects some keywords that 'width' accepts. Notably, flex-basis is defined to accept 'content' + whatever 'width' accepts. (See attached screenshot.) I'm just trying to catch 'flex-basis' up to where 'width' already is.

So because Blink's 'width' implementation currently accepts 'fit-content' but not 'fit-content(100px)', I made 'flex-basis' match that.

I know Blink supports "width: fit-content" but that wasn't a 100%
standard value until recently, for example it's not listed here:
https://drafts.csswg.org/css-sizing-3/#preferred-size-properties
However it's in https://drafts.csswg.org/css-sizing-4/#sizing-values but
together with other new values like "stretch" and "contain".

Would we be adding "fit-content" alone? Would it behave like
"fit-content(stretch)" as the spec says?

Correction:

 

Yeah, that's the plan. 'flex-basis: fit-content' will behave the same as 'width: fit-content'. (Which is 'fit-content(stretch)', as you said.)

[Manuel Rego Casasnovas]

> <https://drafts.csswg.org/css-flexbox/#flex-basis-property> to

> accept 'content' + whatever 'width' accepts. (See attached
> screenshot.) I'm just trying to catch 'flex-basis' up to where
> 'width' already is.
>
> So because Blink's 'width' implementation currently accepts
> 'fit-content' but not 'fit-content(100px)', I made 'flex-basis'
> match that.
>
> I know Blink supports "width: fit-content" but that wasn't a 100%
> standard value until recently, for example it's not listed here:
> https://drafts.csswg.org/css-sizing-3/#preferred-size-properties
> <https://drafts.csswg.org/css-sizing-3/#preferred-size-properties>
> However it's in
> https://drafts.csswg.org/css-sizing-4/#sizing-values
> <https://drafts.csswg.org/css-sizing-4/#sizing-values> but
> together with other new values like "stretch" and "contain".
>
> Would we be adding "fit-content" alone? Would it behave like
> "fit-content(stretch)" as the spec says?
>
>
>
> Correction:
>  
>
> Yeah, that's the plan. 'flex-basis: fit-content' will behave the
> same as 'width: fit-content'. (Which is 'fit-content(stretch)', as
> you said.)

Ok, thanks for the clarifications. I didn't realize "fit-content" was
already shipped in WebKit too, so it's only Firefox missing support in
the unprefixed property. It looks like they're willing to work on the
unprefixed version from the comments on bugzilla.

How is the interop story around fit-content itself? I see some
fit-content tests marked as ".tentative" in WPT css/css-sizing.
Shouldn't those be renamed to remove ".tentative" (it looks all browsers
pass them)?

Do we have tests for "flex-basis: min|max|fit-content"? I guess we
should make sure there's interop here with Firefox (even if they use a
prefixed version of the property).

Cheers,
Rego

[Christian Biesinger]

On Thu, Jul 15, 2021 at 11:27 PM David Grogan <dgr...@chromium.org> wrote:
>
>
>
> On Thu, Jul 15, 2021 at 9:05 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:
>>
>>
>>
>> On 15/07/2021 10:59, Mike West wrote:
>> > That said, I'd like a little more clarity around their intent to ship
>> > 'fit-content' as well. Would it be reasonable to wait on shipping that
>> > value until we have confirmation that they're going to follow along?
>> > Asking for a signal from them as per https://bit.ly/blink-signals
>> > <https://bit.ly/blink-signals> might be a good way of determining
>> > whether their lack of support was an oversight or intentional.
>
>
> So I misunderstood Firefox's behavior. They support 'fit-content' for 'flex-basis' but only as the prefixed keyword '-moz-fit-content'. The prefix isn't specific to 'flex-basis': they haven't unprefixed '-moz-fit-content' for _any_ property.
>
> FF engineers and I discussed this in the mozilla bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1720620#c4 indicates a willingness to unprefix this keyword everywhere and describes behavior that matches Blink. A bug comment is not as formal as a request for position but do you agree that it's sufficient in this case?
>
>> I have another question about fit-content, are you planning to implement
>> "flex-basis: fit-content" or "flex-basis: fit-content(100px)" or both?
>
>
> I plan to make 'flex-basis' accept all the keywords that are currently accepted by the preferred size properties (aka 'width' from now on in this message), but not more. The problem I'm trying to fix in this Intent is that 'flex-basis' rejects some keywords that 'width' accepts. Notably, flex-basis is defined to accept 'content' + whatever 'width' accepts. (See attached screenshot.) I'm just trying to catch 'flex-basis' up to where 'width' already is.

Sorry, can you clarify whether you will make flex-basis support
"content"? The email subject says so, but here you say that you will
only support the same keywords as width.

(I'm happy either way, just curious about what the plan is)


Christian

[David Grogan]

'content' also. Yeah, the section you quoted is really unclear. I meant the "not more" sentence to mean: of the keywords flex-basis is supposed to support only because width supports them, I'm not going to make flex-basis honor anything that Blink's width ignores.

'content' is flexbox-specific and doesn't apply to 'width' (as you know :) and I am going to add support for that with this intent.

[David Grogan]

Based on all browsers passing those, I'd say interop is good :)

As for .tentative, I'm not sure. Perhaps the author used .tentative because those tests use the vendor-prefxed -moz-fit-content?

Do we have tests for "flex-basis: min|max|fit-content"? I guess we
should make sure there's interop here with Firefox (even if they use a
prefixed version of the property).

Yeah, agreed we need to ensure interop here. There were no existing WPT tests so I added some in my WIP patch. Blink and Firefox pass all of them.

Cheers,
  Rego

[Manuel Rego]

On Wednesday, 21 July 2021 at 04:30:10 UTC+2 David Grogan wrote:

How is the interop story around fit-content itself? I see some
fit-content tests marked as ".tentative" in WPT css/css-sizing.
Shouldn't those be renamed to remove ".tentative" (it looks all browsers
pass them)?

Based on all browsers passing those, I'd say interop is good :)

As for .tentative, I'm not sure. Perhaps the author used .tentative because those tests use the vendor-prefxed -moz-fit-content?

It seems at that time they were added as ".tentative" due to some ongoing discussion on the CSSWG at that time: https://github.com/w3c/csswg-drafts/issues/3973

Now that that's resolved and we're going to ship this behavior I believe we can remove the ".tentative" suffix. There're other tests in WPT that use some "-moz" prefixed properties and are not marked as tentative.

 

Do we have tests for "flex-basis: min|max|fit-content"? I guess we
should make sure there's interop here with Firefox (even if they use a
prefixed version of the property).

Yeah, agreed we need to ensure interop here. There were no existing WPT tests so I added some in my WIP patch. Blink and Firefox pass all of them.

Great, thanks!

Cheers,

  Rego

[Manuel Rego]

LGTM1.

[Mike West]

LGTM2.

-mike

[Daniel Bratell]

/LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DefCUNAWRUTogYWu6A2eTazzH1t8%3D6Mkv6RuevBQMV2Bw%40mail.gmail.com.