Page MenuHomePhabricator

let me size inline images to max-height, with variable image-sets including client-side reduction, fix the forced "quirk-mode" of mobile view
Open, LowestPublicFeature

Description

(See also comment 3 in
https://bugzilla.wikimedia.org/show_bug.cgi?id=65883)

We need inline imags in various cases, including where text is dificult to render and an alternate SVG could do the trick, or for displaying small icons (including emoticons and similar icons meaning "Done", "Yes", "No", "Approve"...

However images are currently only supported with static sizes in pixels which do not fit well with the current font size and line-height. Using them inline causes layout problems within paragraphs as these images do not scale cleanly.

HTML offers a clean way to support this using client-side resizing, and it is already used in the Mobile view of our wikis, whose stylesheet uses:

max-width:100% !important;

This causes the browser to rescale the image itself in order to not exceed the specified max-width, even if the image itself has a larger width. This CSS rule however is used with a trick that forces changing the "box-model:" of all block elements from the HTML standard "content-box" to "border-box" (like in old versions of Internet Explorer, or in browsers emulating the "IE quirks mode"), and this breaks lots of pages containining a layout of block elements with non-zero borders or paddings. In my opinion, this change of box-model is a severe bug of the stylesheet used in the Mobile view.

However this stylesheet demonstrates that clients (anot notably all mobile clients such as smartphones and tablets) are perfectly capable of rescaling images themselves to fit in a maximum width (or height).

Here I'm interested to use

max-height: 1.5em;

for rescaling an inline image cleanly to fit within a specified matching line-height:1.5.

However MediaWiki images created with [[Image:...]] or [[File:...]] still do not allow us to add other styles (all styles are generated, as MediaWiki will transform the image by using an <img> element, within an <a> element, itself within a <div> element with custom classes for "block" images using "left/right/center/thumb").

Even with "block" images we would like to have images more easily scaled to fit a relative size according to the container, using "max-width:" and "max-height:" with a percentage of the container's width (normally it is the width content-box of the container, unless the box-model has been changed to emulate the IE-quirks mode), or in a size equal to a given number of text lines (if we know the line-height, this means a "max-height:" for the image set as a multiple of the line-height (on MediaWii the default line-height is 1.5).

Images howver have only a static sizing parameter in pixels (from this size, MEdiaWiki generates an image set whose first image by default uses this size for "width=" and "height=" attributes associatd to the "1x" resolution, and also maps other sizes to "1.5x" and "2x")

What I'd like:

  • (1) supporting max-width= and max-height= parameters in [[Image:]] or [[File:]], with sizes given in "em" and not necessarily in pixels. This item is also needed for proper internationlization where text cannot be used and an image is needed.
  • (2) supporting another range of scaling values for the image sets (currently: 1x, 1.5x, 2x) with a parameter "scales=", to allow changing this set to support other values lower than 1x (notably 0.5x and 0.75x), or even "native" (only works with SVG images) in order to allow cleaner reductions by the browser, instead of growths (used by browsers whose "logical pixel" resolution is lower than the effective display resolution, notably on smartphones (this grately impoves the readability and sharpness of images. Habing additional values "0.5x and 0.75x" would also allow cleaner client-side reductions of sizes constrained by max-width and/or max-height. This item is also needed for readability/accessibility (including the support of custom zoom levels in browsers, and adaptation to small screen sizes and screens with very high resolutions)
  • (3) dropping the forced change of box-model in the Mobile view. This breaks lot of page. The default HTML should be restored. Without it, is is impossible to have a coherent layout between the mobile view, and the desktop view that assumes the default "box-model:" to be "content-box" (which has alsays been the standard in HTML4 and still today in HTML5, except in old versions of IE). Som of our templates will still want to be able to use "box-model:" but it should not be controled by the site-wide stylesheet of the Mobile view that forces it on ALL elements, breaing the inheritance cascade. This item is needed to offer compatibility of pages layouts and templates between desktop and mobile views.

All these items are independant but they work together.


Version: 1.24rc
Severity: enhancement

Details

Reference
bz66896

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 3:27 AM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz66896.
bzimport added a subscriber: Unknown Object (MLST).

Hi, can you please provide

  • steps to reproduce
  • expected outcome
  • actual outcome

in seperate paragraphs?
(The more structured your ticket, the more likely somebody might take a look at it.)

Furthermore, separate requests should be in separate issues. Also see https://www.mediawiki.org/wiki/How_to_report_a_bug - Thanks!

"Please answer" to my own comment ? You want details but everything is in my comment 1. And you do not ask for more specific details.

For now the "!important" tag in the max-width style for images is clearly a severe hack that breaks pages. We should never use these tags in CSS; simply because it is then impossible to design a page lyout that works correctly in BOTH the mobile view and the desktop view. The "!important" tag breaks every attempt to make something compatible between the two views.

(The other tweak used in the mobile view is to force another box model from the standard content-box to the border-box blindly without knowing really on what it will apply on pages. These two tweaks in fact have severe consequences: some pages will NEVER work on the desktop virw, some other will NEVER work in the mobile view, and we are forced to duplicate wiki pages with a mobile version and a desktop version, a complete non-sense to maintain and an extra complexity as each view mode will require its own separate sets of templates)

So all I can say is what I already summarized:

(1) support max-width/max-height parameters for images and DON'T override them by the "!import" CSS tweak for the mobile view (at least provide a way so that this override can be disabled; it should be disabled completely if the image provides itself the max-width parameter in the Wiki source of the [[File:]] or [[Image:]] tag).

(2) support extra sets of scaling factors

(3) drop the "!important" tweaking tags in the site-wide CSS for the mobile view.

These are effectively three things to changes but for the sam final purpose: creating pages that work correctly on mobile views, WITHOUT breaking the desktop view. As long as this does not work, everyone in wikimedia projects will continue designing for the desktop, and the mobile view will be unreadable/inaccessible, with broken layouts.

You've still not asked anything else more precise, so what do you want I confirm?

No, I did not ask for any confirmation and I did not ask for details. See comment 1 again. I asked for a structured bug report which will likely receive more attention than a wall of text.

Unfortunately closing this report as no structured comment has been provided.
Please feel free to reopen this report if you can provide the information asked for (see comment 1) and if this still happens. Thanks!

REOPEN THIS RFE: the subject was extremedly clear (the rest was a rational for the need) because we need it for CORRECT scaling of inline images (used within paragraphs of text) for correct alignment and correct readability.

  • (1) supporting max-width= and max-height= parameters in [[Image:]] or [[File:]], with sizes given in "em" and not necessarily in pixels. This item is also needed for proper internationlization where text cannot be used and an image is needed.
  • (2) supporting another range of scaling values for the image sets (currently: 1x, 1.5x, 2x) with a parameter "scales=", to allow changing this set to support other values lower than 1x (notably 0.5x and 0.75x), or even "native" (only works with SVG images) in order to allow cleaner reductions by the browser, instead of growths (used by browsers whose "logical pixel" resolution is lower than the effective display resolution, notably on smartphones (this grately impoves the readability and sharpness of images. Habing additional values "0.5x and 0.75x" would also allow cleaner client-side reductions of sizes constrained by max-width and/or max-height. This item is also needed for readability/accessibility (including the support of custom zoom levels in browsers, and adaptation to small screen sizes and screens with very high resolutions)

item (3) was a follow-on. Item (1) being the MOST important one.

Both are within the support of parameters for [[Image:]] or [[File:]] and how they are parsed and generate the suitable HTML/CSS code (the related support for the MediaViewer, only when clicking on the image to view it outside its inline use, is unrelated)

Without explaining the rationale, you would simply have not understood the need for it.

If you're still not convinced try navigating pages containing inline images (most often, small icons such as country flags, or small SVG images needed to replace text when it does not work to show an appropriate representative glyph, for example with character variants) with various sizes of displays an with accessibity zoom enabled (not everyone uses the default 100% zoom especially with small screens and on displays with very high resolution such as smartphones and tablets: in almost all cases these default zoom levels can ONLY be used by the youngest people without any visual problem. Most people about 40yo need to increase the text. But online icons DO NOT scale properly, or are simply UNREADABLE.

@Andre I DID have provided the detgails several times. Sorry if you don't want to read them.

Your status "Resolved" was clearly wrong, NOTHING was solved

Your status "Work for me" was also completely wrong, it has NEVER worked for any one

Resetting priority to reflect reality - feel free to increase priority when you plan to work on a patch to support this functionality.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:14 AM
Aklapper removed a subscriber: wikibugs-l-list.