Page MenuHomePhabricator

enhancement of thumbnails
Closed, DeclinedPublic


Author: dunc_harris

The current thumbnail system as far as I can tell only works with width e.g.
250px (which is default). This is good for portrait images, but not good for
landscapes, particularly panoramas, etc, as it renders them too small. Making
them larger makes viewing difficult for smaller resolution screens.

What I propose therefore is an option to put in addition to the pixel width, a
percentage width option, so 100% would display a panorama photo across the width
of the page, 50% across half, for all screen resolutions.

e.g. in the form

[[image:woof.jpg|thumb|right|50%|dogs bark]]

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:57 PM
bzimport set Reference to bz495.
bzimport added a subscriber: Unknown Object (MLST).

This isn't feasible; the window width can't be obtained easily and is too variable. If we rendered thumbnails at 50% of *every* visitors's browser, we
would DoS our own servers trying to accomodate every browser configuration. It would also destroy the caching system and increase server load
simply loading every page extra times to check with the client what its size is.

If we tried to stretch the image in the browser, it would look terrible which defeats the purpose of thumbnailing.

dunc_harris wrote:

I was principally thinking of some of the panoramic photos, which would only
appear in a certain percentage of articles; we could use guidelines to keep the
thumbnails within a reasonable byte size, or perhaps something in the syntax,
e.g. maxwidth=700px or something.

Guidelines don't require software changes, and you can already set the width of a given thumbnail. Closing again.

robchur wrote:

*** Bug 6605 has been marked as a duplicate of this bug. ***

robchur wrote:

*** Bug 7003 has been marked as a duplicate of this bug. ***

  • Bug 10107 has been marked as a duplicate of this bug. ***
  • Bug 14785 has been marked as a duplicate of this bug. ***