Page MenuHomePhabricator

RfC: Square bounding boxes
Open, Stalled, LowPublic

Description

  • Affected components: TBD.
  • Engineer for initial implementation: TBD.
  • Code steward: TBD.

Motivation

(Define the problem you are seeking to solve.)

Requirements

(Specify the requirements that a proposal should meet.)


Exploration

(Proposals and considerations will be documented here.)

Task to follow the progress of the RfC Square bounding boxes.

See also:

Details

Reference
fl536
ReferenceSource BranchDest BranchAuthorTitle
repos/releng/k8s-pvc-cleaner!26main-I0fa97c028ea4b2797b3b6e26dadc8eb841cb391amaindancyMake pod and pvc watcher threads resilient to errors
repos/sre/pyrra!2packaging-wikimedia-footerpackaging-wikimediaherronAdd Wikimedia links to Pyrra footer
repos/releng/k8s-pvc-cleaner!25main-I886ff2755c4fb81b42130e2e1b39dbf1033621ffmaindancyExit main thread if a worker thread terminates
repos/releng/k8s-pvc-cleaner!24main-I9096c578a2731c71ba87e973d5193daff4068137maindancypvc-cleaner.py: Add #!/usr/bin/env python3
repos/cloud/toolforge/toolforge-deploy!200bump_builds-buildermainproject_1317_bot_df3177307bed93c3f34e421e26c86e38builds-builder: bump to 0.0.92-20240219153535-48c88c91
repos/mediawiki/services/ipoid!227main-Ieb75bf687679ac57a26e97c38ed03cd483bc26b3mainkharlanupdate-db: Adjust error logging
repos/mediawiki/services/ipoid!224main-Ifcc5f1d87852bb7dc6084f27f8f3cca9823daf8dmainkharlanlogging: Switch pipeline logging to winston
repos/cloud/toolforge/builds-builder!33handle_harbor_quota_error_on_exportmainraymond-ndibe[builds-builder] meaningful error message when user exceeds harbor quota
repos/data-engineering/airflow-dags!602T351792_build_test_and_lint_images_with_blubbermainaquBuild unit test & lint images with Blubber
repos/releng/k8s-pvc-cleaner!16main-I4c355d9fa586bc867ea6c23145566b80af5b878cmaindancyAdd --debug command line option to enable debug log level
repos/cloud/toolforge/envvars-cli!25bump_to_0.0.4maindcarobump to 0.0.4
repos/mediawiki/services/ipoid!213main-I2f4167934135b466a03d09a713f4ae763efa1f76mainkharlanlogging: Use winston logger with ECS formatting
repos/mediawiki/services/ipoid!211main-I64b09ff1b146227e95a956048a2d15f4e58bf391mainstranLog at info level instead of debug level
repos/mediawiki/services/ipoid!209main-Id317229a60804b90f3dc56884cb06c2b983e1a9emainkharlanlogging: Use pino-pretty with integration script
repos/mediawiki/services/ipoid!204main-Id317229a60804b90f3dc56884cb06c2b983e1a9emain-I2c0886a9f728b321702b9ad6e1894d569b83e38akharlanlogging: Use pino-pretty with integration script
repos/releng/gitlab-cloud-runner!305T351478-integrate-k8s-pvc-cleanermainsandeepsConfiguring k8s-pvc-cleaner
repos/mediawiki/services/ipoid!202main-I2c0886a9f728b321702b9ad6e1894d569b83e38amainkharlanlogging: Use structured logging in node
repos/mediawiki/services/ipoid!201main-I3c46ebc1f68899aaafa2ce5b77bca44413404b76mainkharlanlogging: Implement structured logging for bash scripts
repos/cloud/toolforge/envvars-cli!17bump_to_0.0.3maindcarod/changelog: bump to 0.0.3
repos/releng/k8s-pvc-cleaner!1T351478-cleanup-unused-buildkitdmainsandeepscleanup unused buildkitd PVCs
Show related patches Customize query in GitLab

Event Timeline

flimport raised the priority of this task from to Needs Triage.Sep 12 2014, 1:45 AM
flimport set Reference to fl536.
daniel added a subscriber: daniel.

RFC discussed on 2014-04-02, see https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-02

Action items:

  • cscott to patch bare "thumb" to have square bounding box
  • cscott to patch upright to have a square bounding box, and use dumpGrepper to see whether this breaks too much

We tried this and the patches made production, but we had to revert it because it was too disruptive to page layouts.

Back to the drawing board: probably we will have to add new syntax to make this an opt-in feature.

Spage renamed this task from RfC: Square bonding boxes to RfC: Square bounding boxes.Mar 4 2015, 9:00 PM
Spage updated the task description. (Show Details)

Well, I am not sure what it means to block or depend on (be blocked by) an RfC that has been inactive for more than a year. The RfC produced two conclusions:

  • The first (change defaulting parameter from width to bounding square) is tracked at T65903 and has been declined (cf. T67945), so that part of this ticket is essentially closed.
  • The second is tracked at the T65904 (redefine what "upright" does). I would say the outcome of this ticket "depends" (in a sense, though the RfC is not ongoing) on that one, which appears to be stalled on the question of whether it is a desirable change (Cf. T64671).

T64666: Support 'upright' image option is a horse of a different color: "upright" is already supported as currently defined, so it could logically be closed. Moreover, the ticket's author indicates at T64671#1001170 he does not want to support it but to deprecate it, so the ticket's purpose and relation to the RfC is murky.

...Back to the drawing board...

Does that mean this ticket can be closed?
I am inclined to agree that it needs to be re-thought. The RfC and ensuing events were informative and thought-provoking, but the result does not appear to be actionable.

