See https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes for context.
If the user doesn't specify an explicit size for the thumbnail, we should scale to a square bounding box so that portrait aspect-ratio images look the same visual size as landscape aspect-ratio images.
Version: unspecified
Severity: normal
URL: https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63904
Change 123683 had a related patch set uploaded by Cscott:
Use square bounding boxes for default-sized thumbnails
Change 123683 merged by jenkins-bot:
Use square bounding boxes for default-sized thumbnails
Merged into after RfC discussion; now I need to make the same change in Parsoid---and get the WMF imagescalers busy making the new thumb sizes before deploy.
tsui wrote:
I strongly oppose such a fundamental change of the screendesign. Making the image sizes change according to this bounding-box model destroys the layout/screendesign. It will only lead to users beginning to specify an explicit size of the thumbnail again - at least that is what I will do for sure.
(In reply to Tsui from comment #5)
I strongly oppose such a fundamental change of the screendesign. Making the
image sizes change according to this bounding-box model destroys the
layout/screendesign. It will only lead to users beginning to specify an
explicit size of the thumbnail again - at least that is what I will do for
sure.
Your comments should have been made as part of the RfC process – https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes – note that this code change has already been merged and is now live on all Wikimedia wikis.
@Tsui: explicit sizes are probably actually the right thing in most cases. There is some discussion in https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Infobox_Image and it seems to me that the infoboxes with issues were ones that assumed a fixed width even though they didn't specify an explicit width bound, which was hostile to user customization.
Remember: if you don't specify an explicit size, you are requesting that MW choose an "appropriate size", which could be anything -- and will likely vary on mobile, hi-density devices, user preference, etc. If that's not actually what you wanted, then yes you should be specifying size explicitly.
That said, I am interested in continuing discussion on image options in general. There have been various RfCs proposing a more semantic set of image options, which would allow resizing in a more meaningful way than the current inflexible "default thumb size". Contact me on my talk page if you are interested in pursuing that discussion; offhand I can't remember if there is already a bugzilla and/or RfC for that work.
(Oh, and for the record this particular bug is for "Parsoid should match mediawiki/core's behavior". If you want mediawiki/core to change back, then bug 65945 is the one for you. But really https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Infobox_Image is where the discussion has been happening to date, and we can probably find a new on-wiki or on-mailing-list place to discuss this if/when we outgrow the Village Pump. Bugzilla is very awkward for discussions like this.)
(In reply to James Forrester from comment #6)
(In reply to Tsui from comment #5)
I strongly oppose such a fundamental change of the screendesign. Making the
image sizes change according to this bounding-box model destroys the
layout/screendesign. It will only lead to users beginning to specify an
explicit size of the thumbnail again - at least that is what I will do for
sure.Your comments should have been made as part of the RfC process –
https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes –
note that this code change has already been merged and is now live on all
Wikimedia wikis.
And the RFC was announced and he invited where? Honestly, I don't see any consensus on this RFC but just a blank proposal without any discussion which does not justify at all any software change like this.
The second paragraph of the RfC links to discussions:
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-02 and
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-21
which were announced and discussed on wikitech-l in threads starting with:
http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075619.html
http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076596.html
Discussion is now happening at:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Infobox_Image and
https://en.wikiquote.org/wiki/Wikiquote:Village_pump#Good_and_bad_alterations_in_the_new_software
I have seen them ofc and considered adding them to my comment. But these are no community discussions but discussions of developers how or when to implement the code (as they are happening on wikitech-l). They are necessary too but just as a second step when there’s community consensus. Please first reach this kind of consensus before you implement wide-ranging software changes like this which affect millions of articles. Hence, I beg you to revoke your code implementation now and wait for the outcome of the current discussions which also take place on other wikis (e.g. https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Bildgr.C3.B6.C3.9Fe_.C3.A4ndert_sich_beim_Speichern_ohne_Quelltext.C3.A4nderung https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Kurier#Neues_Media-Wiki-Geschenk).
(In reply to James Forrester from comment #6)
Your comments should have been made as part of the RfC process
which was on MediaWiki.org.
And MediaWiki.org is a wiki ruled by and for MediaWiki developers. I never had the feeling being invited editing that wiki in any kind nor sharing my incompetent opinion there. Apart from that, I've hard times not to compare this course of action to some German or even Vogon bureaucracy.
Obviously, one wanted the input by developers but ... again forgot(?) to asking the biggest consumer(s). Or did one merge this patch as some kind of mock too see how much riot it will cause?
Seriously:
a better default appearance" needs to be proven.
Yup, we decided in this case its better to revert now and then discuss, since some editors are considering adding an 'upright=1' workaround -- which would be bad, since 'upright' is actually the image option we most wanted to fix.
Anyway, https://gerrit.wikimedia.org/r/136708 is the revert, and I believe it is against the deployed branch so should take effect immediately. We will follow up with details about a proper discussion bringing in all the interested parties.
Are there screenshots of the bug caused by the patch? I'm confused as to what the problem is. (Well, in reality, I never really understood the RFC to begin with, but if there was a visual it'd help me out a lot.)
(In reply to Rainer Rillke @commons.wikimedia from comment #12)
And MediaWiki.org is a wiki ruled by and for MediaWiki developers. I never
had the feeling being invited editing that wiki in any kind nor sharing my
incompetent opinion there. Apart from that, I've hard times not to compare
this course of action to some German or even Vogon bureaucracy.
This bug is for discussion about square-bounding boxes for thumbnails. If you want to discuss MediaWiki's RFC process, please use the mailing list.
Also, on a meta note, I'm shifting this bug to MediaWiki core, since it is a core change. Feel free to revert if there is a compelling reason against this categorization.
(In reply to Tyler Romeo from comment #15)
Are there screenshots of the bug caused by the patch?
It was an intentional change...
http://imgur.com/a/iRTEZ#0
First 2 images before this patch was applied. Following 3 screenshots with patch applied
This is just an example. Other examples includeinfo box images that are now too small. Please provide an upgrade stategy to the communities before re-applying this patch.
If you want to discuss MediaWiki's RFC process, please use the mailing list.
The question was about adequacy of a MediaWiki RFC process for this particular change.
I'm shifting this bug to MediaWiki core, since it is a core change
It was. However, C. Scott Ananian needed to implement this change also in Parsoid; consequently shifted the component after Comment 4.
Yes, I should really have opened a new bug for the Parsoid component of the change after it landed in core, rather than shift component. But that's moot now.
(In reply to Rainer Rillke @commons.wikimedia from comment #16)
(In reply to Tyler Romeo from comment #15)
Are there screenshots of the bug caused by the patch?
It was an intentional change...
http://imgur.com/a/iRTEZ#0
First 2 images before this patch was applied. Following 3 screenshots with
patch applied
Thanks! Much appreciated. I can see where the concern is coming from.
C. Scott Ananian, is it possible having a link to or additional thoughts about why it is WONTFIX'ed now?
The title of this bug is "Thumbnails should use a square bounding box by default". We don't plan to actually do that anymore, hence WONTFIX. I'm sorry if the resolution was confusing.
To quote gwicke, who expressed it better than I:
I think we missed one of the use cases that the bare 'thumb' is currently
used for:
- thumb of a reasonable size, respecting the thumb size user pref: this is
what the bounding box change tried to improve
- column-aligned thumbs, respecting the thumb width user pref: this is what
was lost in the bounding box change
I think it would be helpful to engage the community to learn more about their
current use cases, and look for opportunities for improvement together.In the 'thumb' case this could for example lead to a new, more semantic
solution for use case 2), perhaps with a new 'column-thumb' image type. Once
we have found a new solution for existing use cases & editors have switched
to it we can revisit the bare 'thumb' behavior in order to better support
use case 1).
So, basically: we were trying to solve a problem for gallery users and n-wide image layouts, who didn't want unbounded height, and for naive users who wanted a default sizing option that "just worked", no matter how tall your image was.
However, we missed the use case of "a aligned column of images" which was in widespread use in a number of projects. In accordance with https://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle we promptly reverted our BOLD change.
It is possible that we will eventually revisit the issue, as gwicke mentions, but not until after we've got a solution for the existing "column of images" use case. And even then it's not clear that changing the default behavior of 'thumb' will be the correct behavior. The currently mooted proposal is some mechanism to add better semantic classes to images, so that a project can define a stylesheet in Common.css for "image taking up one column width", "full width images", or something similar. There's no definite proposal yet, just vague ideas.
So this bug is being closed as WONTFIX. If/when we have bright ideas for semantic classes for images, there would be a new RfC/bugzilla and it would be announced in the weekly Tech News (https://meta.wikimedia.org/wiki/Tech/News), which has been suggested as an appropriate cross-project forum for issues of this sort.
Note that bug 63904 remains open, which proposes changing the way 'upright' images are sized. In that bug there are comprehensive statistics on image option use which show that changing 'upright' should be a much less invasive change. But comments/participation on that issue are welcome. I will certainly push the 'upright' change to Tech News for discussion before actually merging it.
Bug 35756 is also open, which proposes a new syntax for cropping an image to an exact box. I think this is probably an alternative solution to the gallery issues, when consistent image sizes are wanted.
I hope this has answered all your questions.
Speaking of use cases.
(In reply to C. Scott Ananian from comment #20)
To quote gwicke, who expressed it better than I:
I think we missed one of the use cases that the bare 'thumb' is currently
used for:
- thumb of a reasonable size, respecting the thumb size user pref: this is
what the bounding box change tried to improve
Another request related to that is bug 7003, which also discussed this:
[...] bug 63904 remains open, which proposes changing the way 'upright'
images are sized.