Last modified: 2014-05-30 13:26:25 UTC
The current gallery code includes a lot of padding around the images (inside each single-image boxes; not counting the margin between boxes). Simply allowing the images to fit the corresponding boxes would already be a great improvement (since the default gallery size, e.g. in category pages, is often insufficient to discern the details of non-closeup images). However, ideally the screen space used by images should be maximized, producing a tightly packed page with most of the space dedicated to the images, rather than whitespace. This is how Flickr and Google+ do it, for instance: - https://www.flickr.com/search/?text=kittens&sort=interestingness-desc - https://plus.google.com/photos/+ThomasHawk/albums/posts It's not hard to do this for a fixed gallery width (just adjust the image widths so the heights are the same), and indeed this is implemented on Wikipedia: https://en.wikipedia.org/wiki/Template:Auto_images That approach would be a great improvement, but it doesn't handle different screen sizes which would different row widths to be effective (e.g. in category pages). Fortunately, there's already solutions to that. Here's a link explaining how to implement a dynamic gallery in this way: http://www.techbits.de/2011/10/25/building-a-google-plus-inspired-image-gallery/ And here's a demo (try resizing the page): http://fmaul.de/gallery-grid-example/
A couple links that may be useful: - http://speckyboy.com/2013/07/15/15-jquery-plugins-for-creating-dynamic-layouts/ - https://en.wikipedia.org/wiki/Bin_packing_problem
What about implementing bug 35756 so that the images fill their specified bounding box?
(In reply to C. Scott Ananian from comment #2) > What about implementing bug 35756 so that the images fill their specified > bounding box? Thanks, I didn't know about that one. I'll add it in the see also field. The approach is interesting but not ideal, since that would crop images so they fit the square shape. When you said "fill their specified bounding box" I thought you meant just removing the square padding that currently is added in galleries and category listings (I have no idea what the purpose of that space is, considering that the bounding boxes are already separated from each other with white space). When I say not ideal, I mean that it's rather tricky to ensure tat the crop indeed shows the core elements of the image. Some smart cropping (or even [[seam carving]]) would have to be made (e.g. see http://www.croppola.com, http://cropp.me, and Reddit's thumbnail generation code: r2/r2/lib/scraper.py#L57-84">https://github.com/reddit/reddit/blob/a6a4da72a1a0f44e0174b2ad0a865b9f68d3c1cd/r2/r2/lib/scraper.py#L57-84 ) I'd much rather the approach proposed in comment #0, which would not only preserve all the content of the images but would also make the galleries more dynamic and visually interesting. Still, I think a first step could be removing the wasteful padding of the current bounding boxes; that would be fairly simple to do. Since bug 30270 seems to refer to something slightly different (outer padding/margin, rather than inner padding), I'll probably open a different bug for this.
I have no idea what Bugzilla attempted to do to the github url. Let me try again: r2/r2/lib/scraper.py#L57-84">https://github.com/reddit/reddit/blob/a6a4da72a1a0f44e0174b2ad0a865b9f68d3c1cd/r2/r2/lib/scraper.py#L57-84
Yup, definitely a bug in Bugzilla.
Offtopic: The "r2" triggers some broken regex in https://git.wikimedia.org/blob/wikimedia%2Fbugzilla%2Fmodifications.git/HEAD/extensions%2FWikimedia%2FExtension.pm#L44 for Bugzilla rendering. I've put the URL in the URL field above instead.
