New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-flexbox] Non-interop with shrinking images #1322

Closed
jensimmons opened this Issue May 3, 2017 · 7 comments

Comments

@jensimmons

jensimmons commented May 3, 2017

Testcase that @fantasai created as we were discussing Flexbox.

@dauwhe dauwhe added the css-flexbox-1 label May 4, 2017

@jensimmons jensimmons changed the title from [css-flexbox] Non-interop with shrinking images to [css-flexbox] Non-interop with shrinking and growing images May 6, 2017

@rachelandrew

This comment has been minimized.

Show comment
Hide comment
@rachelandrew

rachelandrew May 6, 2017

Contributor

There is a bunch of discussion here regarding stretching of images with an intrinsic aspect ratio #1112

Contributor

rachelandrew commented May 6, 2017

There is a bunch of discussion here regarding stretching of images with an intrinsic aspect ratio #1112

@astearns astearns removed the Agenda+ F2F label Nov 6, 2017

@w3c w3c deleted a comment from jensimmons Nov 6, 2017

@fantasai fantasai changed the title from [css-flexbox] Non-interop with shrinking and growing images to [css-flexbox] Non-interop with shrinking images Nov 6, 2017

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Nov 6, 2017

Contributor

Adjusting description back to focus on the testcase that was initially posted; there's definitely a bunch of bugs in image sizing, but wanted to discuss specifically this testcase which shows some very interesting non-conforming behavior in Firefox.

data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw%2BDQo8c3R5bGU%2BDQogZGl2IHsgZGlzcGxheTogZmxleDsgYm9yZGVyOiBzb2xpZDsgd2lkdGg6IDUwJTsgfQ0KIHAgeyBtYXJnaW46IDJweDsgYmFja2dyb3VuZDogc2lsdmVyOyBmbGV4OiAxOyB0ZXh0LWFsaWduOiBjZW50ZXI7IH0NCjwvc3R5bGU%2BDQo8ZGl2Pg0KIDxpbWcgc3JjPSJodHRwczovL3BsYWNlaG9sZGl0LmltZ2l4Lm5ldC9%2BdGV4dD90eHRzaXplPTMzJnR4dD0zNTAlQzMlOTcxNTAmdz0zNTAmaD0xNTAiPg0KIDxwPkJCQkJCQg0KIDxwPkMgQyBDDQo8L2Rpdj4%3D

<!DOCTYPE html>
<style>
 div { display: flex; border: solid; width: 50%; }
 p { margin: 2px; background: silver; flex: 1; text-align: center; }
</style>
<div>
 <img src="https://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150">
 <p>BBBBBB
 <p>C C C
</div>

Basically what's happening is that the flex items shrink down in different stages. First of course all the excess space gets eaten up, and then the items shrink down to their min-content sizes (triggering wrapping at the spaces in item C). Then, however, instead of flooring the items at that point, Firefox starts to shrink the image. It seems to have a two-stage concept of the min-content floor.

I don't know how it's doing this, but it seems rather nice, so might be worth discussing if we want to adopt it somehow.

Contributor

fantasai commented Nov 6, 2017

Adjusting description back to focus on the testcase that was initially posted; there's definitely a bunch of bugs in image sizing, but wanted to discuss specifically this testcase which shows some very interesting non-conforming behavior in Firefox.

data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw%2BDQo8c3R5bGU%2BDQogZGl2IHsgZGlzcGxheTogZmxleDsgYm9yZGVyOiBzb2xpZDsgd2lkdGg6IDUwJTsgfQ0KIHAgeyBtYXJnaW46IDJweDsgYmFja2dyb3VuZDogc2lsdmVyOyBmbGV4OiAxOyB0ZXh0LWFsaWduOiBjZW50ZXI7IH0NCjwvc3R5bGU%2BDQo8ZGl2Pg0KIDxpbWcgc3JjPSJodHRwczovL3BsYWNlaG9sZGl0LmltZ2l4Lm5ldC9%2BdGV4dD90eHRzaXplPTMzJnR4dD0zNTAlQzMlOTcxNTAmdz0zNTAmaD0xNTAiPg0KIDxwPkJCQkJCQg0KIDxwPkMgQyBDDQo8L2Rpdj4%3D

<!DOCTYPE html>
<style>
 div { display: flex; border: solid; width: 50%; }
 p { margin: 2px; background: silver; flex: 1; text-align: center; }
