Wikipedia talk:Manual of Style/Images

message: Lately I've seen a lot of disruptive drive-by edits to articles with long-standing image layouts, based on this or that reading of image placement guidelines. But what appears to be happening is that some editors assume that what they see, for example specific instances of WP:image sandwiching and white space, is what everyone else sees, even though this is not always the case. Could we have some guideline that says that before changing the current/long standing image layout of an article, an editor who wants to do this should propose it on the talk page so that the main editors of said articles and others can evaluate the proposed changes to see if they are even a problem for anyone else? This seems to have particularly become an issue after the new extremely narrow text layout has become standard (which I have personally disabled because it looks awful to me). FunkMonk (talk) 17:45, 3 June 2023 (UTC)
replies: text: That seems like a pretty reasonable idea, along with additional advice to test at multiple browser widths and on different devices.  — SMcCandlish ☏ ¢ 😼  04:17, 29 August 2023 (UTC)
thread_title:  Add disclaimer/note about different screen settings 

message: I want to discuss the style of content that readers don't see: the syntax or coding style.
The 'Syntax' section gives this as an example:
I would say that this is easier to read:
For the same reason that
A Siberian Husky used as a pack animal
is easier to read than
ASiberianHuskyusedasapackanimal
additionally, 
is more difficult to read than the aforementioned, for the same reason that
lA lSiberian lHusky lused las la lpack lanimal
is more difficult to read than the aforementioned.
I often see people following the example on this page and eschewing any space that is not between two words. Not only that, but many editors see spaces used in code and remove them. I'm not sure what is being improved. Do they quickly read the content, decide it doesn't need to be read again, and want it to take up less space?
To be sure, some parts of computer code do not need spaces between them (series of rote tags that everyone ignores anyways). But some code can slightly differ from use to use, and it needs to be easy to read.
It isn't just image tags with this problem, to be sure. But this page must be fairly popular and get a lot of different viewers, so I figured I'd bring it up here. Wizmut (talk) 12:45, 1 July 2023 (UTC)
replies: text: I wish we had some kind of rule discouraging changing white space. Not outright prohibiting it. When someone makes a 500 line change, with 499 lines of white space changes and one line of hard-to-see typo, that's not an improvement. GA-RT-22 (talk) 13:09, 1 July 2023 (UTC)
replies: text: I'm glad we don't, and a general one would run afoul of WP:EDITING, WP:CITE, etc.  The most common spacing-cleanup case is making citations consistent and more readable. It often  a genuine improvement for other editors (has no effect on readers, of course), especially when someone has injected vertical citations (which are really appropriate only in WP:LDR) into the middle of a paragraph, making it hard to understand the paragraphization, or when people do daft things like   — SMcCandlish ☏ ¢ 😼  14:12, 19 August 2023 (UTC)

text: Our documentation should reflect what editors typically do (especially since people tend to copy-paste from the doc and change the details). And, well,  thumb | alt = Whatever | More Whatever is not it. The prevalent styles are thumb|alt=Whatever|More Whatever and thumb |alt=Whatever |More Whatever, to mirror typical formatting of templates. And "File: Name" is just weird. No one does that, any more than they refer to "Wikipedia: Administrator's noticeboard" or "MOS: IMAGES".  — SMcCandlish ☏ ¢ 😼  14:12, 19 August 2023 (UTC)
thread_title:  Syntax style 

message: We really ought to add guidance that you shouldn't stack images.
This displays on mobile as a centered continuous stack of images, and not a neatly cascading set of images beside the text. I've seen articles where on mobile, you had to scroll through like five screens of images to get to the text. This is covered a bit in Help:Pictures, but not in the MOS and not specific to mobile. GMGtalk 11:19, 29 July 2023 (UTC)
thread_title:  Image stacking 

message: In Fleetwood Park Racetrack, I've got two maps showing the same area in 1885 and today.  Is there some way to build a  composite image which lets you drag a slider to expose one or the other, in the style of https://web-toolbox.dev/en/tools/image-compare-slider? RoySmith (talk) 16:25, 28 August 2023 (UTC)
replies: text: I don't think this exists. We're just now starting to even have interactive maps. Wiki is always 5-10 years behind the rest of the internet in technological capabilities, unfortunately. ɱ (talk) 17:06, 28 August 2023 (UTC)
thread_title:  Dragable image comparisons 

