Image lightboxing does not respect manual resizing or [grid] tags

I think that’s a perfect encapsulation of what I was thinking – that’s the only use case where you wouldn’t want a lightbox, isn’t it: when the image is either more “part of the text” or “part of the post’s formatting”.

I think that’s a better solution overall – to separate the “lightbox images above the size […]” out into its own setting with a much lower default. It would make sense for it to differ from the current implementation in two further ways:

  • It should judge by the size on the page, as opposed to the original size of the image.
  • It should probably need to exceed both dimensions, as opposed to just one – I can’t quite picture a use case where you would want an image that’s, say, 690×10 pixels (on the page) to be lightboxed.

As a note on use cases, I sometimes include small images in an emoji-like fashion – but they’re high-resolution, so that they won’t be blurry on high-DPI screens. For example: ! This image should not be lightboxed, since 1) it’s an emoticon, but more importantly, 2) the little expansion icon in the bottom right corner would cover up most of it on mobile. At present, it isn’t lightboxed because the high-res original image is below 690×500 pixels in size (372×468 pixels, to be exact), but it shouldn’t be lightboxed despite having been scaled down – the truly salient criterion to judge by is what its size is on the page.

1 Like