Page MenuHomePhabricator

Support explicit border in image thumb with a caption
Closed, DuplicatePublic

Description

Author: swalling

Description:
With Thumbnail style update landing in the next few weeks, there is a need to support manually adding borders to images, especially where the image has a white background (such as flags, animations, illustrations, et cetera).

This can currently be accomplished by simply adding the 'border' style in place of thumb. However, this then makes it impossible to add a caption.

There's no reason to avoid setting a caption on bordered images, as far as I can see. If users don't want a caption they can simply leave it out. If you want only alt text, there is support in the syntax for this using the alt parameter.

Details

Reference
bz68468

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:27 AM
bzimport set Reference to bz68468.
bzimport added a subscriber: Unknown Object (MLST).

That doesn't really make sense. border and "thumb" or orthogonal options. If you want to be able to set a caption with border, then it would make sense to be able to set a caption with neither border nor thumb set.

swalling wrote:

(In reply to Bawolff (Brian Wolff) from comment #1)

If you want to be able to set a caption with border, then it would make sense
to be able to set a caption with neither border nor thumb set.

That would work too, IMO. I don't really understand why you should be forbidden from setting a caption on whatever image style you want, since it's optional.

No, they shouldn't. That's not border is intended for. (It's used e.g. for the flag icons on Wikipedias.)

Or to rephrase: if we fulfill this request, pages everywhere will horribly break. You're asking for another option in the image syntax, and it already has too many options.

I'm very tempted to WONTFIX this.

The image options in MW are beyond terrible, mostly as a result of piecemeal decisions just like this.

swalling wrote:

(In reply to James Forrester from comment #5)

I'm very tempted to WONTFIX this.

The image options in MW are beyond terrible, mostly as a result of piecemeal
decisions just like this.

Okay James. Think of a better solution for people who want a border around an image with a white background and a caption.

(In reply to Steven Walling from comment #6)

(In reply to James Forrester from comment #5)

I'm very tempted to WONTFIX this.

The image options in MW are beyond terrible, mostly as a result of piecemeal
decisions just like this.

Okay James. Think of a better solution for people who want a border around
an image with a white background and a caption.

This is exactly what "thumb" is for right now. Stripping the styling for thumb without providing an alternative would be the root issue, but a very minor one in general.

What are the options here, technically?

  1. Create a new parameter for "|thumb" images, that adds a border for edge cases such as Flag of Japan.
    • This cannot reuse the words "border" or "frame", and cannot (?) mix them together.
  1. Replace a slight border around all thumbnails by default (as the "|border" parameter does: 1px #CCC, no padding), but not enclosing the caption.
  1. ... ?

(excluding any options which misuse html/wikitext (such as Tables, or Gallery-of-one), and the option of uploading new image variants with added borders (because that'd be silly, and inaccurate)).

(In reply to Quiddity from comment #8)

What are the options here, technically?

  1. Create a new parameter for "|thumb" images, that adds a border for edge

cases such as Flag of Japan.

  • This cannot reuse the words "border" or "frame", and cannot (?) mix them

together.

Umm, why not allow them to be mixed. Before reading this bug, I was under the impression they could already be mixed.

  1. Replace a slight border around all thumbnails by default (as the

"|border" parameter does: 1px #CCC, no padding), but not enclosing the
caption.

Probably acceptable. Border is light enough that most people won't notice it on images that don't have a white background. (I assume by "thumbnail" you mean images with the "thumb" parameter. Not all images)

  1. ... ?

(excluding any options which misuse html/wikitext (such as Tables, or
Gallery-of-one), and the option of uploading new image variants with added
borders (because that'd be silly, and inaccurate)).

Yes, that would be.

(In reply to Bawolff (Brian Wolff) from comment #9)

(In reply to Quiddity from comment #8)

What are the options here, technically?

  1. Create a new parameter for "|thumb" images, that adds a border for edge

cases such as Flag of Japan.

  • This cannot reuse the words "border" or "frame", and cannot (?) mix them

together.

Umm, why not allow them to be mixed. Before reading this bug, I was under
the impression they could already be mixed.

Border only applies to "none"/basic and "frameless" images, not "framed" or "thumb".

(In reply to James Forrester from comment #10)

Border only applies to "none"/basic and "frameless" images, not "framed" or
"thumb".

Yes, but since "framed" and "thumb" have now *lost* its inherent border, would it not make sense to allow it for those as well?

(In reply to Erwin Dokter from comment #11)

(In reply to James Forrester from comment #10)

Border only applies to "none"/basic and "frameless" images, not "framed" or
"thumb".

Yes, but since "framed" and "thumb" have now *lost* its inherent border,
would it not make sense to allow it for those as well?

No, the change is a single-skin change (Vector), and only applies to "thumb" not "framed" images. Ideally the change would remove "framed" and "thumb" from wikitext support, but there does not appear to be appetite for that level of effort at this point.

"framed" also uses the thumbinner class.

We need a solution to display a captioned image *with* border if need be. Else this whole restyling business becomes counterproductive. I predict editors uploading images-with-border to work around this, or worse, a community that (yet again) will override this update on a project basis.

swalling wrote:

(In reply to Erwin Dokter from comment #13)

"framed" also uses the thumbinner class.

We need a solution to display a captioned image *with* border if need be.
Else this whole restyling business becomes counterproductive. I predict
editors uploading images-with-border to work around this, or worse, a
community that (yet again) will override this update on a project basis.

For many of the common use cases, such as the flag of Japan cited on the discussion page, editors have already chosen to upload several bordered variants. This tends to exist already, for flags at least.

What's the issue with the following:

"50px|border|Some text" behaves as before
"50px|Some text" behaves as before
"200px|thumb|Some text" has new styling
"200px|thumb|border|Some text" has new styling, plus border

What breakage would this cause? What new problems would it introduce?

Looking at common cases (Flagicon template on enwiki, infoboxes on dewiki, etc.) it looks like a lot of uses of flags already specify a border and won't break with the new styling. The only case that would break is where people currently use |thumb and rely on its border-styling. If we make it easy to apply this border-styling, we provide a solution. thumb|border previously did not make sense, but now do. Am I missing something?

matthiasbecker1967 wrote:

According to comment # 15. Why not make "border" part of "thumb" and introduce "noborder" for explicitely removing all borders on images, where a border is not needed or is depreciated. That would spare editors from combing through tens of thousands articles wether "border" is needed or not.

swalling wrote:

(In reply to Matthias Becker from comment #16)

According to comment # 15. Why not make "border" part of "thumb" and
introduce "noborder" for explicitely removing all borders on images, where a
border is not needed or is depreciated. That would spare editors from
combing through tens of thousands articles wether "border" is needed or not.

Borders were removed from thumbs because complete lack of a border on images is not the most common instance of photo/video use. Instead, multiple box borders around images and lack of sufficient padding increases visual complexity of our reading experience. Removing excess square border on site elements is a trend you can see starting all the way back to the original Vector redesign, which significantly softened Monobook's hard edges and lack of whitespace. Simplifying our image styles for the most common use case is a change that is going to dramatically increase readability and bring the style in line with what we have on mobile devices and tablets now.

I'm going to try and make sure we allocate developer resources for Erik's proposal in Comment #15, so that editors have the option to manually add a border to thumbs where needed. In the meantime, increasing the whitespace around images will help even for images like flags that lack an in-image border.

(In reply to Erik Moeller from comment #15)

What's the issue with the following:

"50px|border|Some text" behaves as before
"50px|Some text" behaves as before
"200px|thumb|Some text" has new styling
"200px|thumb|border|Some text" has new styling, plus border

What breakage would this cause? What new problems would it introduce?

Looking at common cases (Flagicon template on enwiki, infoboxes on dewiki,
etc.) it looks like a lot of uses of flags already specify a border and
won't break with the new styling. The only case that would break is where
people currently use |thumb and rely on its border-styling. If we make it
easy to apply this border-styling, we provide a solution. thumb|border
previously did not make sense, but now do. Am I missing something?

I think this is a reasonable basis for an RfC, yeah. I think at this point given the cesspool that is MediaWiki's image support that I'd rather we didn't make big changes without an RfC (and without the Multimedia team weighing in).

Hi guys, thanks for your interesting ideas for improving the user experience around thumbnails. Could we please hold off on making quick decisions on this front? I am concerned that we are moving too quickly with this proposal -- as well as with the typography refresh, and it’s going to introduce a lot of confusion, right when we’re all at Wikimania. I would like Pau Giner to chime in, as the designer for multimedia, and he's on vacation until next week. In general, I think we all need more time to think through the issues carefully, rather than jump to premature conclusions. Thanks for your understanding.

"50px|border|Some text" behaves as before
"50px|Some text" behaves as before
"200px|thumb|Some text" has new styling
"200px|thumb|border|Some text" has new styling, plus border

What breakage would this cause? What new problems would it introduce?

If I understand correctly, 200px|thumb and 200px|thumb|border would both have border in non-Vector skins, which seems confusing.

In general, dealing with specifics of styling on the wikitext/parser level seems like a poor state of affairs. IMO we should be thinking about proper separation of content and presentation, and which changes in image wikicode take us closer to that.

The ideal state of affairs would be something like [[Foo.png|role=<role>]] and all decision about size, border, positioning etc. could be made by the skin. It is impossible to create really innovative skins, and also good responsive layouts, as long as size and other presentation details are hardcoded in the content, and part of the HTML is hardcoded in the parser.

That is an ambitious change, but as a first small step towards that, maybe we could add a role parameter, put a "role-<role>" class on the image, and add borders for .role-flag-icon and other similar classes in Vector (and deprecate the border property)? Captions include changes to the HTML structure, but I imagine border is something that can be handled purely in CSS.

TheDJ changed the task status from Open to Stalled.Dec 21 2015, 2:12 PM
TheDJ subscribed.

Stalled, since the: Thumbnail style update stalled as well.

Stalled, since the: Thumbnail style update stalled as well.

@TheDJ: Do you know of any task about the "Thumbnail style update"? (Sorry, just trying to find context as tasks should not be stalled forever.)

@Aklapper no more than what is in the mediawiki page. I guess the WMF team decided that it wasn't worth their time to continue to work on this.

In any case, wikitext changes should probably be blocked on the parser unification for now.

Aklapper changed the task status from Stalled to Open.Nov 3 2020, 3:08 PM

Indeed; https://gerrit.wikimedia.org/r/c/mediawiki/core/+/133301/ got abandoned. I don't see why that would stall this task though. :)

Aklapper lowered the priority of this task from Medium to Low.Nov 3 2020, 3:08 PM
Krinkle renamed this task from Images with border parameter should display captions to Support explicit border in image thumb with a caption.Nov 3 2020, 8:05 PM
Krinkle updated the task description. (Show Details)
Krinkle removed a subscriber: wikibugs-l-list.

Update:

  • The Thumbnail style update project from 2014 was cancelled the same year. It is possible that it might be picked up again in the future, but there are no signs of that. Having said that, I do note that Minerva has effectively done this without announcement and as such images that need a border to make sense are currently rendered in a confusing way on mobile web.
  • The proposed solution of making [[File: … |border|Text]] seems inviable to me as it would be a breaking change to the wikitext. This syntax is currently used with te explicit expectation that it not render a caption (otherwise one would have used thumb instead). The text serves as title and alt text, so that cannot be used to disambiguate.

I think the alternate solution of supporting both border and thumb being set simultaneously could work. Thus currently reliably results in thumb (regardless of order), which means it wouldn't cause breakage in the form of captions unexpectedly appearing or dissapearing. It woudl merely add a class that skins like Mineva that omit their border by default can use to render one for these thumbnails.