Using Twitter Bootstrap 2.0 versus 2.1 and specifying images sizes with Isotop

Question

Something changed in Twitter Bootstrap between 2.0 and 2.1 that precludes the simple specification of image sizes when using the awesome Isotope image library and requires the user of the alternative techniques of $(window).load or $container.imagesLoaded to draw correctly (http://isotope.metafizzy.co/docs/help.html). The bug seen is that the vertical height of the images specified seems to be ignored and the images are overlapping. Changing to the alternative forms that wait for images to get loaded results in a far worse experience in terms of flickering and paint issues. I ended up going back to Bootstrap 2.0.

I confirmed that issue was introduced with 2.1 of bootstrap. You can find the change history of bootstrap here: https://github.com/twitter/bootstrap/wiki/Changelog

Does anybody know what changed in 2.1 that probably caused this breakage and if there's any good workaround. As mentioned above, waiting for the images to load is FAR worse than just putting in the image heights and widths, so that is not really a workaround.

Answer 1

I posted the answer here: https://github.com/twitter/bootstrap/issues/6541

Inlining this in the CSS worked, like this: img src="blah-blah" width=398 height=265 style="width:398px; height:265px"

In fact, I also tested Isotope without using the width and height attributes, like this: img src="blah-blah" style="width:398px; height:265px"

And that worked fine! Any recommendation if it's better to only specify the CSS?

I was able to very easily test this without bootstrap (or bootstrap 2.0) by using this CSS: img { width: auto; height: auto; }

It seems that the width and height in the CSS do override the image properties, and before the images get loaded, the browser does not know how much space to allocate, and then, even after the images load, the spacing is still wrong, at least with Isotope. Inlining the style does workaround the issue. I think I tried using regular styles, but that didn't seem to work, but I may have had a CSS priority issue. Any way, since the image size is laid out with the image properties, it's rather natural to put in this tiny bit of inline CSS. I hope we eventually find a better solution, as this will surely affect others when upgrading.

Or at least this should be documented that one needs to use the inline style for the width and height of the image rather than the properties.