Wikipedia talk:Manual of Style/Images/Archive 7

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 5

Question about image size and mobile devices

I'm a tech-dummy, and at the moment I'm too exhausted to read through the gigantic amount of argumentation above. What I want to know, simple and stupid, is how image size plays out on those devices compared with big desktop monitors; and whether this underlies the disputes about the tone of the guideline concerning the forcing of image size (larger, I presume).

A subsidiary question is whether this discussion might help us to form a request to WMF engineering and product for how the technical handling of images by the software might be improved.

Tony (talk) 05:22, 6 February 2016 (UTC)

On my mobile device (a Samsung Note 4, both in a browser and with the Wikipedia App) images are shown full-width, ignoring the markup of how wide they should be and also using the same width regardless of whether I am reading in landscape or portrait mode. So all the debating above is mostly irrelevant for mobile, unless something changes. —David Eppstein (talk) 06:20, 6 February 2016 (UTC)

Well, in my experience with various phones, and iPad, I get something different that D.E. gets -- images are presented on mobile at the same size they're presented on Desktop. Either way this has nothing to do with upright vs. px -- mobile either ignores them both completely for mobile, or does everything the same way for mobile as it does for desktop.

The difference between px and upright is this...

Suppose an image is specified as |thumb|330px. It will always be shown 330px wide -- the idea being, of course, to present it wider than than normal (50% larger than the 220px most users will get if |thumb is used alone).
But now consider a user who's set his thumbnail preference to 400px. This user, apparently, wants to see images much wider than normal -- bad eyesight or whatever. But the image coded as |thumb|330px will always be 330px -- so that this image, which editors obviously felt needed an especially large presentation, will now come out smaller than the 400px width that another image in the same article, coded simply as |thumb, will come out! This makes no sense at all.
In contrast, if you code |thumb|upright=1.5, then the usual reader (who has left his preference at 220px), still gets that image at 330px. But the bad-eyesight reader, who's changed his preference to 400px, gets that image at 600px -- 50% bigger than images coded |thumb. That makes sense.
Going in the other direction, take a user who's set his Preference to 120px -- slow internet connection? -- so that images coded |thumb come out 120px wide. But an image coded |330px completely ignores his preference, and gives him an image almost 3X the size of a |thumb image. But if we code |thumb|upright=1.5 instead, now he gets 180px i.e. respecting both his preference for 110px as the default, and the article editors' decision that this particular image deserves to be 50% bigger than that. Again, that makes sense.

For the vast majority of users, who leave their preference at 220px, upright gives exactly the same thing as px anyway. But should a user choose a different default for whatever reason (bad eyesight, slow internet), upright respects that by scaling everything proportionately up or down, whereas px ignores the readers's preference and presents the same fixed width, regardless. Honestly, I can't see why anyone would prefer this. It makes no sense. (Unfortunately there are some infoboxes etc. which don't accept upright, so you're forced to use px.)

E Eng

(ec) I believe what David Eppstein says is generally true, in so far as any statement about small screen devices as a group can be; they treat the images in their own way, ignoring the markup. Re what Eeng says above, this only goes part of the way. What makes no sense at all is having two systems - if you have prefs at 400px, yes some images will be smaller than you might want, but the real problem is the ones that are too large, with upright set over 1.00. The results of this for tall narrow images can be just bizarre - effective px sizes of 700px or more. We should not mix systems, and since fixed px is overwhemingly more widely used we should stick with that. Johnbod (talk) 06:35, 6 February 2016 (UTC)

Your post is somewhat jumbled, but you seem to be saying that if the user has preference set to 400px, and there's an image with (e.g.) upright=1.8, you'd get an image 700px wide (instead of the 400px he'd get if he's left his preference at 220px). Yes, that's true, but so what? When the user set his preference to 400px, that's what he was asking for -- images about twice as big as usual. Why not give him what he's asking for? That's what preferences are for. E Eng 06:52, 6 February 2016 (UTC)

I'd forgotten quite why I resolved years ago, like so many, to avoid getting drawn into any talk page you were engaged in. Now you remind me. Johnbod (talk) 06:56, 6 February 2016 (UTC)

Oh boy! Here we go! "Like so many" -- ha ha ha ha ha! Let me see if I can guess the reason -- would it be that reasoned argument contrasts so starkly with muddled, borderline unintelligible posts which are never clarified when clarification is requested? E Eng 07:11, 6 February 2016 (UTC)

No, that's not it. Johnbod (talk) 08:25, 6 February 2016 (UTC)

Oh. Then maybe it's the cognitive strain of coyly hinting, as here, without ever saying what you really mean? E Eng 07:28, 7 February 2016 (UTC)

Incidentally, I strongly suspect that one reason the small screen devices ignore the markup is because historically editors have used px sizes which might make sense on typical computer screens but make no sense for much smaller screen widths. I.e., using px gives no useful information about how big to make an image when you're displaying it on something different than a 2003-vintage computer screen. upright, on the other hand, does tell you something useful: which images should be enlarged, which should be reduced, and by how much. So if you want markup that will not eventually be completely useless, upright not px is the way to go. —David Eppstein (talk) 06:54, 6 February 2016 (UTC)

Just so. Listen, since you're here, I was thinking of adding a little px-to-upright conversion table, as a footnote to the Size section. Think I should mock that up to see what it looks like? E Eng 07:03, 6 February 2016 (UTC)

At this point, I'm skeptical that we could even correct blatant spelling errors in this section of the MOS without some editors complaining about edit warring and demanding a reversion, with nonsensical claims about how since that's the way it's always been spelled it must be the right way to spell it. Which is to say, maybe we should continue to try to build consensus for upright before making changes that presuppose that consensus. But such a table might at least make a useful contribution to the discussion here, to give participants a clearer idea about what upright= actually means. —David Eppstein (talk) 07:38, 6 February 2016 (UTC)

You can't "build consensus for upright" in the wash at the bottom of a way over-long RFC which was launched about something else, without even mentioning upright settings. You may only just have heard of upright, but it has been around for many years (it was actually more popular about 5 years ago), and most regular editors are aware of it, but choose not to use it. If you want to test opinion on the matter, I suggest leaving the matter for a few weeks to allow regular watchers here to recover, then launching a straightforward RFC which says what it is doing on the tin. This should be as widely advertised as possible, as a preference for upright is a massive change if taken seriously. Johnbod (talk) 08:06, 6 February 2016 (UTC)

Your suggestion for another RfC comes off more as concern trolling than as useful advice. We already have too much confusion of multiple RfCs, one on this exact subject already going on since last summer. Adding more will make the situation murkier, not clearer. —David Eppstein (talk) 08:17, 6 February 2016 (UTC)

@EEng: Please do create the table you mentioned, and add it to Help:Image; it would be very useful. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:54, 2 March 2016 (UTC)

It's already at Wikipedia:Manual_of_Style/Images#Size. But Help:Image is a little bare-bones -- where would the table fit in there? Anyway, do with it as you will. E Eng 05:36, 2 March 2016 (UTC) Oops, better ping: SMcCandlish E Eng 05:37, 2 March 2016 (UTC)

Here I read a lot about preferences. But unregistered users have only one choice, and the big majority of readers are unregistered users. Isn't so? Why then don't we assume preference = 220px as a fixed setting? And consider first of all if it's the case of changing it? Carlotm (talk) 07:49, 6 February 2016 (UTC)

Pardon me if I have misunderstood your comments in part. That's a good argument for, as an editor working with layout, keeping one's own preference at 220px. It's not a good argument for using px in layout, if that's what you mean. Re your last sentence, are you referring to a software change to increase the default size for unregistered users? That's been discussed at length, multiple times, and no consensus has been reached to do that. I suspect we revisit it every few years. ―Mandruss ☎ 08:14, 6 February 2016 (UTC)

See, this is what I mean about giving participants a clearer idea about what upright means. If you use upright to scale your image, you will respect both the default 220px preference and the preferences of the users who decide to change it to something else. If you use px to scale your image, you will respect only the people who leave the preference as the default, and screw up the appearance for everyone else. upright= works for everyone. px works for a subset of users. Why is this so hard to understand, and why are people so hostile to something that works at least as well in all cases and better in many? —David Eppstein (talk) 08:17, 6 February 2016 (UTC)

(ec again) Most editors do I think assume that the great majority of other readers (on desk-top) have 220 as default - I certainly do, although my own preference is set at 300. It is that assumption that makes the fixing of some images that need to be larger (or, very rarely, smaller) sensible, for example in lead pics. Increasing the default is a rather different matter - personally I'd welcome 240 at least, but actually I haven't seen a significant debate for some years. Of course, the relatively small number of images now set using "upright" would then be a problem - they would automatically increase, often to unreasonable sizes. Johnbod (talk) 08:25, 6 February 2016 (UTC)

They would automatically increase, and that would be a good thing, and it is precisely the point of upright. Far from increasing to an unreasonably large size, the images would increase from an unreasonably small size resulting from increases in overall screen resolutions. Upright allows for change in technology, px does not. ―Mandruss ☎ 08:30, 6 February 2016 (UTC)

No, because the people who set them using upright were also using a base assumption of a 220 default. If there was a 280 (ok 220-240 would not usually make much difference) default they would have used a different scaling factor. For most images it doesn't matter much, but for tall thin ones (like say Asian scroll paintings) it can make a huge difference. Johnbod (talk) 08:35, 6 February 2016 (UTC)

They would have used a different scaling factor for the prevailing screen resolutions at that time. If screen resolutions were higher then, they would not use a different scaling factor. I say again, the 220px default reflects, or attempts to reflect, current screen resolutions, which will change. If images seem to be shrinking due to increases in screen resolution, the answer is to increase the system default, not to start using upright>1 on a wide scale, and certainly not to use px. ―Mandruss ☎ 08:41, 6 February 2016 (UTC)

Here I definitely agree with you. The majority of images should be left with the default scaling rather than adjusting it, whether that adjustment be via px or upright. When images are set larger or smaller than the default it should have a reason, specific to that image (such as small details that would become illegible at the default size, or to adjust for a far-from-square aspect ratio), not because one feels the default is wrong. —David Eppstein (talk) 08:54, 6 February 2016 (UTC)

I can certainly agree with that. In my experience, fixed px images set excessively large get reverted pretty quickly, ones set too small don't. With upright more problems come with setting to increase rather than decrease the size. Johnbod (talk) 11:14, 6 February 2016 (UTC)

University of Oklahoma is a possibly illustrative case. It uses no-value upright (same as upright=0.75) for three tall images, upright=0.6 for one tall image where the related prose doesn't leave much space for an image, and default for everything else. If one has a "typical" screen resolution (and we could argue about that till the cows come home), their preference setting is 220px, and they feel the images in that article are generally too small, they should argue for an increase in the system default. (I have 1366x768, which I believe to be "typical" enough, my preference is 220px, and I could see an increase to 240px but probably no more at this point.) They should resist the temptation to add upright>1 to a bunch of those images, as that would be counterproductive in the long term. When the system default were finally increased, the images would be too large. There would be wide disagreement as to what is "too small", but that's how the discussion should be framed. (And if one's preference setting is not 220px, they probably shouldn't be in the discussion, since they are not seeing what a majority of readers see.) ―Mandruss ☎ 09:42, 6 February 2016 (UTC)

As an editor there is much to be said for that - but as a reader, largely of art articles, a 220 default would rapidly drive me nuts. If there was a one-touch way to toggle between them, that would be handy for editing. I'm glad to see below you support a rise in the default to 240, & I hope agitation for that starts soon. Johnbod (talk) 11:14, 6 February 2016 (UTC)

If you feel that (1) the objective is to save the reader a click on the thumbnail to see the larger image (BIG disagreement on that question on this page), and (2) art articles are a special case where images need to be larger than other images, that would suggest warranted widespread use of upright>1 in art articles. It shouldn't be a factor in discussions about the system default, which has to apply site-wide. ―Mandruss ☎ 11:25, 6 February 2016 (UTC)

No, I don't feel either of those. Johnbod (talk) 11:38, 6 February 2016 (UTC)

(confused) Then why would 220 drive you nuts in art articles? If the click-thru is not a problem, a 50px thumbnail should be theoretically large enough to do the job - just large enough to give some idea of what is waiting on the other side of the click. ―Mandruss ☎ 11:44, 6 February 2016 (UTC)

(amazed) It would drive me nuts on all articles. Look at the rest of the media, electronic and paper. Where else, outside stamp-collecting, are people expected to deal with images as small as a 200px WP setting? Of course no one (outside, apparently, some on this page) thinks that the idea of the images in an article is only "to give some idea of what is waiting on the other side of the click". Most of our readers (I find doing training) don't even know you can click through, and very few want to click through very often - nor should they need to. Johnbod (talk) 10:52, 7 February 2016 (UTC)

I didn't say what you apparently thought I said, and apparently vice versa. Since we appear to have trouble communicating, let's leave it here. ―Mandruss ☎ 10:57, 7 February 2016 (UTC)

(e.c. with Mandruss) A few comments/queries, then.
(1) Why is it called "upright". That itself is confusing. Even I was under the impression that it somehow alters the horizontal–vertical ratio, or is suitable only for relatively tall images.
(2) I'm surprised that personal settings are even mentioned in this thread: they're relevant only to logged-in editors, whereas our concern is surely for our readers.
(3) David E., could the unusual outputs on your devices be browser-related? No one's talking browsers here, but I have a sneaking suspicion that they matter.
(4) Mandruss, you wrote: "That's a good argument for, as an editor working with layout, keeping one's own preference at 220px." It's my experience that many detail-rich images display too small at default (on my big desktop monitor), which underlies my habit of boosting, typically to 240px (maybe I should be inserting upright 1.1 instead ...?). This also relates to your query: "are you referring to a software change [by WMF techs] to increase the default size for unregistered users?" That would be good in my view. I co-ran the consensus-gathering and WMF liaison to move the default from 180px to 240px, back in 2010, I think it was. Many editors wanted more than 220px.
(5) I'm also keen to explore technical ways of minimising the locational issues we have between images and surrounding text, including the intrusion of just a line or two of text between images whose syntax is not placed together in edit-mode. It's one reason I typically do shove the syntax for many or all of the images into one location—at the top or under subtitles. Is this undesirable for our users? Tony (talk) 09:47, 6 February 2016 (UTC)

