Flexbox - Image and Text

Here’s a demo showing what will happen to the image when it uses the code you posted above as its always easier to see in a live demo.

http://www.pmob.co.uk/temp2/image-aspect-ratio.html

I think that clarifies all points and options so you can make your decision which way to go with this.

Just remember that because you think an image fits at one size doesn’t mean it will fit at all sizes so you must try with different sized images (images of different aspect ratio) and different browser widths before you can make your choice.:slight_smile:

2 Likes

Sorry for the delay in replying @PaulOB - really liking the explanation, very clear!

There is only one problem with that demo though, you have added a width and height to the HTML img tag (which I have not done). By doing this it skews the results of the image, as you have illustrated. Try removing these attributes and allow the css to do the sizing, and you will see the results that I’m talking about. This is the part I’m most confused about.

1 Like

No you are incorrect on both counts :slight_smile:

As a matter of fact you should rarely omit the image width and height attributes as the browser can use them in order to scale the image efficiently and allocate the correct room even if they are then resized via CSS. Otherwise you get content jumping and resizing on the fly which looks awkward until the image is cached. It’s not a big issue as such but as a matter of course just add the natural width and height attributes to every image by default.

In my demo adding or removing the attributes will have no effect other than making the browser work harder. Just because you don’t put a width on the image doesn’t mean it does not have an intrinsic width. The browser just has to load the image first to find out what it is. The image always has a natural width and height anyway whether you specify it or not. Css will always over-ride attributes so the max width and height you added will deform the image as shown.

The demo is correct and clear in its results with or without the width and height attributes :slight_smile:

1 Like

Interesting, actually didn’t know that the content will be jumping all over the place whenever the images are being loaded - admittedly not ideal!

I’ve signed up to codepen, just to show there is a difference in adding the width/height HTML attributes to the img tag:

Shame there is no way of doing this efficiently (having a responsive image this way, but limiting the growth). Think I’ll need to read over what you’ve presented, and figure out which one I should go with.

1 Like

Ah yes well spotted :slight_smile:

I made a mistake and the rule .image Img should have had height auto added as the width was being changed in css but the height wasn’t. If you add the height auto in the css then they will be the same.

I had expected that without the height attribute the height would be enforced automatically but seems it’s treated as auto so there is a difference. However adding height auto to the css will fix it.

I probably need to update my demo now. :slight_smile:

Follow up:

I stand corrected :slight_smile:

It seems that modern browsers will treat the image as width auto and height auto if the attributes are omitted so when adding width and height attributes (as you should) you would need to set width:auto and height:auto in the css when you are just using a max-width to limit its width.

I remember testing this years ago and this was not always the case as mentioned here where IE browsers were doing something different. However modern browsers seem to agree now.

I never omit the image width and height attributes which is why I have not run into the issue since :slight_smile: (That’s my excuse anyway.)

Using max-width:100% (with width:auto and height:auto in css or html attributes omitted) will not size the image to fit the container but will reduce the size of the image if it was to overflow the container but will maintain aspect ratio although the image ends up being pretty small depending on aspect ratio and will not fit snugly in the container.

As is often the case with CSS there is always an unexpected behaviour along the way and it was good to delve into this and find the reason for the discrepancy so has been a worthwhile exercise. Thanks for the demo which made it easier to see what was going on.

All the other points are valid and indeed just adds another method into the pot. In the end there is no magic bullet because you can’t just make an image fit a container unless you crop it in someway (background-size:cover etc…). All other methods will leave a gap somewhere in the container.

5 Likes

Just getting back to this after being busy with work - don’t worry, not reigniting the thread in any meaningful way :slight_smile:

However I only just noticed IE11 loses the responsiveness to the image (view in the codepen demos I linked). Is this something that is not available in IE under a flexbox item?

IE11 has a number of bugs with flexbox and this is one of them. It doesn’t like the longhand version of flex-grow and it needs a percent unit even for zero. The following 2 changes should make it work.

.container .image {
  flex:1 0 0%;
}
.text {
  flex:1 0 0%
}
2 Likes

That does indeed make the image responsive @PaulOB, thanks! Have another problem, say if you want to reverse the text and image, there is a problem with a gap appearing on the right (because of what we had discussed throughout the thread of image scaling and aspect ratio).

I understand there is no way avoiding the gap in this situation, but is there any way to have the image positioned to the extreme right-side (so the gap appears between the text and image)?

Tried using text-align:right and justify-content:space-between properties, but no joy.

Code pen below:

You could float the image to the right.

.image img {
  float:right
}

You probably want to add a special class to the rows that have images on the right otherwise the above rule affects all the images in that context.

1 Like

I was hoping to avoid floats, just because I remember reading about needing to clear them afterwards - which is one of the main reasons of using flexbox. I might not have any choice, ah well!

Edit:
@PaulOB do you think this is something I can do (just curious whether it is valid and not hacky)?

.container > .image {
   display:flex;
   flex-direction:column;
   align-items:flex-end;
   flex:1 0 0%;
}

No that’s fine as you can make flex items become flex containers at the same time.

I just used float because it was simpler and flex containers automatically contain floats anyway. However if you want to steer away from floats you should be fine with the above.

As usual with css there are many ways to achieve the same thing.:slight_smile:

1 Like

Thanks for the reassurance. Just to keep my mind right, if I did use the float option, would I be required to clear it afterwards?

“It depends.” It depends on what follows it.

That’s quite a cryptic answer :slight_smile: Think I will just use the method I mentioned, and if I need to use a float in future then I’ll work out why/if I need to clear it.

:sweat_smile: This has came sooner than I thought. The approach I mentioned no longer makes the image responsive again in IE11. I really should have used bootstrap or some other similar framework - this really tests the patience!

lol - If you must support IE11 then that should be the browser you first test with when using flex as it has quite a few flex bugs.

The solution is just to float the image right as I mentioned earlier and that seems to work fine in IE11. There should not be an issue with float containment because flex items automatically contain floats. You can tell that because the red background still goes around the float.

.image img {
  float:right
}

No you would have many more headaches using a framework and trying to do this unless you went with the basic defaults. However as can be seen by this thread you are not going with a default behaviour for anything as such :slight_smile: so its best to roll your own.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.