Is there any reason why small images don't have thumbnails?

When large images are made smaller than their full size, they get a preview thumbnail that can then be expanded, like so:

But if we have an image like this:



it does not get a thumbnail:

This forces poster to do one of the following:

  • Make image into a link, which inconveniently opens a new tab when reader goes to view image
  • Make the image big on the post, which can detract from what’s supposed to grab readers’ attention and needlessly wastes space
  • Hope readers realize they can even view a larger version on images that are borderline visible through squinting
  • Give up after dealing with this for a while and hope readers know how to view a larger version (my personal favorite)

Is there a reason smaller images don’t get thumbnails when they’re displayed at a smaller resolution than their actual size? I wouldn’t think it’s performance related, as this is done with much larger images.

Er… what? If the image is actual size, it is displayed as actual size. So you think this image…

… should have a “CLICK ME TO EXPAND TO FULL SCREEN!” option?

I don’t agree.

2 Likes

I would prefer all images be expandable. Often the small images are the ones that need to be expandable so you can see detail. There is also the consistency/predictability issue.

We have no plans to implement this and it is not on our roadmap for the foreseeable future. I also think it’s a terrible idea.

2 Likes

They are - using the browsers zoom.
It could be argued that if detail would be compromised by a zoom that the image shouldn’t be that small to begin with, no?

Well on mobile (>50% of users) for Android Chrome the zoom is not enabled by default (and it’s under Accessiblility so I had never tried it until now).

Most users might instead just violently poke their mobile screen (like I have been) wondering why this image behaves differently than others.

Also wondering if the different behavior for small images will affect other gallery or lightboxing features.

The problem of not being able to educate user to “enable force zoom” has come up before along with the why is this different issue

I guess I dont understand the violent opposition. If someone doesn"t want or need to see the expanded image/caption/download link, just errr, don’t click on it. In addition the image doesn’t appear differently pre-click so it’s not really a cosmetic issue.

If I want to do this , you’re gonna take that from me?

Rude :wink:

2 Likes

Are we talking about the same thing? The black bar that pops up when mousing over an image that’s smaller than its actual size (it doesn’t pop up if the displayed image equals the uploaded size)? If so, can you explain how that’s a bad thing? I’m not seeing how adding a black bar to an inappropriate image would make the black bar itself inappropriate, and I imagine the expansion itself is fine because it has to be manually expanded by the user.

I can definitely understand why that image would be unwanted, but I fail to see how it relates to expansion – this is a community problem which is resolved via community flags. The expansion option itself on such an image doesn’t negatively impact the community at all.

I would think it would be more appropriate to generate thumbnail by display size instead of uploaded size. Say I display a larger image as an emote right now:

It gets the expansion option, which doesn’t make a whole lot of sense. If instead of choosing to create a thumbnail by uploaded size, it did so based on the largest size (between width and height) of the displayed image, emotes wouldn’t be given thumbnails.

In the case where users have edited the display size down with explicit HTML, sure, thumbnailing should be suppressed. That is a bit of an explicitly malicious user action more than anything else, though.

If the image fits in the post width, it uses actual size and always has.

I’m referring to scaling down images with explicit HTML so that they don’t take up too much space / draw more attention than desired. In the case of the OP, note the second image. It’s kind of hard to distinguish from the actual post, and makes it overall harder to read, but the third (scaled down second) is easy to distinguish immediately – there’s definitely a valid use for scaling it down in this case. However, I still want users to expand the image and see it in its entirety, but it doesn’t have a thubmnail so that’s not possible without inconveniently changing pages / opening a new tab.

Inline image clearly should not have the onebox treatment in my opinion but… there are a lot of complicating factors around thresholds for on-a-line-by-itself images.

For example, this image, will never get a lightbox treatment:

Even if I hardcode it down to 100x100

Personally, I think it is fine to show lightbox for any image over 200x200 that is not inline, with a site setting to adjust threshold.

8 Likes

This seems, to me, to be the right thing to do. Users are unaware of the rules regarding the oneboxing feature and it is sort of hard, as an administrator, to explain the nuances to users that struggle technologically.

What is the current threshold for this? I have a 576x421 image (fairly large), and it is not getting lightboxed.

I was just looking for this myself, I wish it was at least an option so that images in posts had a unique wrapper.

I have a use case where one of the themes available is for obfuscating what you are viewing (at work, in public, etc. Think GhostZilla) that uses the lightbox wrapper to CSS target post images and hide them until you mouse over.

a.lightbox img {visibility:hidden};
a.lightbox {background-color:#eeeeee;}
a.lightbox:hover img {visibility:visible;}
a.lightbox:hover {background-color:transparent;}

a #site-logo {visibility:hidden};
a:hover #site-logo {visibility:visible};
header div.title a {background-color:#eeeeee;}
header div.title a:hover {background-color:transparent;}
a.main-avatar img.avatar {visibility:hidden !important;}
a.main-avatar {background-color:#eeeeee !important;}
a.main-avatar:hover img.avatar {visibility:visible !important;}
a.main-avatar:hover {background-color:transparent !important;}
.posters a img.avatar {visibility:hidden !important;}
.posters a {background-color:#eeeeee !important;}
.posters a:hover img.avatar {visibility:visible !important;}
.posters a:hover {background-color:transparent !important;}
.topic-poster a img.avatar {visibility:hidden !important;}
.topic-poster a {background-color:#eeeeee !important;}
.topic-poster a:hover img.avatar {visibility:visible !important;}
.topic-poster a:hover {background-color:transparent !important;}