https://en.m.wikipedia.org/wiki/Tteokbokki Version 9.0.2 (11601.3.9, r194284) 15C50 See screenshot.
Created attachment 268076 [details] Screenshot
Does not reproduce on system Safari on 15C50. Regression.
Created attachment 268077 [details] Reproduction
Created attachment 268079 [details] Reproduction
Caused by http://trac.webkit.org/changeset/194143
The relevant portion of the spec is: "The max-content inline size of a block container box is the inline-size of the box after layout, if all children are sized under a max-content constraint." However, it seems that computing the max content inline size can't depend on layout, because layout may require knowing the max content inline size (such in the case of floats)
Hyatt: Do you have any thoughts on the above comment?
(In reply to comment #5) > Caused by http://trac.webkit.org/changeset/194143 Checking...
Created attachment 268180 [details] Patch
(In reply to comment #6) > The relevant portion of the spec is: > > "The max-content inline size of a block container box is the inline-size of > the box after layout, if all children are sized under a max-content > constraint." > > However, it seems that computing the max content inline size can't depend on > layout, because layout may require knowing the max content inline size (such > in the case of floats) Turns out the "layout" that this spec mentions isn't a regular layout - it has special rules (such as percentages resolved against an intrinsic computation resolve to auto, and max intrinsic sizes are unconstrained). So there isn't a circular dependency. There's a fair amount of history here; we choose our faster computeBlockPreferredLogicalWidth() rather than a full-on layout (with a special mode) because it gives results which are almost always correct, and is much faster.
Comment on attachment 268180 [details] Patch Clearing flags on attachment: 268180 Committed r194558: <http://trac.webkit.org/changeset/194558>
All reviewed patches have been landed. Closing bug.