manual Of Style/Images
Is the AI upscaling of a blurry or historical portrait considered to be unremarkable (serving to improve the presentation without materially altering the content) or something to avoid or flag (where a reader needs to know about them to properly interpret the image)?
| This is the talk page for discussing improvements to the Manual of Style/Images page. |
|
 | Manual of Style   | |||||||||
| ||||||||||
 | Wiki Help NA‑class High‑importance | |||||||||
| ||||||||||
 | Images and Media (inactive) | |||
| ||||
Index
| |||||||||||
| This page has archives. Sections may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
AI upscaling
As the technology becomes cheaper, I've been seeing an increasing amount of this on Commons, where a user thinks that running a low res portrait through a free upscaler like MyHeritage to add some convincing but semi-imaginary detail to the eyes, nose and mouth is a helpful thing to do. I don't know if we're yet at the tipping point where this needs an explicit clarification in Wikipedia's MOS.
The example that led me here was the Raj Kapoor article, where the low res 1959 film still File:Raj Kapoor in Anari.jpg is being replaced with an AI's upscaled interpretation File:Raj Kapoor in Anari enhanced.jpg. Belbury (talk) 10:06, 9 May 2023 (UTC)
- Absolutely, positively needs to be noted on the img description page and in captions. EEng 10:38, 9 May 2023 (UTC)
- I would argue that we should not accept AI upscale images, save for specific demonstrations of the techniques, due to the questions on copyright of the process. Its not mechanical like image reduction, but instead adding info that wasn't there before, like colorization. Which means that that new information may have been gleaned from one or more additional sources of which copyright is uncertain. Masem (t) 13:26, 9 May 2023 (UTC)
- I'd like to note that image reduction is not mechanical and results do differ based on the chosen algorithm. In addition, image reduction takes away info that was there before. So at the risk of pointing out that other stuff exists, if these are the things that we are worried about, then there's a lot more to look at than AI upscaling, considering that image reduction happens on nearly every page with an image. Orange Suede Sofa (talk) 02:51, 19 May 2023 (UTC)
- AI alterations of an image should always be in a separate upload and clearly marked on both captions and image description page. A colorized version of an original black and white is not an improved version of the same image, it is something new and completely different. In your example, the AI made nicer looking eyebrows but the ear is now worse than before if you ask me. Misleading images like this should be avoided. —Kusma (talk) 20:27, 9 May 2023 (UTC)
Are there any objections to updating Wiki: Manual of Style/Images#Editing images to explicitly say that AI upscaled images "should not usually" be used on Wikipedia, in the same phrasing as for colorisation? The guideline currently cautions against colorisation on the grounds that it is WP:OR, but AI upscaling is as much if not more of a problem.
(I've just found a new behaviour on Commons where a user takes a freely licenced but low resolution celebrity photo, crops it to a close-up portrait and asks an AI to have a guess at what that person might look like at a higher resolution, to use in a Wikipedia infobox.) --Belbury (talk) 09:43, 16 July 2023 (UTC)
Trying for a wording on this, does AI upscaling software should generally not be used to increase the resolution or quality of an old or low-resolution image. Original historical images should always be used in place of AI upscaled versions. If an AI-upscaled image is used in an article, this fact should be noted in its caption.
seem reasonable, as a paragraph after the one on colorisation? --Belbury (talk) 09:07, 19 August 2023 (UTC)
- That reads well to me, and is good advice. This isn't FakedImagePedia. — SMcCandlish ☏ ¢ 😼 13:57, 19 August 2023 (UTC)
- I've now added this paragraph to the page. Belbury (talk) 17:22, 26 August 2023 (UTC)
- The correct way to do resolution reduction is well known in the Digital signal processing world. That said, less correct algorithms are often used, as they are faster. The correct process for upscaling is Deconvolution. The algorithms aren't quite as well defined as downscaling, though, but they also don't use AI. It is often used on scientific data, such as in spectroscopy. It was also used in the early Hubble Space Telescope images. Gah4 (talk) 03:09, 2 October 2023 (UTC)
Add disclaimer/note about different screen settings
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)
- 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)
thumbnails rendering at 170px by default, not 300px?
Does anyone know why, for me at least, the thumbnails at Dundas station (Toronto) are rendering at 170px and not 300px when both |upright and |thumb are set? Isn't the default for |upright = 1? —Joeyconnick (talk) 05:29, 12 June 2023 (UTC)
- No, the default is .75. See the warning in the Size section: "But upright alone, with no =scaling factor ... is equivalent to upright=0.75". This has caused confusion before, see the "Question" section above. I'm going to add some text. GA-RT-22 (talk) 12:54, 12 June 2023 (UTC)
- I question the need for the upright tag on those photos in that article. They are not large photos. BilCat (talk) 17:45, 12 June 2023 (UTC)
- Indeed. Except for very tall and narrow images, we should avoid fixing below the 220 px default, which is what using "upright" without a number achieves. Johnbod (talk) 17:55, 12 June 2023 (UTC)
- I suspect whoever added the "upright" tags was confused in the same way that OP in the "Question" section was, and assumed that "whenever possible" meant "always" and not "when an image must be scaled to something other than the default size". I hope my edit to the MOS has cleared this up. GA-RT-22 (talk) 19:46, 12 June 2023 (UTC)
- Wouldn't it make more sense to have a bot go through and change existing plain "upright" to "upright=0.75" and then make upright with no value = 1? I don't understand why it would default to 0.75. I am clearly not the first person to not know this weird default value.
- If 0.75 was some magic value that would fix all potentially large images, then sure. But it's not. Sometimes 0.75 will be too much and sometimes it won't be enough, so shouldn't it just do nothing by default unless someone has actually picked a value that has the intended effect? —Joeyconnick (talk) 03:57, 13 June 2023 (UTC)
- It actually is some magic number that fixes the majority of images. 4:3 is the most common aspect ratio for still photos. Take one of these and turn it on its side, and you will need to multiply the width by .75 to get an image of the same area as the original. I would be opposed to changing the default, because I don't want to have to remember that .75 is the right number to use. GA-RT-22 (talk) 04:19, 13 June 2023 (UTC)
- Agreed. And if it were changed, all the extant uses of it would have be bot-replaced to specify .75, because for many of them this size was chosen on purpose (or rather the
|upright=was used because it had this particular result). I know I only use it when the image is vertically too large, and using it produces an image of reasonable height in relation to the rest of the images on the page usually without further adjustment. — SMcCandlish ☏ ¢ 😼 18:45, 19 August 2023 (UTC)
- Agreed. And if it were changed, all the extant uses of it would have be bot-replaced to specify .75, because for many of them this size was chosen on purpose (or rather the
- @Joeyconnick: Getting the behaviour of plain
|uprightchanged isn't something that we can do here, it would require a change to the MediaWiki software, and would affect all wikis using that software - almost a thousand WMF wikis, and then there are all the non-WMF wikis as well. You could try filing a ticket at phab: and see what they say. --Redrose64 🌹 (talk) 22:26, 13 June 2023 (UTC)- Thanks but yeah, no: sounds pretty hopeless. I'll just adjust. —Joeyconnick (talk) 03:34, 14 June 2023 (UTC)
- It actually is some magic number that fixes the majority of images. 4:3 is the most common aspect ratio for still photos. Take one of these and turn it on its side, and you will need to multiply the width by .75 to get an image of the same area as the original. I would be opposed to changing the default, because I don't want to have to remember that .75 is the right number to use. GA-RT-22 (talk) 04:19, 13 June 2023 (UTC)
- I question the need for the upright tag on those photos in that article. They are not large photos. BilCat (talk) 17:45, 12 June 2023 (UTC)
Syntax style
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:
[[File:Siberian Husky pho.jpg|thumb|alt=A white dog in a harness playfully nuzzles a young boy |A [[Siberian Husky]] used as a pack animal]]
I would say that this is easier to read:
[[File: Siberian Husky pho.jpg | thumb | alt = A white dog in a harness playfully nuzzles a young boy | A [[Siberian Husky]] used as a pack animal]]
For the same reason that
A Siberian Husky used as a pack animal
is easier to read than
ASiberianHuskyusedasapackanimal
additionally,
[[File:Siberian Husky pho.jpg |thumb |alt = A white dog in a harness playfully nuzzles a young boy |A [[Siberian Husky]] used as a pack animal]]
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)
- 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)
- 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 is 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
{{Cite book| title =Yadda Yadda| last =Foo| first =Bar| date =2023| ...}}— SMcCandlish ☏ ¢ 😼 14:12, 19 August 2023 (UTC)
- 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 is 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
- Our documentation should reflect what editors typically do (especially since people tend to copy-paste from the doc and change the details). And, well,
[[File: Name | thumb | alt = Whatever | More Whatever]]is not it. The prevalent styles are[[File:Name|thumb|alt=Whatever|More Whatever]]and[[File:Name |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 "Wiki: Administrator's noticeboard" or "MOS: IMAGES". — SMcCandlish ☏ ¢ 😼 14:12, 19 August 2023 (UTC)
Image stacking
We really ought to add guidance that you shouldn't stack images.
[[File:1]]
[[File:2]]
[[etc...]]
Lorem ipsum dolor sit amet, consectetur adipiscing elit...
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)
- Yes - it is in there but should be strengthened. Mind you, in my experience most high-traffic articles have now been converted. I'd also like to see discouragement of "mosaic" multiple images, especially large ones. These are bad both on mobile and desktop. Johnbod (talk) 14:21, 19 August 2023 (UTC)
- What we should say is that there shouldn't be more than "a few" images in a
rowstack like that. There are plenty of cases where 2 or 3 or 4 in arowstack makes perfect sense (especially if some are left and some are right -- and please, I don't need to hear about SANDWICHing), and there may be places where even more (small?) images in arowstack might makes sense. Explain the reason and leave it to editor judgment. Please let's not have one more absolutist rule giving self-appointed roving enforcers another excuse for making pests of themselves. EEng 15:45, 19 August 2023 (UTC)- Oh well, maybe it isn't there - I can't find it, & if you can't, it probably isn't. We're not talking about "row"s here, but stacks or columns - let's not confuse ourselves. It should be in there - at the minimum all we need to say is to move images lower down to break up a stack. It used to be a sensible and very common tactic to stack all the images at the top of the article, so that there would be a continuous flow of images at the right of the screen, whatever the screen size or settings. With mobiles this doesn't work at all, as you get Pinterest before any text. We should advise against this. With the multiple images syntax you don't even get captions (there is an ongoing discussion re this at Talk:Prodigy_house#Multiple_Image). Johnbod (talk) 16:31, 19 August 2023 (UTC)
- Obviously stacking all of an article's images at the start of the article is no good. But stacking two images, relevant to a give section, at the start of that section is often better than having one image at the start, floated next to text, then a few whispy lines of text with no image floated next to them, then another image floated next to text. This usually looks awful.I'll say again: the important thing is to warn against big stacks. Modest stacks are OK. EEng 18:19, 19 August 2023 (UTC)
- Oh well, maybe it isn't there - I can't find it, & if you can't, it probably isn't. We're not talking about "row"s here, but stacks or columns - let's not confuse ourselves. It should be in there - at the minimum all we need to say is to move images lower down to break up a stack. It used to be a sensible and very common tactic to stack all the images at the top of the article, so that there would be a continuous flow of images at the right of the screen, whatever the screen size or settings. With mobiles this doesn't work at all, as you get Pinterest before any text. We should advise against this. With the multiple images syntax you don't even get captions (there is an ongoing discussion re this at Talk:Prodigy_house#Multiple_Image). Johnbod (talk) 16:31, 19 August 2023 (UTC)
- Images should be inserted at the point in the source that they belong to (that way they make sense in mobile). To avoid stacking, alternate images right and left and ignore all sandwiches (which are rarely a problem on desktop and never a problem on mobile). —Kusma (talk) 16:39, 19 August 2023 (UTC)
- I find sandwitching to be a problem on desktop. I also find overly rigid staggering that ignores article layout (especially left first - right, irrespective of headers) to worsen readability.—Alalch E. 17:53, 19 August 2023 (UTC)
- I use larger than default images on a wide screen, which almost guarantees that sandwiching will happen whenever there are any left-aligned images. It is nearly impossible to illustrate an article well without sacrificing something: the gallery and multiple images options do not support automatic resizing to larger thumbnail sizes. I personally prefer sandwiching to having to use fixed image sizes. —Kusma (talk) 18:13, 19 August 2023 (UTC)
- "It is nearly impossible to illustrate an article well without sacrificing something" - Agreed. "the gallery and multiple images options do not support automatic resizing to larger thumbnail sizes." That will probably be fixed some day, and those layout tools still make sense in various cases (e.g. gallery at Regimental tartan#Late 18th century diversification, where the list isn't even complete yet, and where using a table with regular
[[File:...|thumb|]]markup would waste a lot of space). — SMcCandlish ☏ ¢ 😼 18:41, 19 August 2023 (UTC)
- "It is nearly impossible to illustrate an article well without sacrificing something" - Agreed. "the gallery and multiple images options do not support automatic resizing to larger thumbnail sizes." That will probably be fixed some day, and those layout tools still make sense in various cases (e.g. gallery at Regimental tartan#Late 18th century diversification, where the list isn't even complete yet, and where using a table with regular
- "I also find overly rigid staggering that ignores article layout (especially left first - right, irrespective of headers) to worsen readability." Definitely. It can make it hard to tell where sections/subsections start and what the heading depth is. As for "I find sandwitching to be a problem on desktop." What kind of problem? Can you link to an example? Are you on some really tiny monitor or something? — SMcCandlish ☏ ¢ 😼 18:41, 19 August 2023 (UTC)
- I use larger than default images on a wide screen, which almost guarantees that sandwiching will happen whenever there are any left-aligned images. It is nearly impossible to illustrate an article well without sacrificing something: the gallery and multiple images options do not support automatic resizing to larger thumbnail sizes. I personally prefer sandwiching to having to use fixed image sizes. —Kusma (talk) 18:13, 19 August 2023 (UTC)
- I find sandwitching to be a problem on desktop. I also find overly rigid staggering that ignores article layout (especially left first - right, irrespective of headers) to worsen readability.—Alalch E. 17:53, 19 August 2023 (UTC)
- Are we ready for a draft? I think we are boadly in agreement, but I think there are still a good number of editors for whom "stacking all of an article's images at the start of the article is no good" is not yet obvious. I'm ok with two or more in a stack, if there is a good reason, but usually there isn't. Otherwise there's no reason not to space them out a bit, and we should say so in a non-absolutist way. I used to stagger left & right, but now I generally only put images that strongly "face into the page" on the left. That's enough for now, but one day we should update WP:GALLERY, which has hardly changed for 15 years, and doesn't even mention the use of "mini-galleries" placed around the article in visual subjects. Johnbod (talk) 22:15, 19 August 2023 (UTC)
- The "good reason" is actually quite common, and it's a long lead and/or ToC, producing a huge block of whitespace on the right (in a regular browser view; not sure about on mobile). — SMcCandlish ☏ ¢ 😼 04:20, 29 August 2023 (UTC)
- If it's a long lead the images for that should be spaced out, between paragraphs. For those still on the old desktop default, a long TOC is a reason to stack, but what proportion of our readers are still viewing like that? You had to be registered, and to override the new default. Johnbod (talk) 02:34, 2 September 2023 (UTC)
- The "good reason" is actually quite common, and it's a long lead and/or ToC, producing a huge block of whitespace on the right (in a regular browser view; not sure about on mobile). — SMcCandlish ☏ ¢ 😼 04:20, 29 August 2023 (UTC)
Dragable image comparisons
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)
Flags
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 icons in particular, it says so explicitly. We need to do a WP:SUMMARYSTYLE section at MOS:IMAGES that encapsulates the general 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); rev'd. 06:37, 8 September 2023 (UTC)
Dispute over censoring an image
At Talk:Anna Krauss we have a dispute over inclusion of this image of the biography’s subject. Per WP:OM, WP:NOTCENSORED and, of course, this page, I believe that the encyclopedic value of the image, which has no suitable substitutes, outweighs its potential for shock and offense. I would appreciate input from editors there, as it is just my opinion against that of Scope creep at this point. I have left a similar note at Wiki talk:Offensive material. — HTGS (talk) 02:04, 2 October 2023 (UTC)
- I am a believer in WP:OM and WP:NOTCENSORED, and so believe it should stay. Gah4 (talk) 02:49, 2 October 2023 (UTC)
How to put image in the correct section?
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)
- 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)
- @Cunard: It's easy to explain. The article begins with a
{{Infobox restaurant}}immediately followed by a{{Infobox Chinese}}, 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{{Infobox Chinese}}, the top edge of the image cannot be any higher than that of the second infobox. --Redrose64 🌹 (talk) 20:09, 8 October 2023 (UTC)- Thank you, Redrose64 (talk · contribs). I guess there's no way to fix this with these two infoboxes. I don't think
{{Infobox Chinese}}can be emedded with{{Infobox restaurant}}, which lacks a "module" parameter like Template:Infobox person has. Cunard (talk) 23:07, 8 October 2023 (UTC)
- Thank you, Redrose64 (talk · contribs). I guess there's no way to fix this with these two infoboxes. I don't think
- @Cunard: It's easy to explain. The article begins with a
edit request
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:
- {{anchor|Sandwich}}{{Shortcuts|MOS:SANDWICH}}{{-}} [[File:The suicide of Cleopatra; the asp is wriggling up the left a Wellcome V0041560.jpg|thumb|330px|... can create a distasteful text sandwich (depending on platform and window size).]] [[File:Harvard Theatre Collection - Sarah Bernhardt TCS 2 (Cleopatra) (cropped).jpg|thumb|left|330px|Wide images opposite one another{{nbsp}}...]]
Thanks. 173.67.42.107 (talk) 12:47, 8 October 2023 (UTC)
Fixed. 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)
"Mos:LEADIMAGE" listed at Redirects for discussion
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 Wiki: Redirects for discussion/Log/2023 October 11 § Mos:LEADIMAGE until a consensus is reached. Utopes (talk / cont) 23:45, 11 October 2023 (UTC)
Value of a color vs. black and white infobox portrait
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)
- Might be helpful to see examples, to get an idea of the relative image qualities. — SMcCandlish ☏ ¢ 😼 18:54, 26 October 2023 (UTC)
- A pretty representative example would be for Michael W. Grebe: color vs. b&w Star Garnet (talk) 20:17, 26 October 2023 (UTC)
- 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)
- A pretty representative example would be for Michael W. Grebe: color vs. b&w Star Garnet (talk) 20:17, 26 October 2023 (UTC)
- 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)
MOS:SANDWICH
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)
- My guess is because it makes paragraphs pretty narrow on monitors that aren't wide screen. Magnolia677 (talk) 13:56, 1 November 2023 (UTC)
- 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)
- 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)
- @Johnbod: 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)
- 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)
- 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)
- 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 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-
- 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)
- 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)
- 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)
- I strongly disagree.
The average monitor size on desktops has gotten larger
– 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)- 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 effective 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)
- I strongly disagree.
"horrifying"
A recent edit changed
Wiki is not censored: its mission is to present information, including information which some may find offensive. However, a potentially offensive image—one that would be considered vulgar or obscene by typical Wikipedia readers—should be included only if it is treated in an encyclopedic manner, i.e. only if its omission would cause the article to be less informative, relevant, or accurate, and no equally suitable alternative is available.
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)
- 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)
- '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)
- 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)