message: We have a problem, highlighted at Talk:Ulster Scots people#Why the flags? (now an RfC at Talk:Ulster Scots people#RfC on inclusion of ancestral national flags), in which people do not understand that the majority of the material at MOS:FLAGS pertains to use of flag images at all; in the few places it is limited to flag  in particular, it says so explicitly.  We need to do a WP:SUMMARYSTYLE section at MOS:IMAGES that encapsulates the  guidance about flag images here. Maybe even move most of it here and retarget MOS:FLAGS to this section, and have MOS:FLAGICONS go to the section at MOS:ICONS and reduce that material there to just the icon-specific concerns (use in infoboxes, tables, etc.).  PS: I think I may even be to blame at least in part for this confusion; I think I had a lot to do with consolidation of the flag-related material in one place, back when MOS:ICONS was in its infancy (and when most of the concerns originally raised were about icons, so it seemed to make sense at the time).  — SMcCandlish ☏ ¢ 😼  20:58, 1 September 2023 (UTC)
thread_title:  Flags 

message: I added an image to the "History" section of an article, but it appears in the next section. How do I get the image to appear in the correct section? Thank you, Cunard (talk) 11:47, 8 October 2023 (UTC)
replies: text: That one's got me stumped. I have no idea why it's moving down to the section below that.  — SMcCandlish ☏ ¢ 😼  13:01, 8 October 2023 (UTC)
replies: text:  It's easy to explain. The article begins with a  immediately followed by a , and these are both floated boxes. Images are also floated boxes; and the top edges of all floated boxes must occur in sequence down the page. So because the image is after the , the top edge of the image cannot be any higher than that of the second infobox. --Redrose64 🌹 (talk) 20:09, 8 October 2023 (UTC)
replies: text: Thank you, . I guess there's no way to fix this with these two infoboxes. I don't think  can be emedded with , which lacks a "module" parameter like Template:Infobox person has. Cunard (talk) 23:07, 8 October 2023 (UTC)
replies: text: It's an issue described at Wikipedia:Extended image syntax#The many-floating-objects problem. You can use , as I did . --Redrose64 🌹 (talk) 20:17, 9 October 2023 (UTC)
replies: text: Thank you for fixing this, ! Cunard (talk) 07:07, 10 October 2023 (UTC)
thread_title:  How to put image in the correct section? 

message: Please change
:... can create a distasteful text sandwich
:Wide images opposite one another...
to
:Wide images opposite one another...
:... can create a distasteful text sandwich
from View source:
:


Thanks. 173.67.42.107 (talk) 12:47, 8 October 2023 (UTC)
replies: text: . The images are now in the proper order to both display the intended effect, and render sensibly in text-only or text-to-speech mode.  — SMcCandlish ☏ ¢ 😼  13:05, 8 October 2023 (UTC)
thread_title:  edit request 

message: The redirect Mos:LEADIMAGE has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached.  Utopes (talk / cont) 23:45, 11 October 2023 (UTC)
thread_title:  "[[:Mos:LEADIMAGE]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: I'm in the process of prepping a few hundred 1980s U.S. government photos for upload to Commons for use in biographies, mostly as infobox photos. While most of the photos are black and white, about 15% of the subjects have both a single color portrait and a set of black and white portraits to choose from. With a few exceptions, the subjects with a color portrait have a visibly higher-quality black and white alternative (file size doesn't necessarily mean much, but fwiw, the color portraits are mostly in the 25-40kb range, as opposed to 50-100kb for the black and white portraits). Is there some sort of guideline to follow on choosing one over the other, or is this simply a judgment call? Bios almost never need two portraits from the same portrait session, so is having a higher-quality image worth the cost of not having a color image of the individual on their page? Star Garnet (talk) 18:12, 26 October 2023 (UTC)
replies: text: Might be helpful to see examples, to get an idea of the relative image qualities.  — SMcCandlish ☏ ¢ 😼  18:54, 26 October 2023 (UTC)
replies: text: A pretty representative example would be for Michael W. Grebe: color vs. b&w Star Garnet (talk) 20:17, 26 October 2023 (UTC)
replies: text: Well, since they're otherwise essentially identical, I would use the color one, but crop it a whole lot so it's just a bust image.  — SMcCandlish ☏ ¢ 😼  12:09, 4 January 2024 (UTC)