Re (1), we originally invented upright with no support for a value, meaning default*0.75, as a suggested size for "tall" images, those with greater height than width. Later, we decided to add full scaling capability, and chose to use the existing upright parameter for that. That resulted in the confusion you speak of, and there has been discussion (some of it recently on this page) about renaming upright to scale to eliminate the confusion. My previous comments might clarify some of the rest of yours, which appear to be the result of the EC. ―Mandruss ☎ 09:56, 6 February 2016 (UTC)

Comment – As a neutral third-party just making an observation here, it would seem that perhaps the way to go is to ignore all manually set parameters (px and upright) whenever the personal preference is set by a registered editor. If this were the case, then we wouldn't need to be having these discussions. Both parameters px and upright would be become equally effective, as they would only apply to those with the default system setting of 220px. Therefore, all manual scaling would be performed with the same reference point in mind, 220px. Now the knee-jerk reaction to that suggestion, of course, would be the concern that images might appear to be too big or too small in some situations to those who have manually set their preferences. I would argue that would only be the case in extremely rare situations, and that the issue is a reasonable trade-off to having the ability to manually set your image preference. If the upright parameter worked in ALL situations, then that would have been the better solution. Since that's not the case, however, then we should err on the side of the default setting and look for an alternative approach such as the one I mentioned: change the way the preference setting operates as opposed to finding the perfect image parameter. --GoneIn60 (talk) 15:29, 6 February 2016 (UTC)

whenever the personal preference is set by a registered editor. - Every registered user has this setting initialized to 220px by the software when they create their account. For those who still have that value, it's impossible to know whether they are even aware that setting exists. Since your entire argument seems to rest on that false premise, there's no reason to respond to the rest. ―Mandruss ☎ 16:00, 6 February 2016 (UTC)

Let me clarify. Whenever the preference is set to a value other than the default, image parameters should be ignored. I understand this was a technicality you discovered in my suggestion, but reasonably I think you know what I meant. --GoneIn60 (talk) 16:26, 6 February 2016 (UTC)

Well, even if I fully understood your rationale, I think things are confusing enough for editors without conditionally ignoring what they code for images. As we've clearly seen, too many already have trouble grasping the existing concepts, which are less complicated than what you suggest. ―Mandruss ☎ 16:31, 6 February 2016 (UTC)

I'm not sure how my suggestion would be more complicated. It takes the thought process out of the equation. Editors can manipulate images as they see fit, just as they do now, only those who have changed their image preference will not be subject to those changes. They'll continue to see images at the size they've specified in their user preferences, and the image parameters set in the article will be ignored. It's quite simple really. --GoneIn60 (talk) 16:38, 6 February 2016 (UTC)

So you're saying that setting a default other than 220 would be interpreted to mean you want all images to be that size, regardless of the characteristics of the image. Rather than being a base size, it would be the size, full stop. It would completely eliminate the benefit of editorial judgment for those users. I don't think that's a good thing, but I'm interested in other reactions. ―Mandruss ☎ 16:55, 6 February 2016 (UTC)

Under GoneIn60's proposal, upright becomes just a weird alternative way of expressing exactly the same thing as px -- you can say upright=1.5 if you mean 330px, or upright=.8 if you mean 175px -- except that (under his/her proposal) for users who select a default width other than 220px, all image size coding is suddenly ignored and all images come out exactly the same width -- a tall portrait the same as a wide panorama -- with no way for editors to change that. This makes no sense at all.

As David Eppstein has pointed out, upright works at least as well as px in all cases, and better in many. For the majority of readers, whose default width is 220px, they work the same. But for the few others, who for some reason (presumably important to them) have changed the default, upright respects that change, by responding proportionately to it, whereas px just ignores what the reader has asked for. (Since some readers may increase their default for eyesight reasons, this might even be seen as an accessibility issue.) E Eng 17:12, 6 February 2016 (UTC)

(edit conflict) @Mandruss: That is correct. In my opinion, it's the lesser of the two evils. Right now, a user's image size preferences is already being ignored when the px parameter is set on an image. This suggestion would remove that limitation and allow the image size preference to take precedence. Similarly, the upright parameter may not scale correctly in some situations as described in previous threads. By ignoring that setting as well, we eliminate some cases where that is an issue. I understand the desire to have editorial judgment over the size of an image, and it would still be an available option that impacts a majority of Wikipedia users (IP editors and registered users that have not changed their image preference). The only other option I can think of, would be to eliminate the px parameter altogether and only use upright. I think that's the next best option after listening to the arguments above. --GoneIn60 (talk) 17:29, 6 February 2016 (UTC)

EEng, I wouldn't suggest that ALL image coding parameters be ignored; only those pertaining directly to image size. The ability to adjust height/width ratios should be retained and not ignored – if there was a way to do that, of course. I'm not as technically savvy in this regard, so perhaps the implementation of my suggestion is not possible. If that's the case, then we should definitely take a good look at limiting or eliminating the px parameter as you and others have suggested. --GoneIn60 (talk) 17:39, 6 February 2016 (UTC)

Um, I said that under your proposal, "for users who select a default width other than 220px, all image size coding is suddenly ignored", and that's true -- px and upright are the only size coding there is, and your proposal is to ignore them when the user sets his preference away from 220px.
You say, "the upright parameter may not scale correctly in some situations as described in previous threads" -- I have no idea what situations these are. upright does what it's supposed to do, and does it right, under all circumstances.
"eliminate the px parameter altogether and only use upright" -- no one's suggesting that radical solution, because there are obscure situations (e.g. inline images) where px makes sense, and a few other situations (e.g. some infoboxes and templates) which can't, as of now, technically handle upright.
"ability to adjust height/width ratios should be retained" -- there's nothing that allows height/width ratios (aspect ratio) to be adjusted, because that would distort images like a funhouse mirror; all these sizing techniques change the images's width and the software automatically adjusts the height proportionally, to preserve the original aspect ratio. Perhaps you meant something else?

E Eng 18:47, 6 February 2016 (UTC)

I think there is a consensus for discouraging px somewhat strongly, but it can never be eliminated completely. I often convert px to upright when I see it, without going all fanatical about it. Those of us who are aware should do the same, linking to WP:IMGSIZE in our edit summaries, and spread the word when the subject comes up in article talk. px has been the wrong move since scaling capability was added to upright, that has been in the guidance for a long time, and too few editors knew about it. Many of those who knew about it ignored the community consensus because they didn't understand it or disagreed with it, and they continue to do so. The solution is to educate editors about px, and educate others about WP:CONSENSUS, not to create hack solutions in an attempt to accommodate their ignorance. ―Mandruss ☎ 17:44, 6 February 2016 (UTC)

Mandruss, as an editor you combine perfectly the ideals of reason, prudence, and diplomacy. Higher up somewhere I proposed adding a table of px-upright equivalences (for a user with default 220px), and I think I'll do that now, in pursuit of your educational goal. E Eng 18:47, 6 February 2016 (UTC)

I'm hoping you people can cooperate more closely to turn this discussion into solid proposals that are likely to gain wider consensus. There seems to be irritation in the air. Please no. Tony (talk) 11:14, 7 February 2016 (UTC)

[[Mandruss, I was trying, days ago, to clarify my thoughts about this complicated question of how to treat images in Wikipedia. The first, and only, point I was questioning in my note was the possibility for registered users to change the default value = 220, which I believe should be removed from these discussions. It's only a private choice of some editors and doesn't affect how the big majority of readers see Wikipedia pages. There are also many other aspects that I would like to consider, some about content and some about how the material is presented particularly in regard to new editors. But now I want to add only one other point, about which I know you don't agree. It's the usage of |upright as the main way of setting images' dimensions. I am of the opinion that it's unnecessary and divisive. In designing the layout of a Wiki page many are the elements that play important roles: infoboxes, templates, tables, almost all of which are expressed in absolute terms, i. e. in pixel. Why then some editors, and you among them, consider the |upright tag as a panacea for all issues and the primary way of dealing with image setting, is beyond my understanding. Carlotm (talk) 07:04, 13 February 2016 (UTC)

Over the years, there has been a pulsating trend away from proprietary techniques and pixel-perfect layout in webpage design. Part of the reason was in acknowledging that it is difficult to predict either the future or the screen width of "readers" (or even whether they were using a screen at all).

Nobody here that understands the complexities and subtleties involved is suggesting that the (misleadingly named) upright syntax is a panacea.

However, for most of our editors (who are perhaps not that interested in learning about the finer points of file syntax, image sizing or image placement), the text on this MoS page should be both educational and clear.

That means that the language used here should

[firstly] encourage editors to use thumbnails as a default image style (unless there are adequate reasons not to),

[secondly] encourage editors not to specify any size at all when using thumbnails as a default image syntax (unless there are adequate reasons to specify a width),

[thirdly] encourage editors not to specify any size at all using (the long deprecated) fixed sizing syntax of px when using thumb or frameless as an image syntax (unless there are completely adequate reasons to specify px).

And yes, I do agree that there is still a lot of work to be done in changing many infobox templates, etc. so that the occurrences where we have to type pee and ex become increasingly rare.

(Incidentally, although this draft User page demonstrates that it is difficult to avoid table width problems entirely when using relative image sizing, it also demonstrates (for users that have not increased their default base image width) that using px may be less compulsory in tables than you might think...)BushelCandle (talk) 09:53, 13 February 2016 (UTC)

Is this an example of what the complaint was about?

At Wikipedia:Village_pump_(miscellaneous)#Is_the_infobox_at_Planet_Nine_a_disinfobox.3F there was a complaint about an image that may be what was bugging the people I kept asking about what was the big beef about in their changes to the pertinence section. Is this an actual example and how do people feel about it? Dmcq (talk) 18:05, 7 March 2016 (UTC)

Interesting discussion and thanks for drawing it to our attention, Dmcq.

I don't think either the original pertinence wording or the latest 'pertinence proposal' assist a decision at that page. As ever, it will be up to the local consensus of editors to decide... BushelCandle (talk) 23:59, 7 March 2016 (UTC)

Fixing images below the default size

There were numerous different wordings and suggestions proposed and none of them had consensus. A lot of the supports and opposes were incredibly unclear as to what exactly they were supporting or opposing, and the huge tangent about image alignment doesn't help. Reading this discussion made my brain hurt. Summary, no consensus for anything, as the discussion was not organized enough to reach one. (non-admin closure). Oiyarbepsy (talk) 00:20, 7 April 2016 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This used to be deprecated in the MOS, and it certainly should be (sorry, can't provide a link - I'd be grateful if anyone can). I don't want to re-open the vexed issue of fixing at higher than the default 220px, which we currently deprecate, but like many people I routinely do this, at least for main images in the lead. The case against smaller-than-default images seems much simpler - is there ever a good reason for doing this, for images with a typical aspect ratio? I can't think of one, and have for years removed all examples of "120px" etc that I see, & I don't remember anyone ever complaining. There is an exception needed for images eg 10 times taller than they are wide, but I think the existing text covers that fine. However it gives the clear impression that too small images are fine with the MOS.

Proposals

A) At the moment we say: "As a general rule, images should not be set to a larger fixed size than the 220px default (users can adjust this in their preferences). If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding."

I propose changing this to "As a general rule, images should not be set to a larger or smaller fixed size..." (new text in bold). Any objections?

B) I'd also like to add something specifying that this applies to multiple images, which seem (unfortunately in my view) to be fashionable at the moment. So at the end of the list of bullet points, I'd like to add:

"* Multiple image templates should not be be over-used, and each image should appear at at least the default image size."

Please comment on these below, specifying A & B. Thanks Johnbod (talk) 21:57, 12 June 2015 (UTC)

Discussion

Fixed image sizes should be avoided in general, but there are cases where they're appropriate, such as in tables. Exceptions should be exceptional, though, and I think they are covered by the "as a general rule" wording—so, basically, I agree with what you've presented. Curly Turkey ¡gobble! 22:24, 12 June 2015 (UTC)
I've seen fixed images done on infobox images all the time. I agree that outside tables (which infoboxes technically are) fixing the size should be avoided. --MASEM (t) 22:43, 12 June 2015 (UTC)
Images in infoboxes count as lead section images, which have always been permitted to be larger - up to 300px wide. As regards images in actual tables, see Rolling stock of the Bluebell Railway#Steam locomotives, where the images are 200px wide, including the upright ones - which makes some table rows excessively tall; compare List of Great Central Railway locomotives and rolling stock#Mainline steam locomotives (175px) or Rolling stock of the Kent & East Sussex Railway (heritage) (150px). --Redrose64 (talk) 22:53, 12 June 2015 (UTC)

Can we get away from the usual issue of whether fixed sizes are good, bad, or downright evil, to address the question of whether this page should continue to use language that implies that images fixed small are better than images fixed large? I agree table images are another exception. Johnbod (talk) 03:23, 13 June 2015 (UTC)

Oppose. I would oppose both as instruction creep, especially the multiple-image template suggestion, not because I like small images (the opposite is true), but because these decisions should be left to the people writing the page, not imposed centrally. Editors forget that the MoS is just a guideline, and go around trying to force it on articles in which they otherwise have no involvement. Every additional rule creates another weapon. This makes the MoS strongly disliked (e.g. see the recent discussions about creating a central style board), which is unfortunate because it's a very helpful document for style advice. Sarah (SV) ^(talk) 00:28, 13 June 2015 (UTC)

As my comment above. Johnbod (talk) 03:23, 13 June 2015 (UTC)