I don't think the RFC should be closed: the question of the RFC ("how to opt in to a square bounding box") are still active, and the solutions proposed in the RFC document -- save the one which was tried and failed -- are still valid.

I think we need to return to the RFC and choose another of the options to implement. Perhaps the "square" option is best, since it's obvious from the first attempt that this behavior needs to be opt-in, not opt-out.

Some more notes:

  1. One of the things missed in the original RFC was the idea that width-based scaling is actually very desirable in article layout, because it leads to a consistent appearance: all the images have their left and right edges line up, and they are generally arranged vertically. It is desirable to maintain this aligned appearance even for portrait images. The original goal was to ensure that extreme cases didn't break the page by being stretched vertically to a huge degree, but the square bounding box was probably overly restrictive. A 1:2 bounding box would probably be a better default (twice as high as it is wide), if we wanted to change the default bounds for thumb as was originally proposed (and agreed on, and then reverted). That would ensure that portrait orientations of common 4:3, 16:9, etc images are still resized using width bounds, and thus appear neatly aligned. The height bound would then affect far fewer images, just the extreme cases.
    1. This could be opt-in, via a ratio argument, or something like that. ratio=2 means use a 1:2 bounding box, and would be an alternative to using an explicit scaling factor (see note #2) and be more robust against image edits which affect its size.
    2. The ratio argument could allow framing the image with an standard-width bounding box (ie, giving the caption the standard width and padding the image with whitespace, not necessarily drawing a border around the bounds). This could restore the desired visual alignment, even for skinny images.
  2. Another major use case for upright is "scaling the default size", without putting fixed pixel dimensions in the markup. This is done for accessibility, so that vision-impaired users can change their default thumbnail size and have all the images scale. Using fixed pixel dimensions defeats this. This needs further investigation, however: scaling the default size is bound to break the alignment of images and thus dirty up the page layout. Here are some possible uses:
    1. This is just a workaround for portrait-format images with skinny aspect ratios, in which case solution #1 above might be better/more automatic.
    2. This is done to provide a fixed number of scaled image sizes, like "double wide" thumbnails (upright=2), etc. The VE UX for T64671 might better reflect this if it avoided the use of a slider for scale, or at least provided detents for common values. (ping @Jdforrester-WMF).
    3. Scaling the default size could be abused to create "full width" figures (ie, the illustration of the earth-moon distance on https://en.wikipedia.org/wiki/Moon#Scale_model ), but this would actually break the page for users who wanted to scale thumbs up without changing their page width. Currently we seem to use <gallery> (as a workaround?) for full-width layouts. It would be nice to have the page width available as a scale factor, independent of thumb size. ("column width", too?)
    4. Are there other legit uses? (Legit meaning, "make the page look better" or "implement a particular layout", not just "abuse scaling to arbitrarily customize image sizes without incurring the wrath of the pixel-scaling police".)
  3. The VE UX for T64671 exposes the upright functionality as a "scale" slider. But upright only allows "scale" sizing of thumbnails. There is no way to "scale" the default image size. If we added a scale option, we could fix this and achieve a more consistent UI. (But do we want to? Scaling the uploaded image size makes page layout brittle against changes to the uploaded image size.)
  4. There are a number of use cases for height-based scaling, especially for multiple-image layouts. ratioed bounding boxes might make sense here, too. In particular, ratio=0.5 would use height-based scaling for most 4:3 or 16:9 images, except for "exceptionally wide" ones. More investigation is necessary; most of these examples seem to really want <gallery> to compute a layout which fits a number of images into the "full page width", in the process constraining them to have the same height. Our built-in image sizing tools can't handle this (and to be fair, <gallery> can't really do it either, the markup is filled with explicit pixel sizes).

I'd like to hear some opinions from designers: what are the sizing tools we need to make our content look good?

FYI, en.wp seems to be advising to use upright because of it's relative to user option scaling features.

upright in my mind only ever meant one thing. This image has a portrait orientation. The fact that it also allowed scaling using it's value was a misfeature that should have never been coupled with it and was a huge mistake.

Upright was introduced to PREVENT images to be as wide as the default. Even though consistent width was usually preferred, people judged that in many (esp the 'narrow') portrait sizes, this gave too much prominence to the portrait image by also resulting in a huge vertical usage of space.

So the hints are I think:
1: You want consistent default widths, because that creates an ordered page layout.
2: Sometimes 1 results in portait images taking up way too much vertical space, since the width rule causes them to double (a/r) the vertical space because of required uptake on the width. Therefore a 'reduced' but still consistent width is desired for portrait images.
3: Sometimes 1 and 2 are not enough, because the image is too narrow a portrait. or because too wide (a panorama) or you simply want to highlight 1 image by enlarging it's size.

1: default width
2: upright default width
3: scale override of defaults, but still relative to the defaults.

Now a bounding box could be considered, in addition to all that, but with the existing content, I think honestly that that ship has sailed for any kind of default. The best option would be to make that an opt in indeed, though I slightly worry about how that might be potentially confusing the endless stack of sizing options even more. Such an option might possibly also become a new 'default' for newly created wiki's but again, for WMF, probably it is better as an opt in.

Krinkle changed the task status from Open to Stalled.Apr 3 2020, 9:49 PM
Krinkle triaged this task as Low priority.
Krinkle updated the task description. (Show Details)
Krinkle moved this task from Old to P1: Define on the TechCom-RFC board.
Krinkle updated the task description. (Show Details)
Krinkle added a subscriber: Krinkle.

This seems related to T65903, which was declined.