</style>
<div>
 <img src="https://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150">
 <p>BBBBBB
 <p>C C C
</div>

Basically what's happening is that the flex items shrink down in different stages. First of course all the excess space gets eaten up, and then the items shrink down to their min-content sizes (triggering wrapping at the spaces in item C). Then, however, instead of flooring the items at that point, Firefox starts to shrink the image. It seems to have a two-stage concept of the min-content floor.

I don't know how it's doing this, but it seems rather nice, so might be worth discussing if we want to adopt it somehow.

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons commented Nov 6, 2017

This example is now also here: https://codepen.io/jensimmons/pen/aVmogq

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Nov 6, 2017

Member

The Working Group just discussed Non-interop of sizing images in flexbox.

The full IRC log of that discussion <iank_> Topic: Non-interop of sizing images in flexbox
<astearns> github: https://github.com//issues/1322
<iank_> fantasai: <goes to project>
<iank_> fantasai: Testcase in last comment
<iank_> fantasai: Flex container, and has some content that shrink down to their min-content size, if you have too many items they'll start to overflow.
<iank_> fantasai: Excess space starts to take up, the text starts to break, <explains the testcase>
<iank_> fantasai: The item with the image starts shrinking.
<iank_> fantasai: This FF behaviour is kinda nice.
<iank_> fantasai: So we want to make FF follow the spec? Or make other vendors follow FF implmentation>
<iank_> ?
<iank_> dholbert: I wrote most of the flex code in FF, and don't know whats going on here.
<iank_> gregwhitworth: What is the usecase where folks would want this behaviour?
<iank_> fantasai: This means that it won't overflow, where other implmentations would.
<iank_> dholbert: <explains image gallery usecase> being able to shrink them is kinda nice.
<jensimmons> I just dropped this example in this codepen: https://codepen.io/jensimmons/pen/aVmogq
<iank_> fantasai: The image doesn't shrink until everything else has wrapped.
<iank_> cbiesinger: If you give the image a flex-basis: auto , and others a flex-basis of 0, don't you get that behaviour?
<iank_> fantasai: You wouldn't be able to get them to start out at their content sizes?
<iank_> fantasai: I don't think we need to resolve now, but interesting to think about.
<iank_> dholbert: I'll try and figure out whats happening in our impl, and report back on the github issue.
<iank_> jensimmons: I had a few questions about flexbox, lets of interop issues around squishing images, and because of those issues, they are really hard for authors to think about.
<iank_> astearns: Def. want interop here, just need to agree what that behaviour is.
<iank_> Rossen: It looks like we have all the impls apart from FF, having interop.
<iank_> Rossen: Switching to FF, means that we might run into compat.
<iank_> fantasai: We were going through interop cases, and most of them were obv., but this one seemed interesting.
<iank_> jensimmons: It also seems like we could do what we want, as there seems to be such lack of interop around images.
<iank_> gregwhitworth: Only about this issue?
<iank_> jensimmons: No, more broadly about images as flex items.
<iank_> gregwhitworth: Where are the bugs?
<iank_> fantasai: Don't have them here. But this one just seemed interesting.
Member

css-meeting-bot commented Nov 6, 2017

The Working Group just discussed Non-interop of sizing images in flexbox.