Comment. This discussion has caused me to discover relative sizing (|upright=) which I didn't know about before but seems preferable to absolute sizing in almost all cases. I had thought that gif animations and bitmap images smaller than the default size needed absolute sizes to allow the animation to work and prevent being resized to larger than the resolution of the image, respectively, but if that was ever true it doesn't seem to be any more. However, there doesn't seem to be a way to use |upright= within {{multiple image}}, and there are probably other cases where absolute sizing is still important, so I wouldn't want to see a blanket prohibition. On the other hand, the same reasons that larger-than-default absolute sizes are bad make smaller-than-default sizes bad as well, so expanding the recommendation about fixed sizes to include smaller-than-default ones seems harmless. If we're going to make this change, it would be simpler to say simply that "as a general rule images should not be used with fixed sizes". The part about whether the size is larger or smaller than the default is a red herring and should be left out; why is using a fixed size equal to the default any better of an idea than the other two cases?—David Eppstein (talk) 00:38, 13 June 2015 (UTC)
- I agree with Mr Epstein—the wording should be more like "As a general rule, images should not be set to a ~~larger or smaller~~ fixed size..." (I think that addresses SV's concerns about instruction creep as well) Curly Turkey ¡gobble! 03:45, 13 June 2015 (UTC)

I have used smaller-than-default-size images on occasions, when the infobox equates or exceeds in length the text on the left. I figure that a smaller image facing that long infobox will be less offensive to the anti-sandwitching purists who believe that no images should ever face a sacrosanct infobox. The only other solution is to place the image below the infobox, and out of view --Lubiesque (talk) 12:07, 10 November 2015 (UTC)

Comment - "a larger or smaller fixed size" reduces to "a fixed size", and conciseness is always good. Larger or smaller than what? I'd support "a fixed size" first, the longer version second. In any case, all guidance should discourage fixed sizes except where there is very good reason to use them, as they defeat the user preference (which is more than an aesthetic preference). I just recently learned that even infobox images can specify a proportional size by coding File: syntax for |image= and omitting |image_size=, as here. I think that's generally a Good Thing, not that it warrants an implementation crusade. No opinion as to the multiple images question. ―Mandruss ☎ 16:33, 8 January 2016 (UTC)
Comment - Nobody anywhere in this discussion above seems to think that, except for certain exceptions, flouting reader's preferences and setting image sizes to a fixed, specified size in pixels (rather than using relative sizing) is a good idea (despite this reversion). I also agree that the minimum change necessary would be to substitute

As a general rule, images should not be set to a fixed size. If an exception to this general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding.

for the current advice. BushelCandle (talk) 20:59, 8 January 2016 (UTC)

This change would also brings our advice into line with our advice at Wikipedia:Image use policy#Displayed image size:

Except with very good reason, do not use px (e.g. thumbɭ300px), which forces a fixed image width. In most cases upright=scaling factor should be used, thereby respecting the user's base preference (which may have been selected for that user's particular devices).

BushelCandle (talk) 05:08, 14 January 2016 (UTC)

Despite the one oppose and zero supports, discussion here seems to have stabilized on something like BushelCandel's wording (which I support). But two bold attempts to actually change the MOS have been reverted by Sandstein with an edit summary that we need to wait for consensus first. What is there to wait for? This discussion (and the subproposal within it to make essentially this change) has been going for over six months. Do we need to start a new RfC just so we can record a clean set of opinions, since this wording is different than what we started this section with? —David Eppstein (talk) 07:31, 20 January 2016 (UTC)

Sorry if I've been a bother, I just don't see an obvious consensus at a glance, and no formal closure of the discussion. I don't have an opinion on the issue myself and won't revert again, but perhaps a formal assessment of consensus would be helpful. Sandstein 09:43, 20 January 2016 (UTC)

Comment: I prefer that the explicit statement that we generally should not bypass the 220px default remain in the guideline; this per what is argued at Wikipedia talk:Manual of Style/Images/Archive 5#Setting an image size or using default. So I oppose the change. Flyer22 Reborn (talk) 22:01, 20 January 2016 (UTC)

So, if I've understood you correctly, would you prefer lengthier; something more on the lines of:

As a general rule, images should not be changed from their default size to a fixed size.
If an exception to this general rule is warranted, forcing an image size to be either larger or smaller than the default (currently 220px) is done by placing a parameter in the image coding.
Except with very good reason, do not use px (e.g. thumbɭ300px), which forces a fixed image size. In most cases where a smaller or larger size than the default is justifiably needed, upright=scaling factor should be used, thereby respecting the user's base preference (which may have been selected for that user's particular devices by an adjustment in their preferences).

? BushelCandle (talk) 23:10, 20 January 2016 (UTC)

Not quite; I'm stating that 220px is still the default size, unless I've missed something, and that we should be clear that editors should generally not bypass that size. Why not mention 220px as the default size in the "general rule" sentence? Flyer22 Reborn (talk) 23:48, 20 January 2016 (UTC)

Because it is incorrect for editors to assume that all readers keep their default size set at 220px. That assumption leads to behavior like setting size=300px when "larger than default" is the intended meaning, which is also incorrect, and may in some cases actually result in a smaller-than-default image size. —David Eppstein (talk) 23:51, 20 January 2016 (UTC)

Spot on, David.

It's surprising how many otherwise erudite, sensitive and knowledgeable editors are still unaware of your explanation and the "upright" solution... BushelCandle (talk) 23:55, 20 January 2016 (UTC)

But the section also states the following: "If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding." and "Lead images should usually be no wider than 'upright=1.35' (displays at 300px based on the default thumbnail width of 220px, but may appear larger or smaller based on settings in preferences)." 220px is still listed as/considered the default. Flyer22 Reborn (talk) 23:54, 20 January 2016 (UTC)

For the same reason it would probably be more accurate to change "currently 220px" in your suggestion above to "currently 220px for most users". Another way of saying it is that 220px is not really a global default image size; what it is, is the default value for each user's individual default image size. —David Eppstein (talk) 23:58, 20 January 2016 (UTC)

Perhaps less confusingly, the initial value of the user default size preference. Two definitions of "default" are being used. ―Mandruss ☎ 00:01, 21 January 2016 (UTC)

I would agree to that then. And, BushelCandle, I was already aware of the upright aspect. Flyer22 Reborn (talk) 00:03, 21 January 2016 (UTC)

I'm sure you were aware, Flyer22. Although it's very obvious from your contribution history that you are erudite, sensitive and knowledgeable in your editing, it's equally plain from the edit history of this page that you're the bee's knees when it comes to matters concerning images. BushelCandle (talk) 00:29, 21 January 2016 (UTC)

Amended proposal (1)

At the moment we say: "As a general rule, images should not be set to a larger fixed size than the 220px default (users can adjust this in their preferences). If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding."

I propose changing this to

As a general rule, images should not be changed from their default size to a fixed size.
If an exception to this general rule is warranted, forcing an image size to be either larger or smaller than the initial default (currently 220px for most users) is done by placing a parameter in the image coding.
Except with very good reason, do not use px (e.g. thumbɭ300px), which forces a fixed image size. In most cases where a smaller or larger size than the default is justifiably needed, upright=scaling factor should be used, thereby respecting the user's base preference (which may have been selected for that user's particular devices by an adjustment in their preferences).

Any objections? BushelCandle (talk) 00:29, 21 January 2016 (UTC)

The first sentence could be simplified even more with (I think) the same intent: "As a general rule, images should not be changed from their default size." —David Eppstein (talk) 00:33, 21 January 2016 (UTC)

the initial default (currently 220px for most users) - No, the initial default is 220px for all users, unless I'm missing something. ―Mandruss ☎ 00:55, 21 January 2016 (UTC)

"If an exception to this general rule is warranted, a fixed size may be specified using nnnpx in the image coding." ―Mandruss ☎ 01:01, 21 January 2016 (UTC)

Every user has a default user size, set in that user's preferences. It is a "default" because it can be overridden by the size specified in an individual article. For most users, the default image size is 220px; this is the default default image size, or as you call it the initial default image size. Some users have changed that preference and have a default image size that differs from the default default image size. It is incorrect to write as if there is a single global default image size: the global default is not for the image size in articles, it is for the user's default image size. —David Eppstein (talk) 01:11, 21 January 2016 (UTC)

"In most cases, the default image size should be used. For registered users, this default size is specified in their user preferences, with an initial value of 220px. For unregistered users, the default size is 220px. Where a smaller or larger size than the default is justifiably needed, upright=scaling factor should normally be coded, thereby respecting the user's base preference. For example, upright=1.2 specifies 20% larger than the default size. A scaling factor of 0.75 (75% of the default size) is commonly used for tall images and may be abbreviated by omitting the scaling factor, as upright. Where absolutely necessary, a fixed size may be specified using nnnpx in the image coding, e.g. 300px. A px value should not be used except with very good reason." ―Mandruss ☎ 01:15, 21 January 2016 (UTC)

That looks better to me: same policy, with a more accurate description of what it means. —David Eppstein (talk) 02:00, 21 January 2016 (UTC)

Optional, albeit not strictly related: "If you are a registered editor and work a lot with image layout, consider leaving your default size preference set to 220px, as this is the default size for a majority of readers." ―Mandruss ☎ 02:25, 21 January 2016 (UTC)

This discussion has been helpful. In view of the issues raised, I withdraw my first amended proposal and put forward an alternative below. BushelCandle (talk) 04:32, 24 January 2016 (UTC)

Amended proposal (2)

At the moment we still write: "As a general rule, images should not be set to a larger fixed size than the 220px default (users can adjust this in their preferences). If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding."

I now propose changing this to

In most cases, the default image size should be used.
(For registered users, this default width is specified in their Preferences, with an initial value of 220px. For unregistered users, the default width is 220px. If you are a registered editor and work a lot with image layout, consider leaving your default thumbnail preference set to 220px, as this is the default width for a majority of readers.)
Where a smaller or larger size than the default is justifiably needed, |upright=scaling factor should normally be coded, thereby respecting the user's base preference. For example, |upright=1.3 specifies 30% larger than the default size. A scaling factor of 0.75 (75% of the default size) is commonly used for tall images and may be abbreviated by omitting the scaling factor, as |upright=. Where absolutely necessary, a fixed size may be specified using nnnpx in the image coding, for example 20px.
A px value, which forces a fixed image size, should not be used except with very good reason.

Any objections? BushelCandle (talk) 04:32, 24 January 2016 (UTC)

Looks good to me, although I wonder why you're linking to meta's Help:Preferences instead of Help:Preferences. The latter mentions the preference we're talking about, and it has a hatnote link to the meta page "for full details". ―Mandruss ☎ 19:31, 24 January 2016 (UTC)

Since only yourself and User:EEng have so far commented on this sub-section, I hope you won't find it too great a breach of normal discussion page etiquette that I have now made minor changes to take account of better internal linking and also changed "size" to "width" in some occurrences above.

With regard to User:EEng's magnificently superior proposals (and your equally perceptive comments) I do fear that sometimes the ideal can sometimes (at least temporarily) be the mortal enemy of the merely plausible (lowest denominator proposal). Sometimes it may be that we can make a huge leap forward; alas, sometimes if proposals are too radical and all-encompassing, then discussion grinds to a halt in a welter of fine detail. I'm anxious that, after many months, we do take concrete and immediate steps to improve our current advice. That's why, with no disrespect intended, I'll leave my alternative proposal (2) tabled in the hope it is not opposed. (If alternative proposal (2) does go through to implementation, there is nothing stopping us trying to improve the text on the page even further afterwards if we can subsequently agree a consensual version of alternative proposal (2a)...) BushelCandle (talk) 20:38, 24 January 2016 (UTC)

with no respect intended - None taken. ;) ―Mandruss ☎ 20:56, 24 January 2016 (UTC)

Whoops! BushelCandle (talk) 21:41, 24 January 2016 (UTC)

^[FBDB]Yes, Bushel, a super-double-extra negative would have been clearer e.g. "Without no disrespect not unintended". E Eng 21:46, 24 January 2016 (UTC)

I'm happy to take 2 before 2A, but my concern remains its discouragement of use of upright. I actually think that's the only difference between them -- everything else in 2A is just a reorganization of the material already on MOS (with maybe one or two things imported from WP:Image_use_policy#Displayed_image_size. So no matter what, we have to deal with the "discouragement" issue, so let's do that first. Below I asked you to clarify what you're supporting -- is it about discouragement? E Eng 21:03, 24 January 2016 (UTC)

Very strong objections to this. Hardly anyone uses the "upright" parameter, and it is too late to change that. We should be encouraging people to set their own parameters, which most don't, which interacts bizarrely with the "upright" lot. There aren't enough people left in this discussion to create a convincing consensus either. Johnbod (talk) 08:19, 26 January 2016 (UTC)

A lot of people don't add inline citations supporting the text they add - but that does not stop us trying to ensure that our Manual of Style gives clear advice on both why and how to implement inline citations, does it? If people do use the old-fashioned and tyrannical 'fixed px width' image syntax to (unwittingly?) flout and over-ride logged in user's preferences, that doesn't mean we need to stop urging others to behave in a better and more knowledgeable way, does it? We're an educative project, aren't we? BushelCandle (talk) 03:49, 27 January 2016 (UTC)

Amended proposal (2A)

I think that "In most cases, the default image size should be used... Where a smaller or larger size than the default is justifiably needed..." is too discouraging re use of upright, which really should be used much more often than it is currently -- most editors don't know about it -- to match image size to the situation, taking into account aspect ratio, the image's level of detail, desire to match size of nearby images, etc.

Use cases for a variety of upright values

Therefore, BushelCandle, would you object to substituting the following? Here I've pulled in the entire section for an integrated presentation. (I hope this isn't biting off too much at once.)

Size

See also: Image use policy on displayed image size

