The Squash, Part Two (expand content images w/ JS)

[nfagerlund]

In a bunch of styles, I added some CSS to shrink user-provided images (while preserving aspect ratio), so they don't overflow their container (or the viewport) too badly.

I think that's been mostly a win, but it's not a universal win; sometimes you want to see the whole image and don't mind if it blows out the page, and sometimes the image shouldn't be shrunk in the first place. (The latter is mostly just vertical comic strips like Questionable Content, which run afoul of the default behavior of "a portrait-orientation image should fit on one screen" -- if it's split into panels, it's actually a bunch of images anyway, so that doesn't make sense.)

We've been sharing some CSS hacks to work around that, but I think we can do better by adding a little JS-powered "expand/shrink" widget next to every image in user-provided content. That's the sort of fix that's impossible for users to provide in their own journals, but trivial to do sitewide.

Design problems to solve:

• Definitely need to exclude userhead icons, poll bar graphs, and a variety of other things that are really more like UI elements than figures. This can also include things like stitched-together frame images in posts where someone went hogwild with decorative HTML. (At least post-content/comment-content areas are well-marked, so it's easy to not mess with the rest of the page.)
• Ideally, only images that actually shrank should get the expand/shrink button. But how to detect that?
  • Most users don't provide height/width attributes when posting images, so info about the actual image dimensions isn't available at the time of DOMContentLoaded.
  • When the dimensions of the window change, that can shrink new images or unshrink ones that were shrunk.

So, a naïve implementation is pretty easy, but I want to think about this a bit more to see if we can get something that feels simple but avoids wacky side-effects.

---

Being selective about what we shrink is also an interesting idea (e.g. detecting really long skinny pics), but IDK if it's feasible yet and it wouldn't solve the entire issue anyway, so never mind that for now.

[nfagerlund]

A good start is to compare HTMLImageElement.naturalWidth / naturalHeight with the standard width/height properties. (Can't do that until the load event, of course.) That leaves the question of how and where to handle window size changes.

[nfagerlund]

If resize observer was a thing yet, I’d have it made in the shade, but no.

[nfagerlund]

Hmm, also remember that new images can be added via cut tag or expand comment.

[nfagerlund]

I thought of a more parsimonious option: Only target images that aren't inside links.

@supports (object-fit: contain) {

.entry-content img, .comment-content img {
  cursor: zoom-in;
  /* ...existing rules */
}
.entry-content img.expanded, .comment-content img.expanded {
  cursor: zoom-out;
  height: auto;
  width: auto;
  max-width: unset;
  max-height: unset;
  object-fit: unset;
}
.entry-content a img, .comment-content a img {
  cursor: unset;
}

}

$(document).on('click', '.entry-content img, .comment-content img', function(e) {
  if (! e.target.matches('a img') ) { // modern-ish, but anything that doesn't support it definitely doesn't support object-fit anyway, so it's fine.
    $(e.target).toggleClass('expanded');
  }
});

[nfagerlund]

Testing that out at http://sheworks4themoney.rr-thrice.hack.dreamwidth.net/2802.html

[nfagerlund]

So now I need more test cases, and also a list of all the types of images within post bodies where we WOULDN'T want to offer a zoom click. Already excluding:

• Any image inside a link. (Catches userheads, etc.) I'm assuming that for an image you'd want to expand, if it's in a link then 90% of the time it's linking out to a bigger version of itself, probably on a flickr or gphotos page (or DW media).
• Poll results.