Wikimedia Bugzilla is closed!

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).