Image sizes are manipulated via changes to their widths‍—‌after which software automatically adjusts height to maintain aspect ratio. (In most cases, references to an image's "size" really mean its width.)

Each user has a "base" image width. For unregistered users ("IPs"), this is always 220 pixels. For registered users, the base width is initially 220px (when the user account is created) but this can be changed via user preferences.^[1]

Where a smaller or larger image is appropriate, use |upright=scaling factor, which expands or contracts the image by a factor relative to the user's base width.
For example:
upright=1.3 might be used for an image with fine detail (e.g. a map or diagram) to render it "30% larger than this user generally wants".

upright=0.60 might be used for an image with little detail (e.g. a simple drawing or flag) which can be adequately displayed "40% smaller than this user generally wants".

"Landscape" images (short and wide) often call for upright greater than 1; "portrait" images (tall and narrow) may look best with upright less than 1.

Images should be large enough to reveal important detail without overwhelming surrounding article text.
Images in which a small region is relevant (but cropping to that region would reduce the coherence of the image) may need to be larger than normal, but upright=1.8 should usually be the largest value for images floated beside text.

If a larger value is used (e.g. for panoramas), then use center or none at the same time, so that the image stands alone. Or use {{wide image}} or {{tall image}} to present a large image in a scrollable box.

Lead images should usually use upright=1.35 at most.

Images within an article, especially those vertically proximate to one another, may be more appealing if presented at the same width.

Where absolutely necessary, a fixed width in pixels (e.g. 20px) may be specified. This should be done only with very good reason because it ignores the user's base width preference. The resulting image should usually be no more than 400px wide and 500px tall, for comfortable display on the smallest devices "in common use" (though this may still cause viewing difficulties on some unusual displays); lead images should be no more than 300px wide.

Notes

^ If you work a lot with image layouts, consider leaving your preference at 220px to match the "reader experience" of most readers.

Note I omitted the bit about upright defaulting to 0.75, which I think is an unnecessary and confusing geekish detail. E Eng 18:47, 24 January 2016 (UTC)

I knew I was going to have to say this eventually. Wikipedia articles are not magazine articles, where the image you see is all you can get. We call them "thumbnails", and I consider them exactly that: graphical links to images that happen to be miniature copies of the target images. In many cases, the thumbnail is large enough and there is no need to click-thru, but that should not be a goal in my opinion. The fact that an enormous number of editors fail to get this doesn't weigh a lot with me. Thus, I have zero problem with the gentle discouragement of |upright= as written above. If the reader wants to see the detail (and many do not), they should find their left mouse button and press it. ―Mandruss ☎ 18:59, 24 January 2016 (UTC)

And I knew I'd have to say this eventually. The notion that in-article images should be "thumbnails", to conserve screen real estate, is an anachronism appropriate to the much smaller screens of 20 years ago, on which adequately-size images could easily crowd out too much of the text. (Of course, nowadays we have a new breed of very small mobile screens as well, but on these Wikimedia usually presents the images alone anyway, so the question of "crowding the text" is still irrelevant.)

I agree that in many (even most, as you say) cases the thumbnail is large enough so that there's no need for clickthrough, because the user has presumably set his default width preference to whatever size works for him for typical images (headshots, close/medium views of objects or locales) given his device, eyesight, typical viewing conditions, or whatever. But where we can reasonably predict that a particular image's level of detail needs to be presented at a bigger size than "this user typically wants", why shouldn't no-need-for-clickthrough be our goal? It's this relative sizing that makes upright so much better than fixed px sizing. Why should we set things up so that most readers will have to click back and forth between image and article as they follow the text?

And surely images with the classic "portrait" aspect ratio should use an appropriate upright setting, without which they come out grossly oversized -- somewhat too wide, and way too tall. I actually think this is the most common use case for upright, and since this use reduces image size I'd think you'd be all for it.

Users on slow connections, or with little monitors from 1999, can set their preference as appropriate to factor those considerations in. E Eng 19:45, 24 January 2016 (UTC)

In my view, the anachronism is the magazine mind-set, which fails to exploit the cool new hyperlink feature the Internet gave us, the ability to click on what we want more information about (or, in this case, a better look at). And the freedom of choice not to do so. Why shouldn't no-need-for-clickthrough be our goal? Because that consumes screen real estate whether the reader cares about the detail of that image or not. ―Mandruss ☎ 19:59, 24 January 2016 (UTC)

Like I said, if "Users on slow connections, or with little monitors from 1999, can set their preference as appropriate to factor those considerations in" -- as can users who don't care about details of images, and want to conserve real estate. E Eng 20:05, 24 January 2016 (UTC) [Later P.S.: The way you have it, the reader has to click through whether he cares about real estate or not. I don't see it as obvious that real estate conservation necessarily should have the highest priority. 22:26, 24 January 2016 (UTC)]

I didn't say anything about not caring about the details of images in general. I said, for any given image, many readers don't care about the detail of that image. They should be given the choice per image, not site-wide. And let's not forget that the large majority of readers are not registered and don't have preferences, and that will forever be the case. ―Mandruss ☎ 20:29, 24 January 2016 (UTC)

Well, we can only do what we think will best serve a hypothetical average reader. Can you explain what you're illustrating by including the image above (using upright=0.75)? I've added the same image at upright=1.2, plus the caption that goes with the image in the article. To me, you're making my point -- why even bother having a caption when it refers to features that are completely illegible to the reader (i.e. at upright=0.75)? E Eng 20:55, 24 January 2016 (UTC)

