Page MenuHomePhabricator

VisualEditor: Be able to set an item's size in upright terms in the media edit dialog
Open, MediumPublicFeature

Description

Moved out of bug T40129's wishlist into its own bug.


Version: unspecified
Severity: enhancement

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:52 AM
bzimport set Reference to bz62671.

The parsoid plan is to support only square bounding boxes.

Unfortunately, PHP core doesn't have a way to specify 'a square bounding box of the default thumbnail size' yet. So for purposes of discussion let's assume there's a wikitext option named 'thumbscale' which enforces a square bounding box of (an appropriate factor of) the default thumbnail size (then quantized to nearest 10px, like upright does, in order to avoid creating lots of odd-sized thumbs).

So Parsoid will *only* generate wikitext of the form:

[[Figure:Foobar.jpg|200x200px]]
or
[[Figure:Foobar.jpg|thumb|thumbscale=1]]

We will attempt to round-trip other wikitext forms ('upright', 'x200px', 'thumb' by itself (which is a width restriction only), etc) if the image is not edited. But if the image is edited, we will emit only a square bounding box.

In the short term, we might use:

[[Figure:Foobar.jpg|thumb|upright=<number>]]

as an approximation to the 'thumbscale' factor, where we compute <number> as <aspect ratio>*<thumbscale>. But this is viewed as a short term hack only.

The VE UI should present this as something like 'use default thumbnail size', rather than explicitly mentioning the 'upright' parameter.

