Open Bug 1349738 Opened 8 years ago Updated 2 years ago

The sizing of images in flex should take the dimension change caused by definite cross-size and aspect-ratio

Categories

(Core :: Layout, defect, P3)

55 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: fremycompany_pub, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15049 Steps to reproduce: 1. Define a width/height on a flex 2. Insert an image in it 3. Observe how its aspect-ratio affects its final size https://jsfiddle.net/zcqst2pr/ https://jsfiddle.net/zcqst2pr/1/ Did this work before? N/A Does this work in other browsers? Yes Actual results: Images do not flex as they do in Edge, which has been deemed per-spec in this case (see below). Expected results: Aspect-ratio should be preserved, except if the image is to be sized bigger than its normal size ("grow" test case). If it is, the flexing that takes place as a second step will shrink the image to fit the container. The reason flexing is different is that flex-shrink is 1 by default and flex-grow is 0 by default. Flexing doesn't have to take the image aspect-ratio into consideration, but should also refuse to shrink further than the image intrinsic size. Please discuss this issue at https://github.com/w3c/csswg-drafts/issues/1112 if you disagree with the test results
JSFiddle Testcase 0: https://jsfiddle.net/zcqst2pr/ Screenshot comparing browsers: https://cloud.githubusercontent.com/assets/364405/24014172/2857bc94-0a41-11e7-8286-2fee87259d45.png Analysis of our behavior vs. Edge's behavior: * Container 1: We agree. * Container 2: We don't shrink the image as much horizontally as we do vertically. (We let it entirely fill the flex container, which is smaller than the image & has a different aspect ratio.) I'm pretty sure Edge is correct -- we have to treat the image as having a definite height (cross-size) per [1], and that means we should resolve its flex base size according to that height converted through the aspect-ratio per [2]. And that'll produce the small width that Edge uses here, which doesn't need any further stretching/shrinking. * Container 3: (Same setup & results as 2; axes are just reversed.) * Container 4: We agree. JSFiddle Testcase 1: https://jsfiddle.net/zcqst2pr/1/ Screenshot comparing browsers: https://cloud.githubusercontent.com/assets/364405/24014188/3594de1e-0a41-11e7-9d3f-13fd5f97fdea.png Analysis of our behavior vs. Edge's behavior: * Container 1: We stretch the image vertically (in the cross axis) but not horizonally (in the main axis). Edge stretches it proportionally, and then shrinks per default "flex-shrink:1" so that it fits the container width. Edge is correct and we are not. We should be treating the image as having a definite cross size per [1] and as having a proportionally-large flex base size, per [2]. (And then that flex base size is larger than the container and should get shrunk to fit, in accordance with the default "flex-shrink:1". min-width:auto doesn't prevent this clamping because it'll resolve to 32px -- the content width -- I think.) * Container 2: We do the same thing we did in Container 1, for the same reasons. Edge is correct. The only difference here is that no shrinking is required (below the flex base size) because there's plenty of width (main-axis space). * Container 3: Same as Container 2, but with axes reversed. * Container 4: Same as Container 1, but with axes reversed. [1] Per the first part of https://drafts.csswg.org/css-flexbox-1/#definite [2] https://drafts.csswg.org/css-flexbox-1/#algo-main-item part B: "If the flex item has [...conditions...] then the flex base size is calculated from its inner cross size and ... aspect ratio.
Blocks: 1136312
See Also: → 1136312
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.