The average reader is the unregistered reader, and that's not hypothetical. I wasn't aware of the original caption for that image (it wasn't in your collapsed content above), and I agree that one should be larger. I also think that's a rare case, and it's reasonably included under the language in Proposal 2, "Where a smaller or larger size than the default is justifiably needed, |upright=scaling factor should normally be coded...". It's justifiably needed. What I'm seeing far more of is thumbnails that are oversized for no other reason than to save the reader a click-thru. And many times it's not even that, the editor just thought it looked better a little larger. Over all I still think Proposal 2 works better than 2A. ―Mandruss ☎ 21:14, 24 January 2016 (UTC)

I just don't get it. I go to a lot of trouble to select appropriate images and put them next to the relevant text, so that the reader can refer to the image while reading. The reader shouldn't have to click through to understand what the image is showing him, then click back and forth, and if real estate is a problem than we should miniaturize headings and get rid of the left-side toolbar that takes up 1/6 of a typical screen but is almost never used by the casual reader. And what's wrong with editors adjusting image size to make the page to look better? E Eng 21:38, 24 January 2016 (UTC)

Keep in mind that it's not just "old" monitors and slow connections. The mobile device screen is not the same resolution as a typical monitor now-days. There's a reason that pixel-perfect resolutions are nearly eliminated from modern web development. The same purpose should be done here. That said, while pixel sizing should be avoided, there are times where percentage-of-page-width can be appropriate for spanning images - ones that are not running in prose. Most of the examples we're talking about aren't being tailored to be running alongside prose, so there's no need to really play with the size. But if we're talking about a section-spanning header, or something similar that is beyond prose, then that might be a reason to use "width=50%" or the like. I would make a distinction between prose and non-prose running images. --MASEM (t) 01:36, 25 January 2016 (UTC)

I don't think our current wiki-markup allows percentage of page width as one of its image sizing options. —David Eppstein (talk) 05:14, 25 January 2016 (UTC)

Hi, Masem! I'm afraid I have no idea what you're saying here, because I don't know what you mean by "pixel-perfect resolutions" and "prose and non-prose running images", "tailored to be running alongside prose", "section-spanning header", "beyond prose"... what do those things mean? E Eng 04:17, 25 January 2016 (UTC)

"Pixel-perfect" are layouts that are designed to fit into a specifically sized browser window or the like, heavily relying on "px" specifications in the CSS or equivalent markup, instead of using relative widths. Prose-running are those that are go along standard paragraphs of text, while non-prose-running are those going against other types of content, such as a table, list, or similar organization. --MASEM (t) 04:22, 25 January 2016 (UTC)

OK, so when you say, "Most of the examples we're talking about aren't being tailored to be running alongside prose, so there's no need to really play with the size", you're saying that images that are floated next to prose usually shouldn't have their sizes adjusted? If that's what you're saying, I don't see why.

At right I've shown two images at upright=1. Wouldn't you agree that one should be much smaller, and the other at least somewhat larger? E Eng 06:00, 25 January 2016 (UTC)

There are reasons to play with prose-running image sizes, I agree there. The Phrenology is a good case because the text on the image is specifically the subject of discussion so it does need to be legible, so adjustment via relative widths and/or upright is fine (ideally a method respecting the user's thumbnail size selection). I'm not sure on shrinking the image too small, however, as then you could be pressing even a short phrase caption into a tight vertical configuration. Upright=0.4 is rather small already and I'm using the default thumb size.

What we should be careful about doing is trying to play with image sizes to make the page "look good". Images have to be legible, yes, and images that are more portrait than landscape do not need to be presented at the same width as regular landscape images. But I would argue that unless you have a good reason to change the display size, it should be left alone, letting the software manage them in a smart way. While we should aim to make the layout visually interesting for articles, and making sure the images presented are useful, we should not be trying to make a visually impressive layout as there are far too many device combinations to try to work towards. Various browsers, and the Mediawiki software is smart enough to make appropriate decisions on how to scale images, so we shouldn't try to second guess that unless we have a good reason to (like legibility). --MASEM (t) 16:32, 25 January 2016 (UTC)

Sorry, but I'm still puzzled by what you're saying. "unless you have a good reason to change the display size, it should be left alone, letting the software manage them in a smart way... Various browsers, and the Mediawiki software is smart enough to make appropriate decisions on how to scale images" -- huh? In what way does "software manage" the images or their size? How do browsers and Mediawiki "make appropriate decisions on how to scale images"? What are you talking about? Images are displayed at the user-selected width, possibly modified by upright; if there's no upright then they're all the same, all the one user-selected width, perdiod. What's all this "software management" you're talking about??? E Eng 16:46, 25 January 2016 (UTC)

From what I thought I have read on the MediaWiki software and just spot-checked, that it does alter image sizes when it knows it is browser on a mobile device or using the mobile web page version so that images will fit more comfortably into the smaller screen, potentially overriding any user preference that may have been set. If anything, this is more a reason to stay to upright and relative width sizes, which stay respected by these adjustments, and those I'm not arguing against. I am arguing that we should be excessively playing with image sizes for simple look/aesthetics reasons as that is something out of our control. --MASEM (t) 17:01, 25 January 2016 (UTC)

As someone who is very prone to whoopsies herself, I assume you meant to write "we should not be excessively playing with image sizes for simple look/aesthetics reasons as that is something out of our control", yes? BushelCandle (talk) 21:37, 25 January 2016 (UTC)

My apologies -- it never occurred to me you were talking about mobile. And I agree we shouldn't be excessively playing with image sizes, but what constitutes "excess" may be a tricky question. As the ancient Greeks proverb goes, "Practice moderation, but not to excess!"

Very strong objections to this (again). Hardly anyone uses the "upright" parameter, and it is too late to change that. We should be encouraging people to set their own parameters, which most don't, which interacts bizarrely with the "upright" lot. There aren't enough people left in this discussion to create a convincing consensus either. Johnbod (talk) 08:20, 26 January 2016 (UTC)

!voting on 2A/2B

Support in broad principle. BushelCandle (talk) 20:46, 24 January 2016 (UTC)

Wait... what is it you're supporting in broad principle? E Eng 21:03, 24 January 2016 (UTC)

From this edit [1] I gather you're supporting 2A. E Eng 21:38, 24 January 2016 (UTC)

Re the editsum in that edit, WP:BOLD doesn't mean implement content that is currently under discussion, clearly contested, and lacking consensus. I call foul, and I object to it as written because it so clearly demonstrates the magazine mind-set. It doesn't even consider the possibility of clicking thru. But I'll leave it with you guys, good luck. ―Mandruss ☎ 21:45, 24 January 2016 (UTC)

I think you're right to call foul, and I expected to be instantly reverted again. However, I genuinely think that the version is 7 steps forward (and, perhaps, 2 steps backwards). Surely you can build on that version though, and tweak it to add the whole reason they're called 'thumbnails' and also tweak the wording to provide powerful ammunition against those edit warriors who might otherwise regard it as a licence to have images sized extraordinarily? BushelCandle (talk) 02:49, 26 January 2016 (UTC)

While I decided to !vote Yes in the RfC (hey it's only one !vote among many), I've experienced a minor crisis of confidence here, and I'm no longer feeling confident enough to go any deeper into this. First, it occurs to me that the "thumbnail" term and concept could be holdovers, historical artifacts, from 14 years ago and before. This could go to the word "anachronism" used in recent discussion. Further, I lack any experience in important areas such as mobile. I'm not jumping the fence, but I'm far closer to it and I would prefer to abstain from this point. I'm good at writing, but it looks like there's enough talent in that area already present. ―Mandruss ☎ 04:19, 26 January 2016 (UTC)

Support in that I think this is an improvement. It's less ambiguous and addresses the most common misinterpretations of the size guidelines. --Dennis Bratland (talk) 21:17, 24 January 2016 (UTC)
Support the recent bold changes, which I think are a significant improvement. —David Eppstein (talk) 23:24, 24 January 2016 (UTC)
Support (obviously). E Eng 01:46, 27 January 2016 (UTC)
Attention, esteemed fellow editors! I've made some changes here [2] -- mostly slight, but some to emphasize the dangers of too-large images. I guess we could call this 2B (or not). E Eng 05:43, 25 January 2016 (UTC)

Still doesn't alleviate my concern. Flyer22 Reborn (talk) 06:24, 25 January 2016 (UTC)

Oppose, per my comment in the #Discussion of "sizing discouragement" section below. That is where my "oppose" vote is. Look there for other votes or almost-votes. Someone (I'm guessing it was EEng before I look to see who) unnecessarily split material. Flyer22 Reborn (talk) 20:00, 25 January 2016 (UTC)
Oppose Hardly anyone uses the "upright" parameter, and it is too late to change that. We should be encouraging people to set their own parameters, which most don't, which interacts bizarrely with the "upright" lot. There aren't enough people left in this discussion to create a convincing consensus either. Johnbod (talk) 08:21, 26 January 2016 (UTC)
Oppose whatever this is about, as it's no longer clear. Not sure what Johnbod means about no one using the upright parameter, because it's used all the time. Please stop making bold changes to the guideline. SarahSV ^(talk) 23:08, 26 January 2016 (UTC)
Oppose Isn't the upright= thing kind of a hack? I mean, it's a parameter that defaults to shrinking the image down to, what is it, 70% of the default? It's a bit odd to advocate for what's basically hacking the code. Adam Cuerden ^(talk) 02:12, 27 January 2016 (UTC)

Adam Cuerden, If you code |upright alone, it's the same as |upright0.75, which is a stupid, confusing "feature" having to do with its original use with portait-aspect (i.e. "upright") images. But no one does that in real life, and it has nothing to do with its usefulness for resizing images in general.

Upright's superiority over fixed-width sizing e.g. 275px is that upright enlarges or shrinks relative to the user's preference-set "base" width. As someone pointed out, 275px is presumably intended to enlarge the image, but if the user has set his base width to (say) 300px because of bad eyesight, then 275px will actually make it smaller for that user. If you code, instead, upright=1.25, then every user gets this image 25% than his "regular" images. E Eng 02:58, 27 January 2016 (UTC)

That may be, but it's still a hack. The solution is probably a MediaWiki code issue: Get a property similar to upright added without the bizarre default, and it'd be far more supportable, because while you're using something otherwise than it was intended, there's always a chance of "improvements" breaking your usage completely. Adam Cuerden ^(talk) 06:57, 27 January 2016 (UTC)

You don't seem to be clear on what hack really means in this context. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:21, 27 January 2016 (UTC)

Support in broad principle. If wording needs to be tweaked "just so" later, it can be, but continuing to squabble over minor details is dragging this out. The fact that upright isn't used much is because we're not advising that it be used and telling people how to do it. The cause–effect argument on that point above is backwards. The "it's a hack" argument is also invalid, for reasons others have already explained. Even if it were true, the fact that a problem might happen some day is insufficient to derail dealing with a real one now. The MW develoepers are actually pretty careful about not breaking things, so the concern is overblown. And again, it's not a hack. A parameter that takes a whole or fractional integer value (regardless what its default is) isn't in "hack mode" when you use it one way and "normal" mode in another. Software doesn't work that way; it operates on whatever values it was engineered to support. And we have a policy to comply with here. Something has to be done; this is the best proposal so far; if it's not perfect, it will be fixed later. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:19, 27 January 2016 (UTC)

Discussion of "sizing discouragement"

Comment: How does this or this current wording prevent the type of image disaster I mentioned before? I don't see that this new wording will help in that regard. What I see is that when an editor blows an image up to an unreasonable size, I and/or others will no longer be able to point to this image guideline and state that such blowing up shouldn't be done. The "As a general rule" and "In most cases, the default image size should be used" type of wordings helped for quite sometime in keeping unreasonable image size under control. So I still support generally advising against making an image bigger than Wikipedia's default image size, and oppose the removal of that aspect. And since, in that discussion, Masem agreed with me reverting back to the longstanding wording, I have to ask his opinion on this. Flyer22 Reborn (talk) 00:54, 25 January 2016 (UTC)
- The image disaster you list is sized absolutely rather than relatively, above the recommended 400px maximum, and interacts badly with two-column mode; it would probably not be characterizable as a disaster when set alongside normally flowed text (especially in the default right-side position). And it's a good example of an image for which larger-than-default sizing is helpful, in that the people in the image are so small as to be unrecognizable at the default size. In short, if you are trying to set a precedent of "no big images, ever", you picked a poor hill to stand on. —David Eppstein (talk) 05:14, 25 January 2016 (UTC)

I don't agree with having images that size to view the actors, especially when the actors are identifiable by the wikilinks in the caption and/or by a person clicking on the image. There are very few cases where I would agree that a Wikipedia image should be that size. And we don't use that size in the cast sections of our film articles; anyone is free to ask at WP:Film if they have doubts about that. I'm with Mandruss that "Wikipedia articles are not magazine articles, where the image you see is all you can get. We call them 'thumbnails', and I consider them exactly that: graphical links to images that happen to be miniature copies of the target images. In many cases, the thumbnail is large enough and there is no need to click-thru, but that should not be a goal in my opinion. [...]. If the reader wants to see the detail (and many do not), they should find their left mouse button and press it." Flyer22 Reborn (talk) 05:28, 25 January 2016 (UTC)

And, Masem, thanks for weighing in. Flyer22 Reborn (talk) 05:34, 25 January 2016 (UTC)

You and Mandruss have a very parochial view of how to read Wikipedia. Left mouse button? What's that? The computer I'm using this on has no mouse (one clicks on the trackpad), and has no concept of left and right for its clicks. And I'm sure there are still people reading articles in hardcopy, for which finding some way to convince the viewer to show a larger image isn't even possible. An image should be sized to be informative, not to get out of the way. If you want tiny tiny thumbnails, set a smaller default, don't force your preferences on all readers. —David Eppstein (talk) 05:48, 25 January 2016 (UTC)

The problem is that we're trying to balance 100s of possible computer/monitor/aspect ratio/layout preferences in addition to the issues with non-free if the images all fall into that. There is no "one size fits all" solution, particularly when we know most visitors to wikipedia are not registered users and thus using our selected default. For that reason, anything that sets a fixed size can be potentially harmful to these unknown configurations, while non-sized, percent-width, or upright= set images work across all platforms even if this means the image might be smaller for a specific configuration. While we provide WP for offline reading, it is by design an online encyclopedia so features that offline readers can't use, we're not to ignore the usefulness of those features (such as links that can be followed to larger images). We're not going to be able to readily satisfy every possible situation, and there's always IAR for unique cases, but we are looking to best serve the greatest common denominator here. --MASEM (t) 06:01, 25 January 2016 (UTC)

Oh, I completely agree with all that. What I'm complaining about is the Procrustian attitude (not from you) that we cannot allow any positively-worded description of ways to resize images because all images must be exactly the same size, and that the only way to see an image at an informative size is to go view it on a separate page, separated from its context. —David Eppstein (talk) 06:26, 25 January 2016 (UTC)

I'm sorry, but I find your reasoning impossible to follow. The only thing more one-size-fits-all than 220px (sometimes modified by upright) is 220px (period, never modified). I think we're all agreed that absolute px sizing is almost always a bad idea, and the text says so. Can you take a look at the examples at right and give your thoughts to my question about them (above [3])? E Eng 06:24, 25 January 2016 (UTC)

No, not a very parochial view of how to read Wikipedia; just a more practical view when it comes to unnecessarily increasing image size or adding huge images in ways that are detrimental to an article. The new wording makes those of us who have to deal with such bad image formatting unable to sufficiently combat such bad image formatting. Like I stated above, "The 'As a general rule' and 'In most cases, the default image size should be used' type of wordings helped for quite sometime in keeping unreasonable image size under control." I can only see this new wording undermining that. So as you probably guessed, I feel that this needs a WP:RfC, given that the previous wording has been standard for so long and that I know many editors who still cite it. For example, there are surely some editors at the WP:GA or WP:FA pages who would be interested in weighing in on this matter. As for the mouse aspect Mandruss mentioned, it clearly should not be taken as literally as you took it. Yes, I know, I know, you were making a point about the existence of different ways to view Wikipedia. But I don't have a mouse either (I have a touchpad), and that doesn't stop me from clicking on the image if I want a better view of it. It seems that you and others are trying to appeal to all readers; that's not always possible, and Wikipedia commonly gives priority to the majority rather than the minority. For the minority, it commonly has alternative options. You argue, "If you want tiny tiny thumbnails, set a smaller default, don't force your preferences on all readers.", but similar has been stated about our editors who do not want to view offensive images; we have them view them anyway, and only let them know after the fact that they can change their image settings so that they don't see the offensive images. Those editors feel that the offensive images are forced on them. I'm not stating that I prefer tiny images; like Mandruss noted, "In many cases, the thumbnail is large enough and there is no need to click-thru." I'm stating that there usually is not a good reason to bypass that default size or to have a huge image in the article. Flyer22 Reborn (talk) 06:24, 25 January 2016 (UTC)

I'd like to discuss your reference to "those of us who have to deal with such bad image formatting". You don't have to deal with the image formatting of images project-wide, nor it is clear that this actually is "bad image formatting". The normal Wikipedia approach would be to leave these questions to the editors working on each article. When do we diverge from that approach and make a rule in MOS?

Well, it's long been an axiom of mine that something should be added to MOS when editor time has, and continues to be, spent litigating the same issue over and over on numerous articles, either

(a) with generally the same result (so we might as well just memorialize that result, and save all the future arguing), or
(b) with different results in different cases, but with reason to believe the differences are arbitrary, and not worth all the arguing -- a final decision on one arbitrary choice, though an intrusion on the general principle that decisions on each article should be made on the Talk page of that article, is worth making in light of the large amount of editor time saved.

Please supply some evidence that either or both of those conditions applies to image sizing. Otherwise, your talk of being "unable to sufficiently combat such bad image formatting" sounds more like you're "unable to convince editors working on various articles that my opinions about image sizing are the right ones", and you want something in MOS that favors your opinion. E Eng 08:01, 25 January 2016 (UTC)

EEng, could you not cut in between discussion like this? Doing so makes for confused and disorganized reading. I disagree with your entire "08:01, 25 January 2016 (UTC)" post, and I've been clear about why. The "As a general rule" wording worked fine for this guideline, just like it works fine for the WP:Lead guideline despite editors who continue to try to get that guideline changed in the same disorganized fashion that you have changed this one. I'm not going to point to more examples like the aforementioned one since you apparently don't see that image size as a problem for a cast section. Unnecessary, bloated images are problems, including when it comes to WP:SANDWICHING matters. I'm not stating any of this out of personal preference; I'm stating it because I have seen it be an issue for years (keep in mind that I have been with this site since 2007), with many editors fighting over image size. Once we point editors to the "As a general rule" wording, the dispute usually settles down. Well, no more, since you and BushelCandle took it upon yourselves to change a longstanding guideline that worked well the way it was. Certain editors here simply don't like rules and don't know how to adhere to them. They have a "rules are meant to be broken" attitude, or they evoke WP:Ignore all rules for everything. They want our guidelines and even our policies to be loose with everything so that they can do what they want; I'm the exact opposite of that. Flyer22 Reborn (talk) 20:29, 25 January 2016 (UTC)

I'm specifically addressing this particular one of your posts, so this is the right place, and the indenting makes it clear there's a branch in the thread. Other than that, I'll just note that you've done nothing that claim there's a "longstanding problem", without giving any evidence (I too have need here since 2007, BTW.) What you call editors fighting over image size (in bold, for some reason) may very well just be editors discussing image size and (I'm guessing) not always coming to the conclusion you prefer. Thus your desire for a rule that supports your preference.

As for "Certain editors here simply don't like rules and don't know how to adhere to them", here are two of my favorite wikiquotes:

The flip side of "ownership" is the problem of editors who come to an article with a particular agenda, make the changes they want to the page according to their preconceived notions of what should be, and then flit off to their next victim, without ever considering whether the page really needed the change they made, or whether the change improved the article at all ... Their editing is an off-the-rack, one-size-fits-all proposition, premised on the idea that what improves one article, or one type of article, will automatically improve every other article or type of article ... Wikipedians should worry more about those who hit-and-run, and less about those who feel stewardship towards the articles they work so hard on. -- Beyond My Ken

One area the hit and run editor gets involved in is the formatting ... The quality of work has increased in some areas, which makes it harder to contribute without good knowledge in the subject matter and sources. Fiddling with the formatting seems to be a suitable alternative passtime. -- Ritchie333

E Eng 05:12, 26 January 2016 (UTC)

You didn't have to cut ahead of David Eppstein's post to reply to me. And the indenting aspect does not help much, especially when one knows that Wikipedia editors have different ideas about indenting and commonly do not pay attention to the time stamps unless it's to see whose name is beside the post. As for your assumption that "What [I] call editors fighting over image size (in bold, for some reason) may very well just be editors discussing image size and ([you're] guessing) not always coming to the conclusion [I] prefer. Thus [my] desire for a rule that supports [my] preference.", you are wrong. It was fighting. And, yes, I've seen Beyond My Ken fighting over image size as well. I haven't been involved in many image size disputes. I have occasionally reverted unreasonable or unneeded image sizes (always the ones that increase image size from the 220px default since decreasing image size away from that default is usually not what editors argue over), and I have pointed them to the "As a general rule" aspect of the guideline that is currently not there. I meant exactly what I relayed above: "I'm not stating any of this out of personal preference; I'm stating it because I have seen it be an issue for years (keep in mind that I have been with this site since 2007), with many editors fighting over image size. Once we point editors to the 'As a general rule' wording, the dispute usually settles down." You are obviously free to doubt that, but the doubt is misplaced. Flyer22 Reborn (talk) 06:37, 26 January 2016 (UTC)

Third request for you to provide even a few diffs, without which doubt trumps unsupported assertion. E Eng 07:09, 26 January 2016 (UTC)

What I've stated is common knowledge, and that includes Beyond My Ken's disputes over image sizes. Either way, refer to where I relayed above, "I'm not going to point to more examples like the aforementioned one since you apparently don't see that image size as a problem for a cast section. Unnecessary, bloated images are problems, including when it comes to WP:SANDWICHING matters." It is clear to me that nothing I state on this matter, with or without diffs, is going to change your mind or contribute to you truly understanding my viewpoint; so I will not be digging through edit histories to provide any such diffs of image disputes, especially since such image disputes are common knowledge. Flyer22 Reborn (talk) 07:25, 26 January 2016 (UTC)