(In reply to C. Scott Ananian from comment #1)

Parsoid will *only* generate wikitext of the form:

[[Figure:Foobar.jpg|200x200px]]
or
[[Figure:Foobar.jpg|thumb|thumbscale=1]]

That seems bad. [[Figure:Foobar.jpg|200px]] is vastly-preferred and [[Figure:Foobar.jpg|200x200px]] is considered broken wikitext except in rare cases.

Related: https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes

We could encourage users to use a limited set of pre-defined scaling factors. This could potentially let us handle some user pref based scaling in CSS instead of JS.

For now the plan is to add a data-mw.scale factor which corresponds to a default-sized image. If the format is 'thumb' or 'frameless', the default image size is given by a *square bounding box* of the default thumb size.

(In reply to James Forrester from comment #2)

That seems bad. [[Figure:Foobar.jpg|200px]] is vastly-preferred and
[[Figure:Foobar.jpg|200x200px]] is considered broken wikitext except in rare
cases.

We could also omit this if we don't care about size stability on image aspect ratio change. Alternatively we could also change the default behavior to use a square bounding box. Lets make that decision when we get there. For now we'll just use upright.

200x200px is what we already emit. That's been the case for a while.

Current thinking is that the new PHP image option will be called 'scale' (not 'thumbscale'), and that parsoid will mark its use with a 'mw-scale' class on the image wrapper, not a data-mw attribute.

Mm. Now I'm thinking the mw option might be square so that Parsoid emits:

[[Figure:Foobar.jpg|200px|square]]
[[Figure:Foobar.jpg|thumb|square]] <!-- equivalent to upright=1 -->
[[Figure:Foobar.jpg|upright=0.5|square]]

That would provide the same functionality but address James' concern in comment 2.

(In reply to C. Scott Ananian from comment #6)

Mm. Now I'm thinking the mw option might be square so that Parsoid emits:

[[Figure:Foobar.jpg|200px|square]]
[[Figure:Foobar.jpg|thumb|square]] <!-- equivalent to upright=1 -->
[[Figure:Foobar.jpg|upright=0.5|square]]

That would provide the same functionality but address James' concern in
comment 2.

I'm not a fan of adding more work-arounds that modify older work-arounds. If we can fix this up cleanly with something like scale & square bounding box by default then we should do so IMO. That would result in cleaner wikitext like this:

[[Figure:Foobar.jpg|200px]]
[[Figure:Foobar.jpg|thumb]]
[[Figure:Foobar.jpg|scale=0.75]]

An automatic conversion that preserves existing image sizes is very much possible if the community agrees that going for a square bounding box by default makes sense. But again, lets not get ahead of ourselves to much here & focus on the Parsoid interface for now.

One point about the upright parameter is that it does something sensible with a portrait image by default without the user having to think about what scaling factor he wants to use. The scale parameter per se is a good thing to have, but being forced to calculate a scale factor to get the equivalent of the old upright parameter is a step backwards in my opinion (its a step forward from the current two-steps-backward position of not having anything at all but is still a step backwards from what we had before.)

(In reply to Spinningspark from comment #8)

One point about the upright parameter is that it does something sensible
with a portrait image by default without the user having to think about what
scaling factor he wants to use. The scale parameter per se is a good thing
to have, but being forced to calculate a scale factor to get the equivalent
of the old upright parameter is a step backwards in my opinion (its a step
forward from the current two-steps-backward position of not having anything
at all but is still a step backwards from what we had before.)

I think you're making assumptions here. :-) The idea was that we'd default to the usual value of 75% (and make it clear that this is the preferred value).

Jdforrester-WMF lowered the priority of this task from High to Medium.Jan 9 2015, 10:55 PM

So the blocking status for T64666 is a little misleading here. AFAIK, Parsoid parses the 'upright' option properly, and emits DOM with the correct size set.

But we're not clear at all that we want to support *authoring* images with the 'upright' option, because we'd rather deprecate that option and replace it with something better.

So, can we reset the discussion a little bit: what is the *current* behavior when you edit an image which has the 'upright' option. What (if anything) is actually broken?

A user on frwp explains that having a number of pixels instead of an upright (configurable) is an accessibility problem.

The upright option suffers from some severe problems. Consensus was reached on replacing it, see https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes -- unfortunately, the replacement agreed upon had to be reverted due to some unexpected interactions with page layout. We need to revisit the RFC and select one of the other proposed options for implementation.

But at the moment, authoring new content using the upright flag is discouraged. There is a separate bug (T112710) that currently affects resizing images tagged with upright; that will be fixed. But that will result in a serialization with an explicit bounding box, not the upright flag, and we have no current plans to emit an upright flag in newly-authored content. Any existing use cases should be dealt with as part of the T351: RfC: Square bounding boxes process (go comment over there!), so that we can come up with a way to solve these problems which doesn't rely on a broken feature.

Change 238855 had a related patch set uploaded (by Cscott):
WIP: Allow serialization of images which scale the default thumbnail size.

https://gerrit.wikimedia.org/r/238855

So the message we have to spread is "don't use upright anymore" ?

So the message we have to spread is "don't use upright anymore" ?

Are there any updates on this? Is somewhere work going on to implement a replacement for "upright" which will be supported in VE?

So the message we have to spread is "don't use upright anymore" ?

Is somewhere work going on to implement a replacement for "upright" which will be supported in VE?

It looks to me like this is being blocked by T351 and T65904. Discussion above appears to indicate that implementing what upright does is being held up by a desire to redefine what it should do, or even to deprecate it.

I think that whatever solution is reached, it should comply with relevant policies on the Wikipedias that are affected by it. On enwiki, (https://en.wikipedia.org/wiki/Wikipedia:Image_use_policy#Displayed_image_size), the following policy is in place:

"Except with very good reason, do not use px (e.g. thumb|300px), which forces a fixed image width. In most cases upright=scaling factor should be used, thereby respecting the user's base preference (which may have been selected for that user's particular devices)."

Additionally, respecting a user's preference for image size is an accessibility issue, and needs careful consideration before any attempt is made to change or eliminate it.

The upright option suffers from some severe problems. Consensus was reached on replacing it, see https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes -- unfortunately, the replacement agreed upon had to be reverted due to some unexpected interactions with page layout. We need to revisit the RFC and select one of the other proposed options for implementation.

But at the moment, authoring new content using the upright flag is discouraged.

@cscott is this advice still up-to-date? https://www.mediawiki.org/wiki/Help:Images#Syntax should probably be updated. For context, we were looking at this flag in T296869: [Add an image] Identify portrait-format images to add the upright parameter to them when published.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:23 PM

The upright option suffers from some severe problems. Consensus was reached on replacing it, see https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes -- unfortunately, the replacement agreed upon had to be reverted due to some unexpected interactions with page layout. We need to revisit the RFC and select one of the other proposed options for implementation.

But at the moment, authoring new content using the upright flag is discouraged.

@cscott is this advice still up-to-date? https://www.mediawiki.org/wiki/Help:Images#Syntax should probably be updated. For context, we were looking at this flag in T296869: [Add an image] Identify portrait-format images to add the upright parameter to them when published.

Or @subbu perhaps you know the answer to this question? Thank you in advance!

My personal experience is that, as a newer editor, I edited ~30 articles using the visual editor before I realized that this was happening. It seems like a straight-forward upgrade to the visual editor. By the way, I went back and modified those 30 edited articles using "upright". I have since noticed many articles with specific "px" instead of upright and manually fix those myself; so this seems to be a fairly widespread problem.