text: Assuming that all options are freely licensed I would look to which photo does the best job of putting the person in a respectable pose. Black and white portraits are often aimed for this capacity, but otherwise we don't place any extra value for color over b&w Masem (t) 19:16, 26 October 2023 (UTC)
thread_title:  Value of a color vs. black and white infobox portrait 

message: I'm writing this on mobile so any oddities can be brought down to that While in a discussion over on the Discord, MOS:SANDWICH got brought up, and when I took another look I noticed that it doesnt really state why sandwiching should be avoided other than it being "distasteful" which is something that is subjective and a thought not everyone shares. Is there a specific reason why sandwiching should be avoided? ― Blaze WolfTalkblaze__wolf 11:58, 1 November 2023 (UTC)
replies: text: My guess is because it makes paragraphs pretty narrow on monitors that aren't wide screen. Magnolia677 (talk) 13:56, 1 November 2023 (UTC)
replies: text: Of course it's that. I've never heard anyone support "heavy" sandwiching, though mild partial sandwiches are not the end of the world for most screens. Mobiles avoid it completely, no? Johnbod (talk) 15:09, 1 November 2023 (UTC)
replies: text: But Blaze Wolf's question was a good one.  So often there are other reasons that aren't obvious. Magnolia677 (talk) 16:48, 1 November 2023 (UTC)

text:  Yes mobiles avoid sandwiching completely. But that wasn't why it was brought up. Someone had said they were proud of an article in which there was sandwiching issues. ― Blaze WolfTalkblaze__wolf 18:11, 1 November 2023 (UTC)
replies: text: Well "sandwiching issues" are in the eye of the beholder, and their screen. I'm certainly proud of some articles where some have moved images around to avoid sandwiches, but in more extremwe cases I'll edit to resolve them myself. Johnbod (talk) 21:03, 1 November 2023 (UTC)

text: And it is good to peridiocally review this sort of claim, anyway. Mobile browsers have come a very long way in a few years, the average monitor size on desktops has gotten larger, and so on. See also discussions at WT:LENGTH about revising/removing various obsolete technical-considerations claims that were being made.  — SMcCandlish ☏ ¢ 😼  19:05, 1 November 2023 (UTC)
replies: text: Fine, but I certainly don't think this is obselete, nor will it be until they pry my keyboard from my cold, dead hands .... Johnbod (talk) 21:03, 1 November 2023 (UTC)
replies: text: Text fragmentation is a big concern for those with disabilities. Size of paragraphs would be the next concern. As for length of articles.... at minimum we should fallow academic recommendations. Moxy- 21:46, 1 November 2023 (UTC)

text: It's long past time to retire MOS:SANDWICH, at least for images opposite infoboxes. It's a relic of a time when screens were much smaller, browsers didn't handle differing widths well, and mobile devices didn't even exist. It's particularly a problem with infoboxes, because it effectively prohibits any inline image in shorter articles (stubs and most start-class) that have infoboxes. 40% of articles have infoboxes; 80% of articles are stub or start class. It does our readers a massive disservice to say we can't have inline images in ~30% of articles. Pi.1415926535 (talk) 05:29, 10 November 2023 (UTC)
replies: text: I strongly disagree.  – maybe, but I'm not alone in regularly viewing Wikipedia articles on tablets not using the mobile site, when sandwiching is a real problem. The screen size on laptops has not increased. My solution for small articles is to use "center" to place images centrally. Peter coxhead (talk) 11:17, 10 November 2023 (UTC)
replies: text: Well, Pi.1415926535's central point is correct, that it is better to have a short article illustrated at all than to avoid illustrating it because the layout isn't perfect for every class of user. The resolution of laptops and tablets has increased, which amounts to an  increase in screen size. But this centering idea might be worth integrating into the guidance if it is useful without negative side effects for other users. I.e., let's get to a compromise, work-around solution.  — SMcCandlish ☏ ¢ 😼  17:04, 10 November 2023 (UTC)
replies: text: Myself, I don't think centering helps at all. Johnbod (talk) 17:11, 10 November 2023 (UTC)
thread_title:  MOS:SANDWICH 