<rolls eyes>No one disputes that "unnecessary, bloated images are problems" -- the dispute is whether a rule is needed to address that problem, versus just letting editors work it out like any other content issue.

Anyway, it's not me you need make understand, but everyone else, and the diffs I request would serve that goal well. If such disputes are really so common, and their outcome so universally in your favor, it would be easy to supply two or three examples. From your lame excuses I conclude you just make shit up.

Worth noting, too, are your repeated statements to the effect that you are frequently unable to prevail on these questions until you point to this MOS provision you so mourn. What that means is that your arguments are unconvincing, not just to me but to many others as well. E Eng 08:01, 26 January 2016 (UTC)

We clearly see things differently. And I couldn't care less that you roll your eyes; it speaks volumes about your maturity level, your inability to discuss matters without resorting to snide remarks or gestures and somehow expecting others not to do the same. Your changes to our guidelines and policies are often disputed for valid reasons, but you always think you are right and barely ever listen to others. You make changes to our guidelines and policies without consensus, as you did in this other case to this very guideline, when the statements at the very top of these pages are clear that significant changes to them should have consensus. And you think I am supposed to indulge you further? Not a chance. You stating that it's "[w]orth noting, too, are your repeated statements to the effect that you are frequently unable to prevail on these questions until you point to this MOS provision you so mourn. What that means is that your arguments are unconvincing, not just to me but to many others as well." proves that you don't listen and that you are beyond presumptuous. Sorry, but you can't bait me as easily as you bait others. Flyer22 Reborn (talk) 20:52, 26 January 2016 (UTC)

My experience is the opposite: very very often, article layouts look bad when all images are forced to be the same size as each other. It is more natural, gives a less mechanical appearance, and is just plain more readable and informative to size images so that, for instance, text (in scientific diagrams) is readable, so that the image is wide enough to allow its caption to be fewer than 10 lines long, so that tall images are thinner than the default, etc. I do not think the MOS should dictate that all images be the same size and I think your insistance that it should is a violation of WP:CREEP. —David Eppstein (talk) 06:30, 25 January 2016 (UTC)

Amen, and might I humbly suggest that the images I've added at right illustrate this very well. E Eng 06:35, 25 January 2016 (UTC)

Yes. Another example that I recently had promoted to Good Article: binary logarithm. Two images are smaller than default (and would overwhelm the article if forced to become larger), three are larger (and their text would become illegible if forced to be smaller), and one is the default size. I think that this sort of thing is much more common, at least in the articles I edit, than articles where the default size is a good fit for all images. The GA reviewer didn't catch the absolute rather than relative image sizing but I have since fixed that. —David Eppstein (talk) 06:44, 25 January 2016 (UTC)

There was no WP:CREEP aspect in my comment by arguing for the longstanding wording. And even if there had been, there would be no violation since WP:CREEP is an essay, despite the efforts of some editors to elevate it to a guideline. I will now alert the WP:GA and WP:FA pages, and some other pages, to this discussion. And I might throw a WP:RfC tag on this discussion. Flyer22 Reborn (talk) 06:39, 25 January 2016 (UTC)

And, for the record, the "As a general rule" wording gave editors enough leeway to change the image size if needed, just like the "As a general rule" wording at WP:Lead gives editors enough leeway to have the lead exceed four paragraphs if needed. Flyer22 Reborn (talk) 06:46, 25 January 2016 (UTC)

Can I make a suggestion, Flyer22? Since, as someone said, the new text is magnificently superior to the old, with the possible exception of how much discouragement there should be on size adjustments, can you propose what text you'd like to see changed or inserted? Perhaps we can arrive at something we can all agree on, and even if not, a useful RfC outcome is way more likely if both "sides" have worked together to frame the question(s) the RfC presents to the community. E Eng 07:12, 25 January 2016 (UTC)

Your dogmatism is showing again. WP:LEADLENGTH does not say leads should be four paragraphs, even as a general rule; rather, it suggests reasonable guidelines for matching numbers of paragraphs to article lengths. We should do the same in matching image sizes to their contexts. —David Eppstein (talk) 06:50, 25 January 2016 (UTC)

David Eppstein, perhaps you missed where WP:Lead states right in the introduction, "As a general rule of thumb, a lead section should contain no more than four well-composed paragraphs and be carefully sourced as appropriate." And perhaps you missed where WP:LEADLENGTH states, "As a general guideline—but not absolute rule—the lead should usually be no longer than four paragraphs." Both of those are indeed "as a general rule" wordings, and are not at odds with me stating, "just like the 'As a general rule' wording at WP:Lead gives editors enough leeway to have the lead exceed four paragraphs if needed." Nothing to do with any dogmatism you perceive on my part.

For the record here on this talk page, this, this, this, this, this, this, this, this, this, this, this and this are the pages I alerted to this discussion. That should be enough for outside input. If it's not, a WP:RfC tag is next. Flyer22 Reborn (talk) 07:29, 25 January 2016 (UTC)

Flyer22, I really wish you'd taken to heart my suggestion that we first define the issue among ourselves before calling in more editors. What you've now done is post to several project-space talk pages (e.g. [4]) a notice which reads, in part:

The discussion concerns whether or not we should keep the following wording: "As a general rule, images should not be set to a larger fixed size than the 220px default (users can adjust this in their preferences). If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding."

This makes no sense, because it talks about "fixed" sizes, and there's no issue there -- the text already strongly discourages all fixed sizes. What you've done is guaranteed to cause confusion now. I'm asking you -- again -- to propose text you'd like to see added or changed in the text as it stands, so we can discuss it first and perhaps come to agreement. And if not, then at least we'll have a clear question to pose to others, not a fractured one like you have now. The text you've posted all over the place wouldn't even make sense added to the current text -- there's no sensible place to add it. E Eng 07:44, 25 January 2016 (UTC)

I've been clear that I support the "As a general rule" wording that you helped change. There is no need for me to propose wording when that is the wording I support. That wording is the wording that is in dispute, since the beginning of this discussion. It is the wording that was replaced. So I fail to see how the note I left about it "guarantee[s] to cause confusion now." The way this discussion is set up is what is apparently confusing editors (per below). The current text in the guideline should be reverted to the WP:STATUSQUO. It is obviously disputed.

On a side note: Pinging my former username does not work; I do not need to be pinged to this discussion anyway. Flyer22 Reborn (talk) 20:29, 25 January 2016 (UTC)

Oppose all attempts to enforce image size parameters. This RfC has gotten so long and unwieldy I have no idea where to post this. I do not accept a "one-size-fits-all" set image size for Wikipedia images. To me that is irrational. Appropriate image size can and should vary based on the image itself, the caption (and its length, and whether it fits felicitously or has unsightly widows), the size of the images or other boxes/structures (like infoboxes) above or below the image, the size and amount of text adjacent to the image, the relative importance of the image, the number of other images in the article/section, and so forth. Softlavender (talk) 11:39, 25 January 2016 (UTC)

Oppose, per Softlavender. I oppose a central one-size-fits-all policy. Leave it up to editors on the page. SarahSV ^(talk) 23:02, 26 January 2016 (UTC)

We should probably take that up at the actual policy then. This is a guideline trying to help the editorship comply practically with the policy. It may well be that what emerges works out fine in practice, but there seem to be concerns here that the policy wording is outdated. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:28, 27 January 2016 (UTC)

RfC: Should the guideline maintain the "As a general rule" wording or something similar?

The following wording used to be in the guideline: "As a general rule, images should not be set to a larger fixed size than the 220px default (users can adjust this in their preferences). If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding." The guideline currently looks like this. Above on the guideline talk page, there is concern that the "As a general rule" wording is limited, and that we shouldn't assume that all readers keep their default size set at 220px; assuming such can lead people to use improper image settings. There is also concern that there are few cases where an image needs to be above the 220px setting, and that the 220px rule has kept unreasonable image sizes at bay and settled disputes over image size for years. Flyer22 Reborn (talk) 21:33, 25 January 2016 (UTC)

Yes, or something similar. Like I argued above, I don't agree that we commonly need bigger images, and unreasonable bloated image size can be detrimental to articles, including with regard to WP:SANDWICHING issues. The 220px default usually suffices. This rule has also helped settle fights over image size. Mandruss stated, "Wikipedia articles are not magazine articles, where the image you see is all you can get. We call them 'thumbnails', and I consider them exactly that: graphical links to images that happen to be miniature copies of the target images. In many cases, the thumbnail is large enough and there is no need to click-thru, but that should not be a goal in my opinion. [...]. If the reader wants to see the detail (and many do not), they should find their left mouse button and press it." I agree with that. Flyer22 Reborn (talk) 21:36, 25 January 2016 (UTC) To me, this rule is similar to the WP:Lead "As a general rule" guideline about generally not exceeding four paragraphs in the lead unless needed, which has worked fine for years. Flyer22 Reborn (talk) 21:00, 26 January 2016 (UTC)
Yes, but maybe not as strongly worded. I think it's important that we discourage changing the image size from the default, but also make an allowance for the many situations where it is actually warranted. Kaldari (talk) 22:22, 25 January 2016 (UTC)
No. The wording that disallows image sizing over 1.8 times the default is sufficient; it is false in practice and also a bad idea to force most images to be exactly the default size. The discussion above provides many good examples of images that should not be the default size, and I don't want guideline wording that encourages wikignomes to go around "fixing" non-default image sizes or imposing strict size requirements as a condition for passing GA or DYK. I would also note that this whole RfC completely misses one of the main points of the recent discussion and bold changes to this part of the MOS, which was primarily about changing from wording that was neutral about using absolute (pixel-based) vs relative (upright parameter) image sizing to wording that instead strongly discouraged absolute sizing. I am very much in favor of that change and would not want to see it lost in wankery over how strictly we should adhere to one-size-fits-all image sizing. —David Eppstein (talk) 23:18, 25 January 2016 (UTC)
Yes - The issue arises largely from the different ways our minds are wired. Some of us are engineers, others artists. The same differences exist for readers, too, by the way. I'm the engineer type, but I believe this !vote gives the best balance. Agree with Eppstein as to fixed sizing, disagree as to wankery. User Eeng is on the other side of the issue. If they are an Electrical engineer, as I've always assumed, they are an unusual one in my opinion. ―Mandruss ☎ 00:57, 26 January 2016 (UTC)

^[FBDB]Since you seem to think engineers are mindless robots blindly applying rigid rules, I'll take what you say as a compliment. (I don't think most engineers are like that, BTW – at least not good ones. And David Eppstein's a computer scientist himself, so maybe you've drawn the technical-nontechnical battles lines incorrectly.) E Eng 04:45, 26 January 2016 (UTC)

No per David Eppstein gives, plus it's redundant to the text already in place, which reads:

Where absolutely necessary, a fixed width in pixels may be specified. This should be done only where absolutely necessary because it ignores the user's base width preference. The resulting image should usually be no more than 400px wide...

Give the "only where absolutely necessary" injunction, there should be very few instances of fixed sizing anyway. And in those cases, I trust my esteemed fellow editors to choose that size with wisdom and discretion, taking into account whatever unusual needs led to fixed sizing being "absolutely necessary" in the first place. Extra verbiage just to further discourage the 220-to-400–pixel case seems overanxious. E Eng 04:45, 26 January 2016 (UTC)

Yes, or something similar, but with weaker wording dropping "absolutely necessary", and no pushing the "upright" parameters. Lead images should be exempted - imo 300px should be normal for these in most articles. I still think images fixed too small are a more common problem than images fixed too large, but few seem to share that view. Johnbod (talk) 08:25, 26 January 2016 (UTC)
Yes – Having read the above discussion, there are good points made from both sides. It is clear that some revamp of this section's wording is needed. However, I do not agree with the updated version, mostly because it lacks conciseness by being overly complex and long-winded. The purpose of this section should be to inform editors of the default 220px user preference, the parameters available for making manual adjustments, and advice that such parameters are not typically needed except in special circumstances (listing a few examples to illustrate). The longstanding wording seemed to arrive at the point in clearer fashion. I think more discussion is needed on the proposed changes. --GoneIn60 (talk) 21:53, 26 January 2016 (UTC)
Oppose. Image sizes are often the subject of dispute because certain editors want to impose very small images on articles they otherwise have no involvement in. For that reason, I think we should not make changes to this section unless there is clear consensus, and I hope we don't add anything that will make life difficult for editors who like to use larger image sizes, particularly in articles about art. SarahSV ^(talk) 23:00, 26 January 2016 (UTC)

Well, one could argue that the section was already changed without clear consensus (diff). Nothing wrong with being bold, until it becomes obvious that consensus is in doubt. I don't suppose that changes your stance on the matter? --GoneIn60 (talk) 03:55, 27 January 2016 (UTC)

GoneIn60, it's hard to see what the consensus version was. I reverted to the version before the diff you cited, but was reverted. Changes pushed through without consensus are likely to be ignored or constantly disputed, so there's actually no point in doing this. SarahSV ^(talk) 04:51, 27 January 2016 (UTC)

