1138482 - wired.com images overflow their "cards", when window size is < 650px

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[stuart robson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150302004030

Steps to reproduce:

Went to - http://www.wired.com/2015/03/our-new-site/ - with a FF Dev Edtion (38) with a viewport size of < 650

The images have a max-width: 100% and some containers use flexbox and have display: flex; on them, those break. Issue with display: flex;


Actual results:

The img breaks out of the container near the bottom of the page


Expected results:

The image should stay within the container

Comment 1

[Daniel Holbert [:dholbert]]

I can reproduce this -- with a viewport width of 600px, there's a "More Design" section that shows up at the bottom, and the images (e.g. a concentric-circles-zebrastripe image) stick off the right edge of their bordered area, & off the right edge of the viewport if your viewport is small enough.

This is yet another instance of bug 1043520. More details to follow. tl;dr: the img's parent (.card) needs a "min-width: 0" declaration, to allow it to shrink to be skinnier than its min-content width (the img's intrinsic size).

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce this on the wired.com front page, too ( http://www.wired.com/ ), in Firefox release version.

Reclassifying as "mobile" since this only affects mobile-ish browser sizes (< 650 px).

Comment 3

[Daniel Holbert [:dholbert]]

So what happens here is, we have 2 nested flex containers.

 <div class="flex-row">
   <div class="card col big-col-18 med-col-18 sm-col-18 mob-pad">
     <img>

The "flex-row" element is a flex container. The "card" element is a flex item. As discussed in meta-bug 1043520, flex items have a new "min-width:auto" behavior, which makes them refuse to shrink smaller than their intrinsic size -- which in this case is the width of the image.

So, "card" refuses to shrink to be smaller than the image's width, which happens to be 600px.

(The image does have "max-width:100%", but that doesn't help; all it does is prevent the image from being wider than its parent, which is 600px (sized to its child) as discussed above.)

The fix here is to give the img's parent a "min-width:0" style rule, so that it can shrink to be less than the intrinsic width of its img-child. That gives the img's "max-width:100%" something useful to actually resolve against.

Not sure how the site's style is structured, but this could go into any rule that's targeting that <div>. It probably belongs either in the ".article-group .card" rule (which is where the site sets "width:auto"), or in the ".flex-row .col" rule (which is where the site sets "flex:auto").

This only looks like a Firefox-specific issue because Chrome/Safari haven't implemented "min-width:auto" as the new default value yet (so these elements just have "min-width:0" by default there -- which means this hackaround won't affect behavior there, which is good). The chrome bug for that is https://code.google.com/p/chromium/issues/detail?id=426898 .

Comment 4

[Daniel Holbert [:dholbert]]

[Sorry -- I misspoke at the beginning of comment 3 -- there's no nesting of flex containers going on. I'm reposting my explanation w/ that fixed to clarify:]

So what happens here is, we have a flex container, with the img as a grandchild, like so:

 <div class="flex-row">
   <div class="card col big-col-18 med-col-18 sm-col-18 mob-pad">
     <img>

The "flex-row" element is a flex container. The "card" element is a flex item. As discussed in meta-bug 1043520, flex items have a new "min-width:auto" behavior, which makes them refuse to shrink smaller than their intrinsic size -- which in this case is the width of the image.

So, "card" refuses to shrink to be smaller than the image's width, which happens to be 600px.

(The image does have "max-width:100%", but that doesn't help; all it does is prevent the image from being wider than its parent, which is 600px (sized to its child) as discussed above.)

The fix here is to give the img's parent-div "min-width:0" in some style rule, so that it can shrink to be less than the intrinsic width of its img-child. That will then give the img's "max-width:100%" something useful (and not-too-large) to actually resolve against. I'm not sure how the site's CSS is structured, but this could go into any rule that's targeting the img's parent-<div>. It probably belongs either in the ".article-group .card" rule (which is where the site sets "width:auto"), or in the ".flex-row .col" rule (which is where the site sets "flex:auto").

This may *appear* to be a Firefox-specific issue, but that's only because Chrome/Safari haven't implemented the spec change that introduced "min-width:auto" as the new default yet (so these elements just have "min-width:0" by default there -- which means my suggested "min-width:0" hackaround won't affect behavior there, which is good). The chrome bug for that is https://code.google.com/p/chromium/issues/detail?id=426898 .

Comment 5

[Daniel Holbert [:dholbert]]

I reached out to them on Twitter: https://twitter.com/CodingExon/status/572520365143932928

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug & fix

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug

Comment 8

[Karl Dubost💡 :karlcow]

(In reply to Daniel Holbert [:dholbert] from comment #1)
> This is yet another instance of bug 1043520.

Did I track mine at the wrong place or do we need to do a massive grouping.
See Bug 975632

Comment 9

[Daniel Holbert [:dholbert]]

I don't think this has any connection to bug 975632, really.

Comment 10

[Karl Dubost💡 :karlcow]

Making a fool of myself. Sorry for the noise Daniel. :) I read too quickly.

Comment 11

[Mike Taylor [:miketaylr]]

I just noticed http://www.wired.com/2015/03/wired-dot-com-from-the-devs/ and see that Ross Patten is listed as working on FlexBox. I'm going to email his address from his GitHub account.

Comment 12

[Daniel Holbert [:dholbert]]

Ross says the he's reproduced the bug & "the fix will go up in our next build". Woot!

Comment 13

[Daniel Holbert [:dholbert]]

Verified fixed!

Cards no longer overflow, and devtools show that the ".col" rule now has "min-width:0".

Comment 14

[Mike Taylor [:miketaylr]]

Awesome turnaround, thanks to wired.com and Daniel. :)

Comment 15

[Daniel Holbert [:dholbert]]

(Thanks to stuart for filing, too!)

Comment 16

[Hallvord R. M. Steen [:hallvors]]

https://twitter.com/MozWebCompat/status/573332700486086656 :)