message: A recent edit changed  to now read "vulgar, horrifying, or obscence". I'm skeptical that there is a consensus for this, primilarily because with the rise of "trigger warning culture", anything that might offend or shock anyone for any reason could be PoV-pushingly mischaracterized as "horrifying" and be subject to editwarring to remove it, even if it would not be of concern to most readers. Medical articles in particular are already subject to frequent attempts to censor images from them of injury types and disease results, and I can certainly see such a broad concept as "horrifying" also being abused to censor material on sexuality; religious ideas like depictions of Hell; historical material on wars and weapons, medieval torture, etc; blood sports; the entire subject area of the horror genre; among others.  — SMcCandlish ☏ ¢ 😼  02:33, 2 December 2023 (UTC)
replies: text: Hmm, I'm inclined to see how it plays out, registering that there is no established consensus for the change. I don't really edit this sort of stuff, but I think there is a case for boxes or whatever with a "show" button. Johnbod (talk) 02:43, 2 December 2023 (UTC)
replies: text: 'a case for boxes or whatever with a "show" button' is something very few editors would support, so using that as a rationale for why to keep this change seems rather dubious. Is there something about it, on it's own merits, or is it just because it aligns with a "show box" scenario that isn't likely to ever happen?  — SMcCandlish ☏ ¢ 😼  08:19, 2 December 2023 (UTC)

text: I'm not sure I agree with the addition, but I think most of the potential objections to images you mention could already occur under the banners of vulgar and obscene (and as you note, attempts to censor images already occur). Nikkimaria (talk) 02:46, 2 December 2023 (UTC)
thread_title:  "horrifying" 

message: There is an ongoing RfC that may be of interest to editors here regarding the removal of image collages from individual year articles at . voorts (talk/contributions) 00:26, 24 December 2023 (UTC)
thread_title:  RfC on removal of image collages from Year articles. 

message: Your input would be appreciated at Talk:Morristown, Tennessee#Photo of a tombstone, where there is a content dispute regarding a photo of a tombstone. Magnolia677 (talk) 23:37, 26 December 2023 (UTC)
thread_title:  Photo of a tombstone 

message: Requesting that the link to Special:PermanentLink/460749801 in Wikipedia:Manual of Style/Images#Images for the lead be changed to Special:PermanentLink/1192743397 (or any such recent version). The currently linked version has a redirect template redlink and what is now a navbox at the top of the article, making it less obvious which image is being referenced. hinnk (talk) 02:52, 2 January 2024 (UTC)
replies: text: .  — SMcCandlish ☏ ¢ 😼  12:05, 4 January 2024 (UTC)
thread_title:  Updating permanent link 

