Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Two lines in reset.less break the isotope library. #6541

Closed
justin808 opened this Issue · 8 comments

3 participants

@justin808

These two lines for width and height in reset.less (width & height) break the isotope javascript library. This was introduced in 2.1. What happens is that Chrome and Safari seem confused on the image size while drawing the page before the images get fully loaded. Commenting out the width and height autos below fixes the issue for the isotope library on Chrome and Safari. The issue is described here: metafizzy/isotope#335. I've verified that removing the two lines fixes the image drawing issue.

img {
/* Responsive images (ensure images don't scale beyond their parents) /
max-width: 100%; /
Part 1: Set a maxium relative to the parent /
/
NEXT TWO LINES CAUSE PROBLEMS /
width: auto\9; /
IE7-8 need help adjusting responsive images /
height: auto; /
Part 2: Scale the height according to the width, otherwise you get stretching */

Is there any CSS that can be applied to override this default for img objects? I tried setting the width and height for the images in the css, but that had no effect.

@justin808 justin808 referenced this issue in twbs/bootstrap-sass
Closed

How to override 2 lines put in by reset.sass? #276

@mdo
Owner

Unfortunately, we won't be removing those at this time. They are necessary for the responsive image feature to work, and a few frameworks I know implement them this way. If there is a better way to do them, we can discuss that, but as it stands now, there is no way to override them aside from explicit dimensions via CSS (not HTML attributes).

@mdo mdo closed this
@justin808

Would there be any way in the less framework to make this conditional? I hate monkey patching a library.

@mdo
Owner

Only option would be to override it in your own CSS (e.g., something like width: initial; or what have you). I haven't researched it much more lately, but if you wanted to dive into some responsive images CSS foo, we'd all appreciate it. Right now those lines are (sadly) required, and I know they can trip some things up.

@justin808

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.

@mdo
Owner

Yeah, the inline CSS will work where the width and height attributes fail. For now, go with that.

@cardeo

Boo inline css - any better solution for this yet?

@mdo
Owner
mdo commented

I'll try to fix this in v3. Not sure of the best practice though for everyone to implement with minimal overhead.

@cardeo

thanks, working on templates for multiple customers/users so telling them they have to inline style image width/height or throw a class on each image to make it fixed width/height isn't super appealing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.