Open Bug 1055887 Opened 10 years ago Updated 9 months ago

Update intrinsic sizing of flex containers (e.g. container max-content width) to new spec text

Categories

(Core :: Layout: Flexbox, defect)

Product:
Core
Component:
Layout: Flexbox
Type:
defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

(Blocks 3 open bugs)

Details

Per http://lists.w3.org/Archives/Public/www-style/2014Aug/0308.html , there's been a change to the algorithm for getting the intrinsic sizes of a flex containers.

The old text was something like "add up the hypothetical main sizes of the flex items".

The new text is a bit more complex, and starts out: "For each flex item, subtract its flex basis from its max-content contribution size, then divide by its flex grow factor, floored at 1."

The new algorithm is currently available here:
  http://dev.w3.org/csswg/css-flexbox-1/#intrinsic-sizes
Blocks: flexbox-spec-changes
OS: Linux → All
Hardware: x86_64 → All
Summary: Update intrinsic sizing of flex items to new spec text → Update intrinsic sizing of flex containers (e.g. container max-content width) to new spec text
Blocks: 1179454
See Also: → 995020
fantasai suggested some further tweaks (to the max-content contribution of a flex item) here:
  https://lists.w3.org/Archives/Public/www-style/2015Jul/0429.html
Chrome Fixed!
Blocks: 1389122
This spec text is changing a bit further in https://github.com/w3c/csswg-drafts/issues/1735 , BTW.
Component: Layout → Layout: Flexbox

Chrome's bug for this is https://crbug.com/240765. I think FF and Chrome currently use the same intrinsic sizing algorithm. It leads to some bad behavior, like https://codepen.io/anon/pen/wBJQap (the new better algorithm, used by EdgeHTML, would make the red border surround the grey rectangle).

I want to fix that broken behavior for authors, but the compat situation for changing to the new algorithm is terrifying. And the chrome layout team (well, Ian K, biesi, and I) hasn't figured out a way to accurately measure the compat impact, aside from ship the new algorithm and gauge the resultant screaming :(

If we (including the Firefox layout engineers) decide to implement the new algorithm, I think we should sync up on releasing it so that author-pain is minimized. Hopefully we can release within a few weeks of each other.

Thoughts on any of this?

(Per the above comment)

Flags: needinfo?(dholbert)

Sure, that sounds like a good idea. This wasn't on my radar to implement soon, but we could plan to prioritize it if/when you're actively working on it as well.

Flags: needinfo?(dholbert)

Oh, yeah, we're not planning to implement soon either, especially after not finding a way to judge the negative impact, I was mostly just checking in. Great to hear that syncing up is a good possibility :)

(In reply to dgrogan(chrome) from comment #9)

If we (including the Firefox layout engineers) decide to implement the new algorithm, I think we should sync up on releasing it so that author-pain is minimized. Hopefully we can release within a few weeks of each other.

Yes. Each time such a thing can be planned and coordinated with browsers simultaneously releasing a change, it will have better chance to be applied. We should also involve Apple WebKit engineers into this.

On the webcompat side, we (the webcompat team) will be seeing the breakage quickly on webcompat.com as if it has any impact these bugs will likely be reported.

@karlcow, just FYI, I think you and I are using the term "compat" differently. I mean compatibility between existing sites and new browser behavior. I think you mean compatibility between browsers.

Maybe the Blink community tends to use "compat" to mean breaking existing sites while the Firefox community uses it to mean compatibility between browsers? (Blink uses "interop[erability]" to describe the latter situation.)

To be clear, both are important and I think we are still in agreement here!

Yeah, Mozilla's use of "webcompat" covers both of those ideas (and we do see issues reported at webcompat.com for both types of issues - both regressions and interop-issues-that-users-are-actually-hitting-in-the-wild).

It's kind of two sides of the same coin (that coin being: "the web-as-it-exists depends on certain browser behavior").

I landed the first bit of this (the row nowrap case, with some new tests) over at https://crbug.com/240765.

It'd be great if we could launch ~together, as discussed above, but what might be a reasonable timetable for you?

I just Agenda+'d https://github.com/w3c/csswg-drafts/issues/6777, which is about a pretty big (IMO) issue with the specified behavior for the column wrap case.

Flags: needinfo?(dholbert)

P.S. I think we could launch the non-column wrap cases, or at least the row cases, even when we're still in spec discussion about the column wrap case.

(In reply to dgrogan(chrome) from comment #17)

It'd be great if we could launch ~together, as discussed above, but what might be a reasonable timetable for you?

Hmm, let me get back to you; this wasn't on my roadmap for the near future, but I agree it'd be nice to ship this change around the same time.

Any updates? After a few revisions, the spec is in better shape now. Blink will probably be ready to ship in the next 4 weeks, but we can delay a few months if that allows the engines to ship together. (Also, when Gecko implements, you will almost certainly root out a few bugs in our implementation that we don't want to ship!)

I just filed a WebKit bug for the new algorithm https://bugs.webkit.org/show_bug.cgi?id=243173

Thanks - glad to hear that the spec has progressed and that the Blink impl is looking close to ready!

I'm happy to look into implementing this ~soon, in the interests of averting interop issues and uncovering potential disagreements-with-the-Chromium-impl sooner rather than later. Not yet sure what the complexity/ETA will be, but I can plan to get started at least in the next week or two. (Realistically I probably won't get to this next week, due to the CSSWG meetings Mon-Weds and due to next Friday being a Mozilla "wellness day" general-holiday; but I'll make this a priority for the week after.)

🎉🎉🎉

Need to clarify something I said in comment 20. "Ready to ship in 4 weeks" meant first ship to Canary and Dev channel, not Stable. We'll see how bad the fallout is in Dev channel before promoting to Beta.

Also to note, we are only implementing inline intrinsic sizes at this time. So we aren't implementing the "Flex Container Intrinsic Main Sizes" algorithm for column containers, for example.

Good to know, thank you. I was wondering, did your implementation (the behavior-change) cause any substantial test-failures or known webcompat issues at this point?

There are ~10 changes to existing tests, but none seem scary.

We've only checked compat by browsing around in canary ourselves. We found one issue, but still haven't figured out if it's a bug in our implementation or intended behavior change.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)
Duplicate of this bug: 1827269

Update here: the spec algorithm didn't turn out to be web-compatible, but the Chrome folks have a new proposed algorithm discussed in https://github.com/w3c/csswg-drafts/issues/8884 which is hopefully more-web-compatible.

Flags: needinfo?(dholbert)
See Also: → https://github.com/w3c/csswg-drafts/issues/8884
You need to log in before you can comment on or make changes to this bug.