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

Description

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


Version: unspecified
Severity: enhancement

Details

Blocked By
T64666: Support 'upright' image option
Reference
bz62671
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 "Normal".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?

Trizek-WMF added a comment.EditedJun 18 2015, 2:12 PM

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" ?

Add Comment