Probably not It kind of steamrollers over all the obvious exceptions. To name one that hasn't been mentioned: Infoboxes can sometimes, due to text or formatting, default to fairly wide boxes. A default-sized image can look terrible in those as it's far narrower than the space provided. I could support a statement that the default shouldn't be changed without reason to do so. Adam Cuerden ^(talk) 02:18, 27 January 2016 (UTC)
- Actually, definitely not. If we're disallowing larger than, but the wording does not disallow smaller than, then we're setting a new, smaller image size. Adam Cuerden ^(talk) 16:34, 29 January 2016 (UTC)
Oppose; as noted above, it's redundant with the extant text. One size does not fit all, and "where absolutely necessary" his hyperbolic. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:32, 27 January 2016 (UTC)
Oppose, per SarahSV; and I agree with this comment by Softlavender (see above) re desirable parameters for sizing images rather than 'one-size-is-good-for-you': "Appropriate image size can and should vary based on the image itself, the caption (and its length, and whether it fits felicitously or has [creates] unsightly widows), the size of the images or other boxes/structures (like infoboxes) above or below the image, the size and amount of text adjacent to the image, the relative importance of the image, the number of other images in the article/section, and so forth". //Jbeans (talk) 14:20, 3 February 2016 (UTC)
Yes. Ⓩⓟⓟⓘⓧ (talk) 19:43, 23 February 2016‎ (UTC)
Yes, but .... I'm just going to quote Kaldari, who put it very succinctly: "Yes, but maybe not as strongly worded. I think it's important that we discourage changing the image size from the default, but also make an allowance for the many situations where it is actually warranted." — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:33, 2 March 2016 (UTC)

Discussion section

Flyer22 Reborn, let me ask you... Based on #RfC: Should the guideline maintain the "As a general rule" wording or something similar?, it seems like your concern about the current wording [5] is the loss of this text:

As a general rule, images should not be set to a larger fixed size than the 220px default (users can adjust this in their preferences). If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding.

How would you feel about incorporating it this way [6]? E Eng 04:00, 27 January 2016 (UTC)

I'd be fine with that. Keeping this bit (the "In most cases" sentence) is also my concern. Flyer22 Reborn (talk) 10:39, 27 January 2016 (UTC)

Re the "images should not be set to a size larger" (above), I'm glad we were able to resolve your concern. You could have saved all the reverting and yelling and ANIing and RFPPing and RfCing if you'd just edited that little piece back in yourself, as I did just now, instead of reverting 200 lines of change because you don't like one line.
Your second point is re the change (see your link above) from

In most cases, images should be right justified on pages, which is the default placement. If an exception to the general rule is warranted [etc etc] [Note: bolding added for ease of locating the two options]

to

By default, images appear against the right margin. If an exception is warranted, [etc etc]

Since this is the only concern you've expressed on that diff, I've reinstalled its other changes [7]. (And if there's something else you decide you don't like, please just edit it in place, or raise a concern here if you prefer, but don't don't mass-revert everything unless the whole edit is hopeless.)

However, I would propose that the new text above is more appropriate. Why should it be the "general rule" that images "should" be on the right "in most cases"? In practice almost all articles have all images on the right anyway, because of the default, but if editors of a given article want some, most, or all images on the left, for whatever reason, why should that be an "exception" which must be "warranted"? What's the big deal? Why does MOS care? Is, or was, there some plague of left-justified images that must be stopped before it leads to immorality, social collapse and worldwide famine?

The "should be right justified" language was inserted here [8], after the following not-very-exciting talkpage disucssion [9]

On the project page it is stated "As an example in its simplest form..." followed by example image markup that includes |right, despite that right hand placement is a default parameter ... Is this possibly an artifact from a time when images did not automatically default to the right, or am I missing something?--Fuhghettaboutit (talk) 11:59, 18 January 2009 (UTC)

I have made the change to the page reflecting that right it is the default, highlighting that right placement is preferred in most places, and describing how to override.--Fuhghettaboutit (talk) 13:45, 26 January 2009 (UTC)

It seems like "right side is the default" became "right side is preferred" as someone's afterthought. Unless someone can explain why the right side is preferred, and left placement must be a "warranted exception", I think we should just say

By default, images appear against the right margin. To place them on the left margin [etc etc] [Note: bolding added for ease of locating the two options]

Thoughts?

E Eng

I was clear at WP:ANI about why I objected to your and BushelCandle's edits. It's not just about me objecting to those two aspects; it's about the fact that you two are steadily changing a guideline with longstanding rules that have worked well for years, and you are doing this without WP:Consensus. I object to all such edits, really. It was also made clear in that WP:ANI thread that others feel the same way about making changes to a guideline. To you, there is no consensus version in this case, but there has been for years. While I am aware that WP:Consensus can change, there is no consensus at all for the new wording. The WP:STATUSQUO essay exists for things like this. WP:Consensus is a policy people too often ignore. And even during the aforementioned RfC, you and BushelCandle are making changes. You two have made changes that have been disputed times before; the guideline has been the way it has been for sometime because what it stated before edits by you two has been shown to work well for years. Significant changes to Wikipedia guidelines or policies often significantly impact Wikipedia. And I'm not convinced that all these latest changes are for the best. The WP:RfC is clearly needed, as others feel similarly. On a side note, would you mind moving this discussion to the RfC Discussion section since that is where the latest discussion is, and since this section you've made addresses the RfC aspect?

As for your "right-justified" arguments, how are right-justified images not the best position for images in Wikipedia articles, especially for lead images? How is putting images on the left beneficial, other than the occasional "I want to alternate images" aspect some editors indulge in. That "I want to alternate images" aspect commonly results in WP:SANDWICHING issues, not just at the hands of newbies but also at the hands of our experienced editors; some of our experienced editors are not even aware of the WP:SANDWICHING guideline. You could argue that Wikipedia is simply used to right-justified images, just like society is used to right hand-justified materials since most people are right-handed, but placing images on the left sometimes seems to create awkward-looking text, especially with regard to a small section and how that aligns with a heading, whereas I haven't seen the same for right-justified images. Flyer22 Reborn (talk) 00:09, 28 January 2016 (UTC)

The exact guideline that you just linked to gives one of the possible reasons for left-aligned images: "It is often preferable to place images of people so that they "look" toward the text. (Do not achieve this by reversing the image, which creates a false presentation e.g. by reversing the location of scars or other features.)". As for the rest of your arguments, you appear to be attempting an appeal to tradition, a logical fallacy. I think the discussion here makes clear that there is not currently a consensus for forbidding larger-than-default images, nor for forbidding left-side images, however much you might like there to be one. And EEng has already demolished the argument that the consensus once existed in the case of left-facing images, by looking at the actual discussion when that change was made. —David Eppstein (talk) 00:16, 28 January 2016 (UTC)

David Eppstein, for "left-facing" images, you mean of course "left-justified" images. E Eng 04:18, 28 January 2016 (UTC)

Er, yeah, the other left. I often have difficulty telling left from right without looking at my hands to see which one has a ring. —David Eppstein (talk) 04:53, 28 January 2016 (UTC)

Your "appeal to tradition" argument is incorrect. Our definitions of consensus differ as well. If my appeal is anything, it's "If ain't broke, don't fix it." You, and others with your viewpoint, have failed to convince some of us that the longstanding rules are broken or need improvement. Those rules have been proven to work and be significantly beneficial for years. The proposals are just that -- proposals. Flyer22 Reborn (talk) 00:30, 28 January 2016 (UTC)

In fact, the WP:SANDWICHING guideline mentions one of the issues I've seen with left-aligned images: "In a few web browsers, bulleted lists overlap with left-aligned images. It may be preferable to avoid placing a left-aligned image near lists." Flyer22 Reborn (talk) 00:14, 28 January 2016 (UTC)

That's a good reason for not placing left-aligned images near bulleted lists. It's a very bad reason for instituting a more general ban on such alignment. —David Eppstein (talk) 00:17, 28 January 2016 (UTC)

It's not an argument for "instituting a more general ban on such alignment." You and EEng seem to take "As a general rule" or "In most cases" type of wordings as some type of "you can't do things that way" rule. It's not, just like it's not with regard to WP:Lead. It's guidance on best practice, and that exceptions to the standard may be justified. This a guideline, not a policy. Guidelines have more leeway, and people should forgo the general rule when it is validly warranted. Flyer22 Reborn (talk) 00:30, 28 January 2016 (UTC)

As a general rule, guidelines of the form "as a general rule" are used as cudgels by editors to enforce the rules much more strictly than that wording would imply (e.g. by preventing passage of an article through GA until the rule is obeyed). And in fact you yourself have stated that you want this rule to be in place as a way to persuade other editors to fall in line with your preference for small images. So we should be very careful about including such wording, and only make such rules when the exceptions are indeed rare. In this case, I may be biased by mostly editing mathematical articles where the images are usually diagrams needing larger-than-default size to be legible, but I think the exceptions are not rare. And if you look at the discussion on whether we should keep the guidance to avoid larger-than-default images even "as a general rule", it seems clear to me that opinion is sufficiently divided (at least so far) that there is no consensus on any such general rule. —David Eppstein (talk) 00:42, 28 January 2016 (UTC)

Nowhere did I state or imply that I want "this rule to be in place as a way to persuade other editors to fall in line with [my] preference for small images." I stated, "The new wording makes those of us who have to deal with such bad image formatting unable to sufficiently combat such bad image formatting. [...] The 'As a general rule' and 'In most cases, the default image size should be used' type of wordings helped for quite sometime in keeping unreasonable image size under control. [...] It seems that you and others are trying to appeal to all readers; that's not always possible, and Wikipedia commonly gives priority to the majority rather than the minority. For the minority, it commonly has alternative options. [...] I'm not stating that I prefer tiny images; like Mandruss noted, 'In many cases, the thumbnail is large enough and there is no need to click-thru.' I'm stating that there usually is not a good reason to bypass that default size or to have a huge image in the article. [...] The 'As a general rule' wording worked fine for this guideline, just like it works fine for the WP:Lead guideline despite editors who continue to try to get that guideline changed in the same disorganized fashion that you have changed this one. [...] I'm not stating any of this out of personal preference; I'm stating it because I have seen it be an issue for years (keep in mind that I have been with this site since 2007), with many editors fighting over image size. Once we point editors to the 'As a general rule' wording, the dispute usually settles down. [...] Certain editors here simply don't like rules and don't know how to adhere to them. They have a 'rules are meant to be broken' attitude, or they evoke WP:Ignore all rules for everything. They want our guidelines and even our policies to be loose with everything so that they can do what they want; I'm the exact opposite of that."

That is what I stated. I am not as strict with guidelines as you make me out to be, and that is clear by my recent comments on different guideline matters. Curly Turkey stated above, "Fixed image sizes should be avoided in general, but there are cases where they're appropriate, such as in tables. Exceptions should be exceptional, though, and I think they are covered by the 'as a general rule' wording—so [...]." I and others have echoed that sentiment. I have no problem at all forgoing a general rule when the forgoing is warranted. Flyer22 Reborn (talk) 01:55, 28 January 2016 (UTC)

Note: I moved the "Resuming discussion" section here per what I stated above about its location. Flyer22 Reborn (talk) 01:59, 28 January 2016 (UTC)

For the nth time, my edits are meant to improve the presentation without changing the meaning. Such an effort doesn't require excruciating prior discussion of where to indent and where to place bulletpoints. Such changes are almost impossible to discuss -- you just make a change so others can see what you mean, in loco.
If, here or there, there's an inadvertent change of meaning, or you feel an earlier turn of the phrase should be retained, you can just undo or fix that edit.
I do such editing in very small quanta, so it's easy to see that presentation, not substance, is being changed at each step -- each of which can be easily undone if needed. (In the case of the #Size section, material was imported from WP:Image use policy, so what you seem to think is new is actually just conformance to that policy.)
You say,
- "You, and others with your viewpoint, have failed to convince some of us that the longstanding rules are broken or need improvement." For the n+1th time, I'm not proposing changing the rules, just improved presentation.

"The WP:RfC is clearly needed". No, it was completely unnecessary. If you had simply edited in your desired change, I doubt anyone would have objected. In the end I just did it for you (and would have done so sooner, except your objection was so vague I couldn't see where to insert the text).
"And even during the aforementioned RfC, you and BushelCandle are making changes." Everyone doesn't have to stop because you've objected to one tiny bit of a large set of changes.
"I'm not convinced that all these latest changes are for the best." I'm sure you're right: undoubtedly they're not all for the best, because I'm fallible. So undo/fix the ones that aren't for the best.

As to left-right (where I am suggesting an actual change) you ask, "how are right-justified images not the best position for images in Wikipedia articles, especially for lead images? How is putting images on the left beneficial"? I don't know, but I trust editors of individual articles to decide that for themselves. (I agree lead images should be on the right, like infoboxes are -- I'm certain some guideline somewhere says so.) As seen above, the idea that "most" images should be on the right is just something someone made up one day. MOS is grotesquely bloated, and if we don't need a rule, then we need to not have that rule.

Now I'd really like to hear what other editors think about the "most on the right issue". I've put the two options in bold above. E Eng 04:18, 28 January 2016 (UTC)

Whatever you meant, I mostly disagree with you. You don't just change presentation; you change the meaning in some cases as well. Otherwise, there would not be as much debate regarding your changes now; the debate clearly has not solely come from me. And my objecting to your changes is not just a matter of me objecting to those two aforementioned aspects; I already stated that. There is no need for us to keep repeating ourselves. Getting outside input is good in cases like this, and that's what I've done with the first RfC; from what I can see, it is absolutely needed. And I'll perhaps start one on the right-adjusted matter as well. The dispute regarding the "As a general rule" aspect should be resolved first, since it's clear by the RfC that people have different opinions on it. Flyer22 Reborn (talk) 06:27, 28 January 2016 (UTC)

For the n+5th time, if the meaning changed here or there, just WP:SOFIXIT.
No, the debate has come solely from you. When version 2B was installed live, there were 5 supports and 4 opposes:

you,
someone who bizarrely claimed "no one uses upright",
someone who (equally bizarrely) thought upright is a "hack",
someone who said he/she couldn't even tell what we were !voting on (and expressed puzzlement at the other oppose-er's idea that no one uses upright).

You're the only person still saying, "I'm don't like it ... There are problems ... I'm opposed" -- and you've pointed only to two little phrases you dislike, both of which have been changed to suit your preference. If your only continued objections are vague I-don't-like-its, there's nothing more to discuss. Have the last word now if you wish -- I'll be busy improving the presentation of the guidelines. E Eng 17:51, 28 January 2016 (UTC)