message: I know I've seen discussions on the theme "No, we don't want your artistic vision in WP-biographies", but is there something written on that in a guideline somewhere? Should something be mentioned at Wikipedia:Manual_of_Style/Images#Making_images_yourself? Gråbergs Gråa Sång (talk) 09:44, 4 January 2024 (UTC)
replies: text: This seems more like a WP:IMAGEPOL (specifically WP:IUPC) question than a MOS:IMAGES one. The "Making images yourself" section here is basically a summary, with some style input, of the IUPC subsection "User-created images" (which we were not cross-referencing; I fixed that).But yes, this should be addressed more clearly somewhere. What the policy ssys in short is that it's fine to add one's own charts and diagrams, including maps (and of course one's own photos are permissible). But it doesn't very directly address other user-generated graphics. All it says is "Additionally, user-made images may be wholly original. In such cases, the image should be primarily serving an educational purpose, and not as a means of self-promotion of the user's artistic skills. The subject to be illustrated should be clearly identifiable in context, and should not be overly stylized." The example provided is actually another diagram. It doesn't get at things like artistic portraits, still lifes, landscapes, animal depictions, and so on, but it probably should. There's a bit of a wrinkle when it comes to things that are not possible to photograph, such as interstellar phenomena or mythical creatures.The overal question may have particular pertinence these days and into the future, since AI image generators can be used to cobble together "new" portraits based on pre-existing portrait data, and this would be WP:OR and then some, well beyond what WP:IUPC was intended to permit. Just yesterday (not on WP or on Commons) I saw a huge series of fanciful AI portraits of Mädchen Amick (zero of which would be appropriate here), and that was just one example in a long stream of such AI-enabled fan "art" I've run into on social media; the prevalance of it is increasing rapidly.I think this question is worth raising, with regard to portraits, landscapes, and other non-diagrammatic art (human- or AI-generated), at WT:IMAGEPOL.  — SMcCandlish ☏ ¢ 😼  11:59, 4 January 2024 (UTC)

text: See above. There have been similar questions in the past, and IIRC the answer was always "no thanks". --Redrose64 🌹 (talk) 14:42, 9 January 2024 (UTC)
replies: text: Could someone let me know whether it would be ok, if we are talking about a cyberoffensor, potentially dangerous, over 40 years old, free, who is not yet posted on Wikipedia? 188.146.110.234 (talk) 15:10, 9 January 2024 (UTC)
thread_title:  [[WP:USERG]] portraits 

message: Would there be a problem if, out of lack of an available picture, but as in a photography of a person, to use a drawing of this person in the image section? Kayy kay (talk) 04:02, 9 January 2024 (UTC)
replies: text: See above. There have been similar questions in the past, and IIRC the answer was always "no thanks". --Redrose64 🌹 (talk) 14:42, 9 January 2024 (UTC)
replies: text: Could someone let me know whether it would be ok, if we are talking about a cyberoffensor, potentially dangerous, over 40 years old, free, who is not yet posted on Wikipedia? 188.146.110.234 (talk) 15:10, 9 January 2024 (UTC)
thread_title:  Drawing instead of photo in the image section 

message: Whatever the original reasons there were for the image width parameter to be called "upright", it's a poor name for that feature (either nonsensical or counterintuitive) and likely yet another small issue in WP:RETENTION, WP:NEWBIES &c.  —  AjaxSmack  15:24, 20 January 2024 (UTC)
replies: text: The original reason seems to be that it was intended for 'upright', i.e. portrait-oriented, images to reduce the size when the user's default width was used. But I agree that it's a poor name now; "scale" might be better. (Note that "upright" is used elsewhere, e.g.  in taxoboxes.) Peter coxhead (talk) 16:54, 20 January 2024 (UTC)
replies: text: The  feature isn't like a template parameter where we would discuss and then just amend the template code. It's part of the MediaWiki software, and hence is not just outside the scope of this page, it's also not something that English Wikipedia can decide without involving all the other wikis that use MediaWiki (more than a thousand different websites). You need to file s change request at phab:, but be warned, they may throw it out as being years too late. --Redrose64 🌹 (talk) 23:22, 20 January 2024 (UTC)
replies: text: What about an alias, then?  —  AjaxSmack  22:51, 21 January 2024 (UTC)
replies: text: We can't, the image format is part of the MediaWiki software so the change would have to be made there. Masem (t) 03:37, 22 January 2024 (UTC)
thread_title:  "Upright"? 

message: Hi. I don't know where to place the "Mezzelune with seafood and pesto" image; according to the Manual of Style's rules, which is the most suitable place? JacktheBrown (talk) 18:49, 27 March 2024 (UTC)
thread_title:  [[Mezzelune]] 

message: FAC discussion which could be relevant to editors here, and perhaps the MOS for images should have a note on how to deal with palaeoart once consensus emerges. FunkMonk (talk) 13:45, 11 April 2024 (UTC)
thread_title:  Discussion on use of [[palaeoart]] 

message: Would anyone like to comment about the appropriateness of images in navboxes at Wikipedia talk:Categories, lists, and navigation templates#Images in navboxes (again)? --woodensuperman 07:43, 26 April 2024 (UTC)
thread_title:  Images in navboxes 

message: The MOS:SANDWICH bit could be slightly reworded I think. Propose deleting "that face each other" from . "Face each other" doesn't make sense in this context I think; both images are facing the reader. Still not in love with this new wording, so open to suggestions. 104.232.119.107 (talk) 21:49, 22 May 2024 (UTC)
replies: text: Already done – was replaced by "images horizontally opposite each other", which looks fine to me. Tollens (talk) 20:03, 23 May 2024 (UTC)
replies: text: Yup looks good to me too! 104.232.119.107 (talk) 04:15, 24 May 2024 (UTC)
thread_title:  Reword