The full IRC log of that discussion <iank_> Topic: Non-interop of sizing images in flexbox
<astearns> github: https://github.com//issues/1322
<iank_> fantasai: <goes to project>
<iank_> fantasai: Testcase in last comment
<iank_> fantasai: Flex container, and has some content that shrink down to their min-content size, if you have too many items they'll start to overflow.
<iank_> fantasai: Excess space starts to take up, the text starts to break, <explains the testcase>
<iank_> fantasai: The item with the image starts shrinking.
<iank_> fantasai: This FF behaviour is kinda nice.
<iank_> fantasai: So we want to make FF follow the spec? Or make other vendors follow FF implmentation>
<iank_> ?
<iank_> dholbert: I wrote most of the flex code in FF, and don't know whats going on here.
<iank_> gregwhitworth: What is the usecase where folks would want this behaviour?
<iank_> fantasai: This means that it won't overflow, where other implmentations would.
<iank_> dholbert: <explains image gallery usecase> being able to shrink them is kinda nice.
<jensimmons> I just dropped this example in this codepen: https://codepen.io/jensimmons/pen/aVmogq
<iank_> fantasai: The image doesn't shrink until everything else has wrapped.
<iank_> cbiesinger: If you give the image a flex-basis: auto , and others a flex-basis of 0, don't you get that behaviour?
<iank_> fantasai: You wouldn't be able to get them to start out at their content sizes?
<iank_> fantasai: I don't think we need to resolve now, but interesting to think about.
<iank_> dholbert: I'll try and figure out whats happening in our impl, and report back on the github issue.
<iank_> jensimmons: I had a few questions about flexbox, lets of interop issues around squishing images, and because of those issues, they are really hard for authors to think about.
<iank_> astearns: Def. want interop here, just need to agree what that behaviour is.
<iank_> Rossen: It looks like we have all the impls apart from FF, having interop.
<iank_> Rossen: Switching to FF, means that we might run into compat.
<iank_> fantasai: We were going through interop cases, and most of them were obv., but this one seemed interesting.
<iank_> jensimmons: It also seems like we could do what we want, as there seems to be such lack of interop around images.
<iank_> gregwhitworth: Only about this issue?
<iank_> jensimmons: No, more broadly about images as flex items.
<iank_> gregwhitworth: Where are the bugs?
<iank_> fantasai: Don't have them here. But this one just seemed interesting.
@dholbert

This comment has been minimized.

Show comment
Hide comment
@dholbert

dholbert Nov 6, 2017

Contributor

(I didn't notice the p { ...flex: 1} at first -- the behavior makes more sense in light of that.)

So, there's really just one main Firefox quirk here: we're treating the img as having min-width:0 (i.e. we're resolving its auto to 0). This is because our implementation is from an older version of the spec text, which explicitly said to resolve min-width:auto to 0 for elements with an intrinsic aspect ratio. Bug 1136312 is filed on updating that. This Firefox behavior will change once we fix that bug.

Here's a version of the codepen with explicit "min-width:0" to make other browsers match that behavior:
https://codepen.io/anon/pen/BmLaZK

With that tweak, Firefox and Edge agree on the rendering, I think. (Chrome doesn't quite agree -- it doesn't honor the aspect ratio at all as the image shrinks, whereas Firefox/Edge honor the aspect ratio up until the point where the "C C C" is the tallest thing and forces the image to that height via align-self:stretch)

Contributor

dholbert commented Nov 6, 2017

(I didn't notice the p { ...flex: 1} at first -- the behavior makes more sense in light of that.)

So, there's really just one main Firefox quirk here: we're treating the img as having min-width:0 (i.e. we're resolving its auto to 0). This is because our implementation is from an older version of the spec text, which explicitly said to resolve min-width:auto to 0 for elements with an intrinsic aspect ratio. Bug 1136312 is filed on updating that. This Firefox behavior will change once we fix that bug.

Here's a version of the codepen with explicit "min-width:0" to make other browsers match that behavior:
https://codepen.io/anon/pen/BmLaZK

With that tweak, Firefox and Edge agree on the rendering, I think. (Chrome doesn't quite agree -- it doesn't honor the aspect ratio at all as the image shrinks, whereas Firefox/Edge honor the aspect ratio up until the point where the "C C C" is the tallest thing and forces the image to that height via align-self:stretch)

@cbiesinger

This comment has been minimized.

Show comment
Hide comment
@cbiesinger

cbiesinger Nov 6, 2017

Blink has some bugs with aspect ratios and images in flexbox, that could be part of that. I filed https://crbug.com/781972 today for another issue but there's also existing bugs, and they may all be the same underlying issue.

cbiesinger commented Nov 6, 2017

Blink has some bugs with aspect ratios and images in flexbox, that could be part of that. I filed https://crbug.com/781972 today for another issue but there's also existing bugs, and they may all be the same underlying issue.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Jan 27, 2018

Contributor

OK, sounds like we're closing this issue as “implementations just need to fix their bugs”. Please re-open if that's not the case. :)

Contributor

fantasai commented Jan 27, 2018

OK, sounds like we're closing this issue as “implementations just need to fix their bugs”. Please re-open if that's not the case. :)

@fantasai fantasai closed this Jan 27, 2018

@fantasai fantasai added this to the Published css-flexbox-1 2017-10-19 milestone Mar 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment