Last modified: 2011-11-29 21:59:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T9048, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7048 - allow 'em' and 'ex' image sizes
allow 'em' and 'ex' image sizes
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 8429 9409 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-08-18 00:44 UTC by David Millet
Modified: 2011-11-29 21:59 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Patch to allow image em and ex sizes in wiki pages (7.80 KB, patch)
2006-08-18 00:45 UTC, David Millet

Description David Millet 2006-08-18 00:44:08 UTC

I've written a patch that enables em and ex image sizes to be used in a wiki, if
and only if '$wgAllowEmExImageSizes = true' is set in LocalSettings.php.  As
more and more people are interested in putting wikibooks and wiki pages into
print and pdfs, it is very helpful to have images with sizes set by the client
relative to the font size.  The downside is that clients will sometimes download
large images that are print ready; nonetheless, at the Blender wiki, we believe
this functionality will make it much easier for us to get our documentation to
print quickly.

I hope you like the patch
Comment 1 David Millet 2006-08-18 00:45:45 UTC
Created attachment 2243 [details]
Patch to allow image em and ex sizes in wiki pages
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-29 20:28:45 UTC
*** Bug 8429 has been marked as a duplicate of this bug. ***
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-29 20:30:15 UTC
The essential problem here is that we don't use client-side resizing.  Because
it's horrible.  We use server-side resizing, and the server has no idea what an
em is in the context that the image is used.
Comment 4 Brion Vibber 2006-12-29 22:12:27 UTC
Note that the use of em or ex sizes is not really related to provision of
higher-resolution printer-friendly images.

A "pixel" in CSS/HTML doesn't actually refer to a literal pixel on the output
device, but is a logical unit. (Though it generally does correspond to a pixel
for on-screen rendering today).

I'm closing this as WONTFIX since em/ex sizes really just don't fit well with
what makes sense for web-friendly rendering unless you move to an all-vector or
who-cares-about-bandwidth world.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-25 00:39:17 UTC
*** Bug 9409 has been marked as a duplicate of this bug. ***
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-01-04 00:04:51 UTC
Changing to LATER: we may want to reconsider at some point if either clients reliably support good image scaling, or if we start serving actual vector images instead of rasterized versions.
Comment 7 Erwin Dokter 2009-01-04 00:39:57 UTC
"...we don't use client-side resizing..." Not quite true; GIF thumb generation has been turned off recently. But I hope that gets re-enables real soon. 
Comment 8 Brion Vibber 2011-11-29 21:59:35 UTC
Modern browsers are much better at client-side scaling, and we may well end up shipping more SVG and intermediately-sized images in the future.

But, em and ex aren't really as needed as they used to be. Modern browsers' zoom capability zooms images and other elements as well as text; '100px' is actually a logical size that's more consistently portable to use than '6em' or something.

I'm going ahead and resolving as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.