EEng, repeating yourself does not make you correct. As the current state of the guideline edit history shows, as the RfC shows, and as the #Should we really be encouraging a hack? discussion shows, I am not the only one stating, "I don't like it ... There are problems ... I'm opposed." And it's exactly why Ymblanter full-protected the page after my and Moxy's requests, seen here and here. Although I'm certain that the guideline needs more than three days full protection, I thank you, Ymblanter. SlimVirgin tried to return the page to the WP:STATUSQUO, with a request that we work all of this out on the talk page first, but you (EEng) and BushelCandl couldn't wait. What we had was an unstable guideline; it was being changed day in and day out on editors' whims or preferences, with absolutely no consensus. The latest changes are not simply minor changes. And I don't want to go in and make significant changes to a longstanding guideline without consensus; I want to make sure that all of the significant changes are beneficial for Wikipedia and have consensus; that is the core of my disagreement with you on this matter. Flyer22 Reborn (talk) 22:48, 28 January 2016 (UTC)

The RfC is only about one small phrase you disputed, and reflects not at all on the rest of the changes.
The preference for upright has been part of WP:Image use policy since at least 2012 (the recent changes here merely reflect that) so the question "Should we really be encouraging a hack?" is a nonstarter.
"The latest changes are not simply minor changes" -- you keep saying that, but after repeated requests you have refused to give even one example. so stop whining about process and get out of the way while others continue to improve things.

E Eng 23:40, 28 January 2016 (UTC)

@Flyer22 Reborn: "Return to the WP:STATUSQUO" should not be seen as a long-term solution, lack of consensus in this or other RfCs here should not be interpreted as consensus for the status quo ante, and continually making more and more RfCs until everyone is tired of responding to the same questions over and over should not be used as a way of enforcing your preference for the status quo. Rather, when an RfC calls the question of whether there is consensus for a part of a guideline, and the results of the RfC demonstrate that there is no consensus, that part of the guideline should be ripped out. As for the page protection: I'm at a bit of a loss over why it was imposed after we seemed to have agreed to discuss the major changes, and after the edits on this MOS section had become minor copyedits and clarifications, but in any case it was clearly intended to promote discussion, not to close off the discussion and give you your way. —David Eppstein (talk) 00:14, 29 January 2016 (UTC)

EEng, other changes you've made are clearly disputed. You can keep making it about me, but it isn't. You always do this: Make significant changes to our guideline or policy pages without consensus, and that needs to stop. This is also clear at the WP:Image use policy page; one example is this edit by Redrose64, which reverted you and relayed, "rv all of today's changes - this is a *policy* doc, and changes should only be made after discussion." Like I stated, you always do this. I have various guidelines and policies on my watchlist, and I help improve some of them. I clearly have a different style than you do. And that style is never me being in the way.

David Eppstein, nowhere did I state or imply that "Return to the WP:STATUSQUO" should be seen as a long-term solution." Nowhere did I state or imply that I will continually make more and more RfCs "until everyone is tired of responding to the same questions over and over" and/or as a way of "enforcing [my] preference for the status quo." I've been explicitly clear about how I feel about people making changes to longstanding rules with no consensus or indication that such changes are improvements, edit warring over the rules, and creating unstable guidelines. You often take my comments and twist them. Perhaps what I've stated is not clear to you, but it's clear to others. So I disagree with you, per what I just stated to EEng. And there is no need to ping me to this talk page. Flyer22 Reborn (talk) 00:33, 29 January 2016 (UTC)

I've yet to see a clear link to any policy that currently demands that "In most cases, images should be right justified on pages...".

Consequently unless and until ALL the users of the English Wikipedia are canvassed by a notice on every page (such as when we have fund-raising) I am vehemently opposed to such dictatorial wording that is unjustified by policy.

If this is a binary alternative, I much prefer By default, images appear against the right margin. If an exception is warranted... BushelCandle (talk) 08:09, 28 January 2016 (UTC)

It's not a policy, it's a Manual of Style, meant to provide a consistent style and approach to all pages on WP. Right-aligned images is one of those things that bore out from the MOS for images in the past. Keep in mind that MOS is not policy (since most MOS is about style and not content) but does carry weight for consistency. --MASEM (t) 23:45, 28 January 2016 (UTC)

I hope the edits over at Wikipedia:Image use policy are not related to the editwar here. -- Moxy (talk) 21:10, 28 January 2016 (UTC)
- I imagine they're related, but they looked more like clarification of a technical issue (upright not working well at small pixel sizes) and less like attempts to unilaterally change the policy to me, so I'm not overly concerned with them. —David Eppstein (talk) 00:18, 29 January 2016 (UTC)

David Eppstein: Well, I reverted the additions to Image Use Policy, for reasons given in my edit summaries starting here [10]. If anything, we should be consolidating all this image-size-and-formatting stuff here at MOS/Images, and then eliminate the overlapping and conflicting stuff on that subject on the five other pages (I counted!) that talk about it -- and for sure new stuff like what I reverted at Image Use Policy -- should be added here, not on the five other pages, so as to contribute to that consolidation and centralize discussion.

Next thing I know I get a not-paying-attention admin restoring those changes, telling me to get consensus [11]! Huh??? E Eng 01:02, 29 January 2016 (UTC)

The image use policy should only include things that are a matter of policy (e.g. images must be properly licensed), not a matter of stylistic guidance (e.g. what is the preferred way to set the size for small images), I agree. I guess that means we need to hold a discussion there as well, on how to achieve that? —David Eppstein (talk) 01:14, 29 January 2016 (UTC)

Not sure what you're saying. I'm pretty sure that most or all of the WP:Image_use_policy#Displayed_image_size section grew up there as a sort of accident (probably growing out of the bit about uploading best-quality images, no need to upload separate versions for use as thumbs, software automatically scales everyting, etc.). Part of what I was doing in my recent set of changes here, at MOS/Images, was to start importing all that material here, with an eye toward consolidating formatting stuff here and eliminating it there, as described in my post just above here. To do that, I don't think anything needs to be discussed over there, except maybe at the end when everything there is now here, and a pro forma discussion might be held before deleting its copy of it. E Eng 01:40, 29 January 2016 (UTC)

To comment on one of the original points @EEng: made above, while I can agree that right-aligned image as the MOS default likely fell out partially from right-aligned being the default option for image placement, there are two valid right to prefer right-aligned: they will not interfere with key left-aligned section headers, and that flow of text around a right-aligned image is generally less disruptive and easier to read (due to the consistent left border) than around left-aligned images. This doesn't mean right-aligned is the only allowance, and as you've pointed out there's plenty of reasons to use left-aligned (such as person-facing-in or for images against a long infobox). But in general if you are dropping an image into an article where there are no other images to clear, right-alignment is strongly suggested for best reading options. --MASEM (t) 23:52, 28 January 2016 (UTC)

Exactly, Masem. Like I stated above, certain editors seem to take "As a general rule" or "In most cases" type of wordings as some type of "you can't do things that way" rule. It's not, just like it's not with regard to WP:Lead. It's guidance on best practice, and that exceptions to the standard may be justified. This a guideline, not a policy. Guidelines have more leeway, and people should forgo the general rule when it is validly warranted. Flyer22 Reborn (talk) 00:36, 29 January 2016 (UTC)

This seems disingenuous to me. Guidelines are treated here more strongly than just general advice. For instance, the first rule for good articles is that you shall not pass unless you obey a selected set of MOS guidelines. Therefore, we should be careful only to include suggestions when it would not be reasonable for a good article to disobey them. —David Eppstein (talk) 01:04, 29 January 2016 (UTC)

WP:Policies and guidelines currently states, "Although Wikipedia does not employ hard-and-fast rules, Wikipedia policy and guideline pages describe its principles and best-agreed practices. Policies explain and describe standards that all users should normally follow, while guidelines are meant to outline best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense."

That's how I treat our rules. Flyer22 Reborn (talk) 01:34, 29 January 2016 (UTC)

The MOS part of our policy/guidelines have a fix of prescriptive and descriptive elements. Most of the prescriptive ones (that is, that should always be follow with very few exceptions) are regarding the small details, such as logical quotations, using non-breaking spaces between a number and its following measurement unit, and the like. The ones that relate to layout, appearance, etc. like image sizing and placement fall as descriptive ones, meant to prevent edit warring over a non-essential detail more than anything else. I have never seen a GA or FA failed because of going against the MOS's advice on image placement, though I have seen suggestions made by reviewers to improve the image layout. Consider our image advice falling into the "should/could" of the MoSCoW method, while things like punctuation are more "musts". --MASEM (t) 16:54, 29 January 2016 (UTC)

I disapprove of strong—even general mild—inhibitions against larger image sizing than the default, which in many contexts is too small to show important details. When I co-led the move to up the default size from the tiny 180px to 220px (I think it was in 2009), many editors voted for 240px (or more); but we erred on the conservative side. It would be better to word the guideline in terms of using the default unless there is a reason to depart from it. Tony (talk) 05:52, 29 January 2016 (UTC)

Tony1, Might I suggest you register your opposition in the main !voting section? E Eng 10:36, 29 January 2016 (UTC)

Yes he should, though he will then no doubt receive some dismissive characterization from you! Johnbod (talk) 13:46, 5 February 2016 (UTC)

I don't know why, since I agree with him. Anyway, I reserve my dismissive characterizations for those who endlessly complain vaguely, without ever specifying what it is they're complaining about. E Eng 23:42, 5 February 2016 (UTC)

What has happened here...why does the MOS deal so much with upright now? Editors will not encounter this much when they edit..nor is it explained in most help pages or in the wizard. Need much more of a talk before big changes. dreaming we think upright will be all over all of a sudden. Its a great idea,,but just not how it is--Moxy (talk) 11:58, 5 February 2016 (UTC)

Indeed. There have been vast numbers of changes for which there is no consensus, and the discussion here has been taken by a couple of editors to a length that few can be bothered to follow. There may need to be a massive reversion at some point. Johnbod (talk) 13:46, 5 February 2016 (UTC)

This needs to be fix....the MOS doe not deal with what is going on. We should restore the size section to a version with real value....not some wish list. I suggest restoring the section to before the editwars. We need px values.....not more info on the upright that noone uses. Looks like the debate here has not helped the MOS -- Moxy (talk) 18:03, 5 February 2016 (UTC)

If we restore to the WP:STATUSQUO, EEng and/or BushelCandle will likely revert. Remember, SlimVirgin (SarahSV) already tried to restore the WP:STATUSQUO, and we saw what happened. Then we got the page full-protected, and EEng and BushelCandle went back to editing it as soon as that full protection wore off. Flyer22 Reborn (talk) 19:35, 5 February 2016 (UTC)

Best we restore till this is all worked-out....its clear there is a problem with the current text. it does not match anything else out there. Thus far we have two editors telling us what is best ..but its clear they are not sure themselves. Restore....not the communities fault they have a problem....we should not have to see it here...daily changes are simply not good.. -- Moxy (talk) 19:53, 5 February 2016 (UTC)

As explained several times before by me, by David Eppstein, by BushelCandle, and others, the material re upright is imported from WP:Image use policy, which has expressed that preference, and the deprecation of px, for many years. No long discussion is needed to bring a guideline into conformance with policy.
Beyond that, and excepting the two small phrases on which Flyer has opened RfC, these changes are intended to be straightforward copyedits and reorganization improving the presentation without changing what's being presented i.e. what the guideline actually recommends. Despite numerous requests (e.g. [12] -- just one of many) over two weeks, no example to the contrary has been offered -- no example of anything added, removed, or changed. Absent that, all this wringing of hands and gnashing of teeth and tearing out of hair is more than a bit hollow.

E Eng 23:42, 5 February 2016 (UTC)

Actually we dont just copy and paste from one to the other ..no point in regurgitating the same thing all over..guidelines are to help people with what they will encounter in everyday life. As of now it just repeats the policy...this does not guide anyone more then the policy does....big mistake. -- Moxy (talk) 02:36, 6 February 2016 (UTC)

Moxy's comment fails to make a distinction between (1) what we must do (policy), (2) what we should do (guidelines), and (3) what we actually do. As EEng says, currently the use of upright is policy, despite the fact that actually it is seldom used. What I would prefer is to downgrade it from policy to guideline, which involves strengthening the language here but also weakening or removing the language about upright on the corresponding policy. The fact that many articles are badly formatted does not mean that we have to describe their poor formatting as our idea of best practices here. —David Eppstein (talk) 00:06, 6 February 2016 (UTC)

This sounds like a good idea....but as has been said before by many upright is simply not used...nor is it explained much in our help pages or other pages. Not having values here that editors will find makes the page less then useless. We have been making guidelines for 15 years...they are here to guide people...not make people run to a help desk asking WTF is upright....when all I see is |px= . So to be clear here having no px values is a mistake....I dont care if upright is there....just need to see info on " Thumbnail sizes". What is going to happen is the help desks when asked will simply link people to the "how to pages" over the guideline if the guideline does not cover the basics that people ask about.- Moxy (talk) 02:36, 6 February 2016 (UTC)

I guess you overlooked that the help page to which you link (and permalinked here) also deprecates px in favor of upright:

Normally the size should be specified as a value relative to the user's preferred base size, using the upright parameter rather than pixel values.

(That page is a complete joke as a help page, BTW -- grotesquely prolix, and written with no understanding whatsoever of how to explain something to someone, and detailing options and syntax never, ever used -- but that's a different matter.) E Eng 05:12, 6 February 2016 (UTC)

Did not get the point of the post at all did you? Yes upright is fine as said above by me and others...what is needed is px values explained here...not some help page. We dont want people to get info like this - as you put it- from a "joke" help page. I see why there is little progress here . -- Moxy (talk) 07:11, 6 February 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

[1] If you work a lot with image layouts, consider leaving your preference at 220px to match the "reader experience" of most readers.

[1]