Last modified: 2014-07-25 20:00:09 UTC
With [[mw: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.
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.
(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.
(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. 2) Replace a slight border around all thumbnails by default (as the "|border" parameter does: 1px #CCC, no padding), but not enclosing the caption. 3) ... ? (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. > > 2) 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) > 3) ... ? > > (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.
(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?
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.
(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.
