Intent to Implement and Ship: CSS Flexbox: New intrinsic size algorithm

[Christian Biesinger]

Contact emails cbies...@chromium.org Spec https://drafts.csswg.org/css-flexbox/#intrinsic-sizes Summary The CSS Flexbox specification changed the algorithm for calculating a flexbox's intrinsic size (see below for the spec link). The new algorithm produces better results when there are flex items that actually flex, because it takes flex factors and flex-basis into account, whereas so far we just sum up the preferred sizes of each flex item. Motivation The new algorithm gives better results for a case like:

<div style="display: inline-flexbox;">

<div style="flex: 1;">XX</div> <div style="flex: 2">XX</div>

</div>

This above example will not size the flexbox big enough to fully fit the first flex item!

The separate motivation is to follow the current version of the spec for compatibility with other browsers, who also want to update.

(note: per the spec, we should also use this algorithm to size a flexbox's height when there is no height specified, but I will implement that separately, with a new intent if desired)

Compatibility Risk Firefox: Public support Edge: Private support Safari: No public signals Web developers: No signals

Describe the degree of compatibility risk you believe this change poses Hard to tell. On the one hand, other browsers are committed to implementing flexbox as specified. On the other hand, this does potentially affect shipped content. I believe inline/shrink-wrapped flexboxes to be rare, though.

Ongoing technical constraints None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes

OWP launch tracking bug No OWP bug. Regular bug: http://crbug.com/240765 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6021353392046080 Requesting approval to ship?

Yes

[Rick Byers]

On Wed, Aug 5, 2015 at 6:56 PM, Christian Biesinger <cbies...@chromium.org> wrote:

Contact emails cbies...@chromium.org Spec https://drafts.csswg.org/css-flexbox/#intrinsic-sizes Summary The CSS Flexbox specification changed the algorithm for calculating a flexbox's intrinsic size (see below for the spec link). The new algorithm produces better results when there are flex items that actually flex, because it takes flex factors and flex-basis into account, whereas so far we just sum up the preferred sizes of each flex item. Motivation The new algorithm gives better results for a case like:

<div style="display: inline-flexbox;">

<div style="flex: 1;">XX</div> <div style="flex: 2">XX</div>

</div>

This above example will not size the flexbox big enough to fully fit the first flex item!

The separate motivation is to follow the current version of the spec for compatibility with other browsers, who also want to update.

(note: per the spec, we should also use this algorithm to size a flexbox's height when there is no height specified, but I will implement that separately, with a new intent if desired)

Compatibility Risk Firefox: Public support

Is this the best link to back that up?

Edge: Private support Safari: No public signals Web developers: No signals

Describe the degree of compatibility risk you believe this change poses Hard to tell. On the one hand, other browsers are committed to implementing flexbox as specified. On the other hand, this does potentially affect shipped content. I believe inline/shrink-wrapped flexboxes to be rare, though.

Do we have any way to estimate the compat impact this may have?  Eg. is it worth considering adding a use counter first, or do you feel the risk is low enough that we should just make the change and watch for any fallout?

Also it looks like there are further tweaks to the algorithm being discussed.  To what extent does this still appear to be a moving target?  If we are going to break a couple rare sites, I'd prefer we do it once instead of multiple times.

[Paul Irish]

On Wed, Aug 5, 2015 at 3:56 PM, Christian Biesinger <cbies...@chromium.org> wrote:

...

 

Motivation The new algorithm gives better results for a case like:

<div style="display: inline-flexbox;">

Did you mean "inline-flex" here?

Compatibility Risk

 

Can you indicate which intrinsic sizing algorithm is currently implemented by Edge, Firefox, Safari?

Describe the degree of compatibility risk you believe this change poses

Hard to tell. On the one hand, other browsers are committed to implementing flexbox as specified. On the other hand, this does potentially affect shipped content. I believe inline/shrink-wrapped flexboxes to be rare, though.

The previous flexbox change broke both DevTools and trace-viewer for a few days. A quick audit indicates the above change will break DevTools again.

I would also like a counter in place to measure this first.

If the usecounter results indicate more than 1% of flexbox deployments will be affected by the sizing change, I'd prefer we start with a console warning for a full milestone beforehand.

[Christian Biesinger]

Per the comments here I am adding a use counter in
https://codereview.chromium.org/1304853002/.

-christian

[一丝冰凉]

Can someone bother to look at this case http://jsbin.com/pinerirogu/1/edit?html,css,output , it seems that there's still difference between Firefox and Chrome Canary. Can someone bother to explain why this hasn't been fixed by this issue? Or if Canary is not there yet?

See also: https://code.google.com/p/chromium/issues/detail?id=426898#c35

在 2015年8月6日星期四 UTC+8上午6:56:49，Christian Biesinger写道：

[Christian Biesinger]

Alright, I'd like to get back to this intent. We do have data now:

https://www.chromestatus.com/metrics/feature/timeline/popularity/939

There's been a bit of a jump in the count of pages where this new algorithm would produce a difference (?!). However, it's still at only 0.04% of all pageloads.

I don't know exactly how often flexbox is used (afaik we have no counter for display: flex / display: inline-flex), but we do have a counter for the flex: property -- which is used on 14% of pageloads: https://www.chromestatus.com/metrics/css/popularity

Thoughts?

-Christian

[Rick Byers]

Ouch.  Looks like we would have been fine to change this before October but it's getting pretty risky now (especially if you assume the upward trend will continue).  If this change was going to badly break layout on even half of these (0.02% of page loads) it would probably be too harmful.  But perhaps most changes wouldn't actually be bad, just slightly different?  Do you have any intuition around that?

One possible next step is to try to collect a random sample of (eg. ~20) sites impacted by this change and evaluate the level of impact (eg. you could use the telemetry cluster to load the top 100k websites on a custom build that logs when your deprecation is hit).

Any update on what the other engines are doing here?  If some other engine had already successfully shipped this change, that would lower the risk dramatically.

Rick