Template talk:Multiple image/Archive 2

Archive 1

Archive 2

Archive 3

Request to support 'upright' size

I'd like to request a modification of the template to support the 'upright' size option. Thank you. Praemonitus (talk) 17:08, 14 May 2015 (UTC)

That doesn't actually add any functionality, as upright is just a factor to multiply width with. -- [[User:Edokter]] {{talk}} 17:42, 14 May 2015 (UTC)

Actually it does. Applying a fixed width takes away user control; changing it to a scaling factor gives control back, while allowing increases in size for displaying fine details such as text. See Wikipedia:Autosizing images#Purpose of autosizing for more information. Praemonitus (talk) 15:17, 16 May 2015 (UTC)

While not mandatory, this template is hardly used without width parameters. If it is to support upright, it should also support height parameters. -- [[User:Edokter]] {{talk}} 19:37, 16 May 2015 (UTC)

The template not only fails to support |upright=, it completely ignores the user setting at Preferences->Appearance. Its |width= parameter appears to default to 200px. Where this template is used to stack thumbnails vertically, editors are converting to individual File: links, and for good reason. The template sorely needs to be brought into agreement with the existing handling of the File: link, vis-a-vis both the user setting and |upright=. ―Mandruss ☎ 15:52, 23 June 2015 (UTC)

The whole template is a hack for functionality not provided by the software. It's not supposed to be perfect. If you want something perfect, please submit a patch to do this in PHP in the core of the mediawiki software —TheDJ (talk • contribs) 19:39, 23 June 2015 (UTC)

In that case, I as an editor have the choice between a cool-looking vertical stack of thumbs or respecting the user size preference. The latter seems clearly more important, and I'll continue to convert such usage of this template when I see it. Thanks for the input. ―Mandruss ☎ 00:42, 24 June 2015 (UTC)

Note that I wasn't requesting perfection; just the implementation of a single feature. Does this mean the feature can't be implemented within the template code? Praemonitus (talk) 14:36, 24 June 2015 (UTC)

Correct. —TheDJ (talk • contribs) 18:16, 24 June 2015 (UTC)

Border gap width

caption

This may be too pedantic but it somewhat bugs me: The border gap of {{multiple image}} is 1px wider then the standard [[Image:]] format. For consistency, it should probably be narrowed. T.Shafee(Evo﹠Evo)^talk 08:12, 21 August 2015 (UTC)

@Evolution and evolvability: The extra 1px is intentional, it's there because of #Zoom breaks Horizontal layout above, and related matters. It's so small as to be unnoticed by the majority of our readers. --Redrose64 (talk) 15:08, 21 August 2015 (UTC)

@Redrose64: Thanks for the explanation. It's a pity that it's constrained by other issues. I'll have to just practice my deep breathing. T.Shafee(Evo﹠Evo)^talk 01:09, 22 August 2015 (UTC)

abcdefghijklmnopqrstuvwxyz

There's a connected issue: how footers are treated. When the footer is too long to fit, it's truncated to the right at the box edge, but starts at the left at the edge of the first image, as in the example opposite, where the footer is specified as |footer=abcdefghijklmnopqrstuvwxyz. This means that a reduction in the total width of the outer box could cause a "just right" footer to be truncated when it isn't at present. So although the point above is sound, any change needs some care. Peter coxhead (talk) 11:07, 21 August 2015 (UTC)

Height

I think Height parameter will be very useful. --Rezonansowy (talk • contribs) 14:28, 19 November 2013 (UTC)

Yes, it would: but unfortunately, to utilise that, we need some means of finding either the true dimensions of the image, or its aspect ratio. See #image height and several other threads. --Redrose64 (talk) 17:57, 19 November 2013 (UTC)

Maybe rewriting it to module will give a normal solution for height. --Rezonansowy (talk • contribs) 13:00, 20 November 2013 (UTC)

I fail to see how. Modules have no more access to either the true dimensions of the image, or its aspect ratio, than templates have. --Redrose64 (talk) 13:27, 20 November 2013 (UTC)

Actually, there has been some work on bugzilla:41498 and that might make this possible both from parser code function and lua module apparently. —TheDJ (talk • contribs) 13:33, 20 November 2013 (UTC)

The mode=packed with the gallery tag does a pretty good job. I wonder if we could just leverage this. Frietjes (talk) 19:25, 20 November 2013 (UTC)

That too. although I would point out that those new gallery options are still somewhat experimental. User:bawolff might have something to say about it. —TheDJ (talk • contribs) 22:17, 20 November 2013 (UTC)

I consider the new gallery types to be mostly stable. There haven't been any major issues reported (the biggest one I am aware of is if you have a very narrow aspect ratio image, the results aren't great, especially with long captions). Additionally, there hasn't been much new work on the new gallery stuff as of late (if you have feedback/criticism/etc please let me know). Bug 41498 was more about exif type metadata. Actual width and height is separate, although something that really makes sense for lua (probably something slightly easier to get through the review process as well). Bawolff (talk) 02:05, 21 November 2013 (UTC)

You guys are aware that you can output images using "xnnnpx" to set the height you want? For example is set to be 15 px high. Wnt (talk) 08:33, 10 December 2013 (UTC)

Yes, but that doesn't return the width, which is needed to calculate the width of the bounding box. —TheDJ (talk • contribs) 12:27, 10 December 2013 (UTC)

Absolutely. If we could determine the aspect ratio of each image, then we could indeed utilise a single height; but to perform calculations on it, it would need to be a bare integer, without initial "x" or terminal "px". --Redrose64 (talk) 17:39, 10 December 2013 (UTC)

Alright, I just had an exasperating session at User:Wnt/Templates/Sandbox and I see there's indeed a problem. I thought I could just shrink to fit - I have an example there that can do it for one image - but so far every attempt I've made to have two images horizontally either fails or leaves the text heading off for the hills. That's not to say it can't be done, just that the way things are set up seems very hard to predict. As for pulling bare integers out of text, that can be done in Lua - in fact, I set up a Module:LuaCall that calls built in Lua functions for use in other pages (though unfortunately I notice true built in functions like tonumber aren't working - I should work on that). For example {{#invoke:LuaCall|main|a=x434xx |b=%d+|mw.ustring.match(a,b)}} -> 434. Wnt (talk) 21:01, 10 December 2013 (UTC)

(Actually, though I just got tonumber() working, it's not actually useful - it's not parseInt - so you'll have to use mw.ustring.match) Wnt (talk) 21:45, 10 December 2013 (UTC)

Pulling bare integers out of text is the least of the problems. We need either an explicit width, or an aspect ratio which together with the height can be used to calculate the width. That is the basis for the advice in the documentation headed Matching image heights (the part about "construct an expression for the |widthn= parameters"). It could have been written something like this:

• {{#expr: (dh * ar) round 0}}

• where
  • dh is the desired height in pixels
  • ar is the aspect ratio (original width divided by original height)

But a height alone is simply not enough. --Redrose64 (talk) 21:57, 10 December 2013 (UTC)

Or someone can invest the time to make this truly expose the values using a lua module in the core, so we don't have to fly trough hoops. —TheDJ (talk • contribs) 14:14, 11 December 2013 (UTC)

The Bugzilla for getting the metadata seems like a useful template, but I'd like to see a parallel function to get the basic file parameters (the height and width we want) for any file regardless of metadata. Also high on my wish list: a way to get the complete contents of the file, so that we can use Lua to process file data - for example, so a module can make a histogram of pixel intensity in a jpg, or, my favorite case, to extract the text from a SVG file so that a Lua module can parse substitutions so we can color countries according to a data file with it. A third desirable function would be to put the data back into file form, so a generated SVG can be displayed here, but admittedly that is a security minefield. Wnt (talk) 22:49, 11 December 2013 (UTC)

A started a proposal on what a mw.file api should look like here: Wikipedia:Lua_requests#How_about_a_mw.file_api —TheDJ (talk • contribs) 13:55, 13 December 2013 (UTC)

Guys, I don't understand. Why are you still worrying about bugzilla and feature requests? Rezonansowy, isn't this template (below) already sufficient? You can edit-source and copy and paste it into any page. Cesiumfrog (talk) 09:59, 13 December 2013 (UTC)

First caption.	Second caption.
This multiple-image template does have a height parameter. (Here, for example, is set to 100 pixels high.)

• Your version does not follow the layout of actual thumbs, that is going to be problematic (especially with VE coming at some point).
• It uses tables. We shouldn't use tables for presentational purposes. We've been trying to get rid of it in infoboxes and amboxes for a long time, we shouldn't reintroduce them.
• It will make cells as wide as the widest caption (not desired). —TheDJ (talk • contribs) 13:55, 13 December 2013 (UTC)
• It also presents the textual information to screen-reader software in the wrong order: "Wide and squat image" "Tall and thin image" "First caption." "Second caption." ... instead of "Wide and squat image" "First caption." "Tall and thin image" "Second caption." ... --Redrose64 (talk) 16:30, 13 December 2013 (UTC)

The quick red fox jumps over the shy brown echidna.	This text wraps and wraps and so on.
This multiple-image template does have a height parameter. (Here, for example, is set to 130 pixels high.)

Thanks for the feedback! Redrose, I've now corrected this template-prototype so that it presents textual information in the desired order. DJ, regarding your three points:

• It actually does follow the same layout of actual thumbs (e.g., what encloses both is class thumb and thumbinner, with captions in thumbcaption). Could you clarify if there is something you still see that might sometime later in the maybe future become possibly problematic?
• Like you point out, we already use tables in other templates. They are universally supported. The alternative to tables has known bugs (for example, the horizontal multiple-image layout breaks in many browser versions, especially when zooming). Is this objection solely ideological?
• Captions do wrap exactly as desired. (For comparison, note the status-quo has a bug where long captions are sometimes misprinted over the top of the caption of the adjacent cell, rendering both unreadable.)

So I think this is the more practical solution right now. Am I still missing something? Cesiumfrog (talk) 00:33, 14 December 2013 (UTC)

Does the problem about "the horizontal multiple-image layout breaks in many browser versions, especially when zooming" still exist? In Firefox 25, I need to zoom out four steps from 100% before it breaks - at which point the text is so small as to be unreadable. I don't think that people will use such zooms. --Redrose64 (talk) 00:39, 14 December 2013 (UTC)

It sounds like you're telling me the problem still exists (not only for legacy browsers, but also for the most current firefox). Although it may not impact the way you view wikipedia on your device, many other affected contributors have been troubled enough to come here and request a fix. Are you implying that the reason this highly-requested "height" feature should be withheld is because as a side-effect it fixes a widely-reported "zoom" bug, which you'd rather users work-around by obtaining different resolution screens? Cesiumfrog (talk) 02:04, 14 December 2013 (UTC)

The problem does still exist, but is very much reduced since I made this modification. It is not confined to Firefox (and never was): it shows to the same degree in Chrome 32 and Safari 5. Before my modification just over a week ago, the display broke in both Chrome and Firefox at the very first step of zoom-out, and Safari at the second (see #Broken); since that mod, you need to zoom out four steps before breakage occurs in any of those three browsers. I consider that to be not just an improvement but an acceptable fix: it is unlikely that people will wish to zoom out beyond the point where text becomes too small to read - by this time the unreadable text will surely be a much bigger problem than a few misplaced images. --Redrose64 (talk) 09:43, 14 December 2013 (UTC)

I acknowledge that the remainder of the bug may not affect you personally, but that doesn't mean it isn't impacting other users. For example, on a low-resolution screen it can be necessary to zoom out (many steps) in order to appreciate the big-picture. But anyway, we're getting off-topic; my proposal eliminates this bug as a side-effect, but its main purpose is to fulfil the frequent request for a height parameter. Why are you not in favour of permitting this? Cesiumfrog (talk) 09:56, 14 December 2013 (UTC)

• I still think my 3rd point about the caption is incredibly annoying. But I notice that FF handles it differently, so i'll show you a screenshot of Chrome/Safari: http://imagebin.ca/v/15Hcss7ybvwy —TheDJ (talk • contribs) 10:27, 14 December 2013 (UTC)

Conceded. Cesiumfrog (talk) 11:18, 14 December 2013 (UTC)

The quick red fox jumps over the shy brown echidna.	This text wraps and wraps and so on.
This multiple-image template does have a height parameter. (Here, for example, is set to 130 pixels high.)

DJ, does this third version display correctly? Cesiumfrog (talk) 12:21, 14 December 2013 (UTC)

Applying display: table-caption to the entire table is not a good idea, since the whole table is not equivalent to a <caption>...</caption> element. --Redrose64 (talk) 22:42, 14 December 2013 (UTC)

Why is it not a good idea? (Is the reason practical or ideological?) Cesiumfrog (talk) 00:46, 15 December 2013 (UTC)

I believe that it can cause accessibility issues, particularly where screen reader software is in use. The table is being asked to state that it's something that it isn't. I shall consult RexxS (talk · contribs) on this later today. --Redrose64 (talk) 01:13, 15 December 2013 (UTC)

It shouldn't make a difference in that regard. Readers are not allowed to interpret style information in that way, they should only look at the semantic (HTML elements) or annotation information (aria attributes). It will still see this as a table. Putting role="presentation" on the table should take care of that though. —TheDJ (talk • contribs) 20:49, 15 December 2013 (UTC)

Yes, RexxS said that about display: table-caption but would like to know where the idea came from? --Redrose64 (talk) 22:18, 15 December 2013 (UTC)

Well, readers don't always behave as we expect and sometimes don't just look at HTML elements. For example, display: none is usually interpreted by a screen reader as "ignore this element" - and mostly they do. Nevertheless, I don't think Cesiumfrog's solution is likely to cause issues; after all it only tells the user agent to display the table with the characteristics of a table caption (i.e. compact and the top element inside its container). It might be considered a bit 'hacky', but it does the job. I'd be tempted to run up a bunch of test cases in a sandbox and see if any problems show up there. But otherwise, well done Cesiumfrog! - it looks good to me. --RexxS (talk) 22:43, 15 December 2013 (UTC)

• I liked the good HTML/CSS ideas, but I've happened across a way to get the file width and height, so I've coded Module:FileData. It has a drawback that it isn't automatically updated if the file dimensions are changed; also, I just wrote it five minutes ago so let me know if you run into trouble. {{#invoke:FileData|height|apples.jpg}} = . I'm not telling you to use it, but I was pleased to discover we had the option. Wnt (talk) 18:24, 13 January 2014 (UTC)

@Wnt: it seems to be broken; Module:FileData is returning an empty string. --Redrose64 (talk) 17:46, 12 February 2014 (UTC)

See [1] and Module talk:FileData. @Jackmcbarn: removed the mw.message. functions that made it possible for this module to work at @Anomie:'s request, because they "serve no useful function" Wnt (talk) 18:22, 12 February 2014 (UTC)

@Redrose64 and Wnt: If something's not working now, it's not because of that. The removal hasn't deployed here yet and won't for another week. Never mind, I see. You disabled the module on your own before the code change happened. Jackmcbarn (talk) 19:51, 12 February 2014 (UTC)

Actually, someone else disabled it, but once I noticed I continued... reducing it, because there's no sense getting people's hopes up using something if it's only going to stop working on the 20. Wnt (talk) 21:09, 12 February 2014 (UTC)

What did I do?

I used multiple image tags on the Mandolin article to clean it up. But today, I realized I cannot click on the photos. Does anyone see what I did wrong; I assume that this can be fixed.Thanks, Jacqke (talk) 17:36, 4 September 2015 (UTC)

@Jacqke: If you're not using the |linkn= parameters, they should be removed. When present and blank, the images are delinked.

I would also suggest adjusting some of the uneven image sizes - see for example the group of three top of the History section. --Redrose64 (talk) 18:42, 4 September 2015 (UTC)

@Redrose64 I appreciate your help. When you say uneven image sizes, are you talking about vertical height?Jacqke (talk) 20:07, 4 September 2015 (UTC)

OK, I checked for the |linkn= tag and didn't have any. I tried making image sizes the same and that worked. Thank you.Jacqke (talk) 20:07, 4 September 2015 (UTC)

Is there a way to use different sizes? The different photo dimensions create a lot of dead space when photos are all sized the same horizontally.Jacqke (talk) 20:07, 4 September 2015 (UTC)

@Jacqke: By |linkn= I mean |link1= |link2= etc. I removed all of those that I could find with these edits.

Regarding this edit of yours and others like it: My comment "I would also suggest adjusting some of the uneven image sizes" was purely an observation on a matter of presentation. I did not mean to imply that image size has anything to do with clickability - it hasn't. To even up the heights, see Template:Multiple image#to match image heights. --Redrose64 (talk) 20:42, 4 September 2015 (UTC)

I was wondering about that. The funny thing is, though, it worked. After I resized two sets, all of a sudden, they all worked again. Thanks again!Jacqke (talk) 20:49, 4 September 2015 (UTC)

They began working after each of my edits. When I had made the last one, at 18:38, I carefully checked every image in the article to make sure that they all clicked through to the description page. Only after I was sure did I post here, at 18:42. --Redrose64 (talk) 21:31, 4 September 2015 (UTC)

I didn't see you had edited. By the time I looked for the tags you mentioned, you had already removed them. Again, thanks., Jacqke (talk) 01:48, 5 September 2015 (UTC)

header_align repeated

If you copy and paste the example into an article it throws an error because header_align is in there twice. Should one of these be removed? EyeTripleE (talk) 04:33, 21 October 2015 (UTC)

Yes. The error was introduced with this edit by Peter coxhead (talk · contribs). --Redrose64 (talk) 08:58, 21 October 2015 (UTC)

Yes, my error. It would probably be better if all the examples kept the parameters in the same order and position; the first example puts |header_align= after some other parameters, including |align=, and on its own line, whereas later examples put |header_align= on the first line. It was this inconsistency which led to my error (not that it justifies it). Peter coxhead (talk) 09:30, 21 October 2015 (UTC)

HELP - Code for 4-images (1tall/3short) in 2-Columns?

IF Possible - would like help in presenting 4-images: 1 very tall vertical image in vertical column-1 and 3 related short images (ie, 1; 2; 3) in an associated vertical column-2.

Seems the following "Template:Multiple image" code (see below) doesn't seem to work with vertical columns? - seems there's no "|percol= " (or related) option? - but maybe there's some other workaround? (nonetheless, horizontal rows seem to work ok - see example at => "Aromatum Chaos#Gallery") - my best efforts with this issue so far is at the following => "Sputnik Planum#Gallery" - in any case - Thanking you in advance for help with this - and - Enjoy! :) Drbogdan (talk) 21:48, 6 December 2015 (UTC)

{{multiple image |perrow= |caption_align=center |align=left |width=200 |direction=vertical
|image1=PIA20201-Pluto-ManyDifferentTerrains-20150714.jpg
|caption1=test1
|width1=
|image2=PIA20200-Pluto-BurneyBasin-CratersPlains-20150714.jpg
|caption2=test2
|width2=
|image3=PIA20199-Pluto-Mountains-NearSputnikPlanum-20150714.jpg
|caption3=test3
|width3=
|image4=PIA20198-Pluto-SputnikPlanum-Mountains-20150714.jpg
|caption4=test4
|width4=
}}

this template is not the best for galleries. I would say just use a standard <gallery>...</gallery> for the majority of the images, and a 'right floating thumb' for the tall image. Frietjes (talk) 17:52, 7 December 2015 (UTC)

@Frietjes: Thank you *very much* for your comments - and suggestion - yes - I agree - Thanks again - and - Enjoy! :)Drbogdan (talk) 18:15, 7 December 2015 (UTC)

Reporting potential error

I have successfully used this template in the last few weeks, but yesterday, something went wrong. Instead of formatting properly, the template appeared like this:

{{multiple image

| caption_align=center
| header_align=center
| align =right
| width =150
| image1=Anthony Kennedy official SCOTUS portrait.jpg | alt1=Justice Anthony Kennedy
| image2=Fyodor Mikhailovich Dostoyevsky 1876.jpg | alt2=Fyodor Dostoyevsky
| footer =In his concurring opinion, [[Associate Justice of the United States Supreme Court|Justice Anthony Kennedy (pictured left) cited Fyodor Dostoyevsky's (pictured right) famous aphorism: "The degree of civilization in a society can be judged by entering its prisons". Justice Kennedy wrote that "[t]here is truth to this in our own time".

}}

For the diffs, see this and this. Am I entering the syntax incorrectly? Thanks in advance for your help. Best, -- Notecardforfree (talk) 16:08, 28 December 2015 (UTC)

Missing ]] after 'Justince' in |footer=?

In his concurring opinion, Justice Anthony Kennedy (pictured left) cited Fyodor Dostoyevsky's (pictured right) famous aphorism: "The degree of civilization in a society can be judged by entering its prisons". Justice Kennedy wrote that "[t]here is truth to this in our own time".

—Trappist the monk (talk) 16:15, 28 December 2015 (UTC)

Ah! Silly me! I thought I had gone through everything with a fine-toothed comb, but I now see the error of my ways. MANY thanks for your prompt reply! Best, -- Notecardforfree (talk) 16:20, 28 December 2015 (UTC)

Pixel width deprecated

WP:IMGSIZE says, "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." Otherwise the user's image size preference gets ignored. Is there some way to reconcile that instruction with this template? I'm not sure it would make sense to use a scaling factor, given that we've got multiple images; would you multiply the user's prefered width by the number of images? Kendall-K1 (talk) 16:40, 26 January 2016 (UTC)

Ultimately this template should be replaced by the gallery tag with |mode=packed (see here); this gives much better behaviour when displayed in windows of different sizes, e.g. on mobile devices. Peter coxhead (talk) 19:18, 26 January 2016 (UTC)

I haven't used the gallery tag when editing, but it doesn't look like you can have a caption that spans two (or more) images in the gallery. I think the unique value of the multiple image template is that it allows editors to use a caption that explains the relationship between two images. -- Notecardforfree (talk) 19:29, 26 January 2016 (UTC)

I agree that it's not yet a replacement for this template, but improving the gallery tag seems to me to be the best way forward. As it's embedded in the mediawiki software, it is more powerful. Peter coxhead (talk) 19:55, 26 January 2016 (UTC)

Doesn't respect user default image size preference

If one omits any image size parameters, this template sets all images at 220px wide, regardless of whether the reader has set a preference for some other default image width. This causes multiple images to look out of scale to the other images in an article. Can this be fixed to respect the user's preferences, please? —David Eppstein (talk) 19:02, 29 January 2016 (UTC)

The person to ask is Frietjes, because he was responsible for converting this template to a Lua module (its code is at Module:Multiple image). Reading the Lua, I think the default width is 200 rather than 220. I suspect that it's not possible to access the user's preferences from within Lua, any more than it is from within the template language. Peter coxhead (talk) 15:35, 30 January 2016 (UTC)

"or she was responsible" :) unfortunately, width=frameless doesn't work. this has nothing to do with the lua version, and has been an issue since the initial creation of the template. does anyone know if <gallery>...</gallery> respects user thumb size preferences? Frietjes (talk) 15:38, 30 January 2016 (UTC)

we might be able to do something here, by adding a feature to use 'upright=' to set the sizes, but there would be no way to then set the outer container size. Frietjes (talk) 15:40, 30 January 2016 (UTC)

I would definitely be in favor of allowing upright= as a parameter, and of setting upright=1 for images that do not have a size already set, in instances where the outer container size is not set. —David Eppstein (talk) 18:35, 30 January 2016 (UTC)

Help:Gallery tag says the default is 120px, which based on the examples and my tests, is the height for portrait images and the width for landscape images. Peter coxhead (talk) 18:59, 30 January 2016 (UTC)

It says "The default width and height are currently 120px. It is good practice not to overspecify the size (instead, accept the default size), unless there is a strong reason to override the user's viewing preferences." That seems contradictory to me. Is it always 120, or does it scale with the user's preference? Kendall-K1 (talk) 20:55, 30 January 2016 (UTC)

I believe, based on my tests, that the default is always 120. A gallery probably shouldn't have all its images the same size as the user's preference for a single image, but smaller, so 120px is reasonable for those who keep to the default 220px, but ideally it would scale. Peter coxhead (talk) 10:12, 31 January 2016 (UTC)

Apparently this is considered a bug; gallery images are supposed to autosize but that's broken now. See Help talk:Gallery tag#Size adjusting with packed. Kendall-K1 (talk) 13:14, 31 January 2016 (UTC)

New "lua" version causing problems?

Article HD_219134_b (archive demonstrating this) uses this template and has a new strange issue with the "Multiple image" template that appears in all revisions with this template. However HD_219134_c (archive) is also showing the same weird extendend box thing and is not using this template. So is this a problem with a particular version of Mediawiki or some other template issue? Davidbuddy9 Talk  02:13, 17 April 2016 (UTC)

It's nothing to do with this template. Your browser is centring the box between what it thinks are the available bounds, those being the edges of the page content box. It does not take the infobox into account at this stage. It then tries to fit the images into the available space, which is too narrow (because the infobox now comes into the equation) so it's pushed down below the bottom edge of the infobox. I suggest not attempting to centre the image(s), but really that's a style issue for WT:AST/WT:ASTRO. --Redrose64 (talk) 09:43, 17 April 2016 (UTC)

Mobile

This template is not visible on the mobile site. Bandar Lampung#Cityscape appears empty. Hairy Dude (talk) 11:17, 7 May 2016 (UTC)

@Hairy Dude: It's not visible on anything, not just mobile. But it's not a problem with the template but in the way that it's being used - the |image1= |image2= |image3= parameters are all blank, and have been since these edits. They are mandatory, otherwise how will the template know which images to display? --Redrose64 (talk) 19:21, 7 May 2016 (UTC)

Thought I had checked, but apparently not :/ Well that's just bizarre, the editor should have removed the template when he removed the images. Thanks for your edit removing it and sorry for the waste of time and unwarranted blame - it's just that I have come across quite a few templates that fail to display on mobile for no good reason! Hairy Dude (talk) 02:14, 8 May 2016 (UTC)

In this case, "the editor" that removed the images was CommonsDelinker (talk · contribs), which is not human but a bot; presumably it's not programmed to look at the bigger picture, just to remove invalid image links.

As for the recent removal of the {{multiple image}}: I didn't do it, just in case somebody wanted to fill in those params. It was actually removed by Nagualdesign (talk · contribs). --Redrose64 (talk) 10:27, 8 May 2016 (UTC)

If one omits any image size parameters, this template sets all images at 220px wide

The documentation states "If one omits any image size parameters, this template sets all images at 220px wide" but I have found that it instead sets all images at 200px wide. Could somebody please fix the template to do as the do documentation says at set images at 220px wide instead? Thank you, New9374 (talk) 06:12, 5 July 2016 (UTC)

@New9374: I think that the documentation is in error: the relevant paragraph was added to the doc just seven weeks ago, at 08:23, 14 May 2016 by BushelCandle (talk · contribs) with this edit. The action of the template itself has been 200px since 23:11, 4 June 2011 when Plastikspork (talk · contribs) made this edit, which was requested at Template talk:Multiple image/Archive 1#Edit request from FleetCommand, 6 February 2011. --Redrose64 (talk) 10:09, 5 July 2016 (UTC)

Sorry for not examining the code. I've still not examine the code, but changed "220px" to "200px". BushelCandle (talk) 12:17, 5 July 2016 (UTC)

Multiple image on mobile

Tracked in Phabricator
Task T148505

Why are all the images aligned vertically on mobile - [2]? Can anything be done about it? Hzh (talk) 00:11, 16 October 2016 (UTC)

Because on mobile we need safe defaults for narrow screens. Multiple image is 'hack' that does something that we don't really support. As such you can expect it to behave differently in certain situations. As long as it's readable, it's not really a problem worth dealing with right now. —TheDJ (talk • contribs) 09:37, 17 October 2016 (UTC)

@TheDJ: It doesn't really answer the question. On mobile it takes up the same width as a set of horizontally aligned images, but simply arranged vertically. It means there is a large empty space where horizontally-aligned would be, see for example the images for Adoxa moschatellina (in fact all the images specified to align horizontally). If you are concerned about narrow screens, aligning it vertically wouldn't help at all since it takes up the same width as when aligned horizontally. All it does it to make the space for the images much bigger. Hzh (talk) 10:44, 18 October 2016 (UTC)

I've investigated a bit deeper and it seems that this is specifically triggered by a workaround for the multiple image template inside the Minerva mobile skin. It also seems that this workaround is no longer required (though might need further confirmation), and have thus requested the removal of that style rule. —TheDJ (talk • contribs) 12:24, 18 October 2016 (UTC)

What is the status for request for the removal of the style rule? It is still that horizontally aligned images on desktop are arranged vertically on mobile with empty space at their right/left side where bottom image(s) should be.

Could module be altered by introducing some other hack (as same as these that prevent easy fixing of the problem) so that images are shown horizontally if a user chooses that – at least for 2 images aligned horizontally because this is probably the most frequent number? --Obsuser (talk) 22:09, 26 October 2016 (UTC)

@Obsuser: This should be significantly improved now. I still need to fix the header, which will need the following additional styling properties.

-webkit-box-flex: 1;
-moz-box-flex: 1;
width: 100%;
-ms-flex: 1 0 100%;
flex: 1 0 100%;
-webkit-box-ordinal-group: 1;
-moz-box-ordinal-group: 1;
-ms-flex-order: 1;
order: 1;

but i'll do that later. —TheDJ (talk • contribs) 08:38, 22 November 2016 (UTC)

Thank you. This template is very useful because there is no other way to arrange images so that their style (borders etc.) is as same as the original one – it is the "emulated" ordinary style of displaying images via File: syntax but allows different perrows etc. Thanks. --Obsuser (talk) 13:04, 22 November 2016 (UTC)

Remove border

|image_style=border:none

Is there an option to remove the border between the images in this template? I was expecting something like |border=0 like in {{Photomontage}} or the default in {{image frame}} but I don't see it czar 09:01, 7 July 2016 (UTC)

See Template talk:Multiple image/Archive 1#Box border and Template talk:Multiple image/Archive 1#Border color. --Redrose64 (talk) 12:57, 7 July 2016 (UTC)

• Back half a year later with the same issue... really wish there was a way around this czar 18:48, 6 January 2017 (UTC)

  All I can do is direct you to either the template's talk page, or its documentation. I cannot add any code to the template - this is not because of any lack of user rights, but lack of ability. It's been comverted to a Lua module, against my wishes, and is therefore impenetrable: I can't understand the present code, so adding a feature to it is out of the question. --Redrose64 🌹 (talk) 21:13, 6 January 2017 (UTC)

Czar, do you mean |image_style=border:none ? Frietjes (talk) 16:46, 5 February 2017 (UTC)

@Frietjes, yes! Thank you! Added an example above czar 17:55, 5 February 2017 (UTC)

Default width

Wouldn't it be better if this template defaulted to the user's thumbnail width (or the default wikipedia thumbnail width for non logged-in users) if a width isn't given?--Lead holder (talk) 19:45, 21 October 2016 (UTC)

@Lead holder: The problem is that we need to do calculations to fit everything and that that specific value is unknown to us. There is no way to figure out a user's preference value from wikitext/lua, which generates the output. Remember, this template is a 'hack'. As it comes to thumbnails, it is not a 1st class citizen of the wikitext language. —TheDJ (talk • contribs) 20:43, 21 October 2016 (UTC)

I understand. Thanks for the reply.--Lead holder (talk) 23:55, 21 October 2016 (UTC)

Wow, this is too bad! Was just about to ask this. SharkD  Talk  04:16, 9 May 2017 (UTC)

By the way, what is the default size for new users? SharkD  Talk  04:27, 9 May 2017 (UTC)

@SharkD: To find this out, first find a page that has an image with |thumb, without |upright=, and no forced size (such as the one in Dr. Jekyll and Mr. Hyde (1887 play)#First American productions). Then log out (if you aren't logged out already), and use your browser's "Inspect element" feature on that image. This should display the HTML, including a <img> element. Within that element will be a number of attributes; the one that you are looking for is width= - when I try this, I see width="220" so it's 220px. --Redrose64 🌹 (talk) 08:29, 9 May 2017 (UTC)

thumbtime

Please add the "thumbtime" parameter for movie files. Link. Thanks. SharkD  Talk  18:55, 22 March 2017 (UTC)

Template-protected edit request on 28 March 2017

Please add support for the "thumbtime" parameter of media files. Otherwise, media will always begin roughly halfway through an animation instead of at the beginning. Thank you. This parameter is discussed here. SharkD  Talk  02:40, 28 March 2017 (UTC)

I've coded this at Module:Multiple image/sandbox with a test case at Template:Multiple image/testcases#Test 17. Since this is my first attempt at LUA coding, I'd like someone else to review my changes before they go live. -- John of Reading (talk) 06:48, 28 March 2017 (UTC)

@Mr. Stradivarius:, could you help here? -- John of Reading (talk) 06:34, 29 March 2017 (UTC)

@John of Reading: Yep, this addition looks fine. :) — Mr. Stradivarius ^{♪ talk ♪} 11:38, 29 March 2017 (UTC)

@Mr. Stradivarius: Thanks! @SharkD: Done. -- John of Reading (talk) 12:30, 29 March 2017 (UTC)

Thank you! SharkD  Talk  23:53, 29 March 2017 (UTC)

Alignment

How would one go about aligning images stacked vertically which have different widths? Currently the default is left justified by I want right justified. For example, I want the two stacked imaged in Homology (chemistry) to be right justified so the molecules align. Tried image_style = align:right; Devon (talk) 02:42, 4 May 2017 (UTC)

Devon, this hack works. Frietjes (talk) 15:31, 6 June 2017 (UTC)

Mobile

Is there a way to force this to display in the same way on mobile as it does on desktop? Specifically, I mean something like what's currently on Poverty. On Chrome dev tools mobile it displays the same as it does on desktop, but on my actual mobile it displays as vertically stacked randomly cropped versions of the images. TimothyJosephWood 21:15, 27 June 2017 (UTC)

What kind of phone and mobile browser do you use ? If it's anything under Android 5, then likely the answer is no. Same for the stock Samsung browser. This is why it shows vertically stacked (cause that is safe and is guaranteed to fit on your screen). —TheDJ (talk • contribs) 21:57, 27 June 2017 (UTC)

Additional white space around photos.

1. Is there a better way to show more white space between photos than what I describe and show below?

2. Is there a way to not have the photos align so closely to the top, sides, and bottom of the box where they are displayed?

3. Can the outside border around the entire multi image display area be removed?

In the article Vehicle registration plates of Montenegro I came up with the following fix to add white space between the two photos. Changing the background color to white, removing the image border, and adding the photo "blank.jpg" between the photos enabled the photos to be spaced farther apart. Of course the blank.jpg photo takes up one photo image so, if there are more than five actual photos this fix won't work (since there is a limit of 10 photos with this template).

Police plate

Military plate

Zcarstvnz (talk) 14:45, 3 September 2017‎ (UTC)

Zcarstvnz, I added an optional |image_gap= parameter

Police plate

Military plate

let me know if there are any spurious issues. the additional parameter should not impact any existing uses, since the default is 1, and the code functions the same for a gap of 1. Frietjes (talk) 15:20, 3 September 2017 (UTC)

Hello, guys.

As I reported in Frietjes's talk page, I ran into problem with this change. In every web browser that I used (more than one), the image looked like this: https://imgur.com/a/Mf0eJ. However, Frietjes's investigation showed that for a user who visits Wikipedia for the first time, it looks as it should, like this: https://imgur.com/a/55vm8.

My investigations revealed that the culprit is the CSS rule for the tsingle class that overrides the right margin settings with an !important directive; however, for an ordinary user a CSS declaration for tsingle is never loaded! They might even think that the mention of this non-existent class is a harmless bug!

I reset my preferences to default and am now searching for the particular setting that deploys the CSS rule for the tsingle class to the client.

Best regards,
Codename Lisa (talk) 16:31, 4 September 2017 (UTC)

Culprit was found!

The following setting, found on your Preferences page, prevents a gap between the two images:

Gadgets → Testing and development → New image thumb design, and other minor styling tweaks (TOC, categories). Discuss.

Best regards,
Codename Lisa (talk) 16:48, 4 September 2017 (UTC)

Codename Lisa, does the !important override just margin-right, or both margin-right and margin-left? if it only overrides 'margin-right', then we can easily add the gap using 'margin-left' instead. Frietjes (talk) 17:57, 4 September 2017 (UTC)

This is the rule:

.tmulti .tsingle {
    margin: 0 !important;
}

But it got me wondering anyway: Why did you add tsingle and tmulti to the Lua module anyway? What was your purpose?

—Codename Lisa (talk) 20:16, 4 September 2017 (UTC)

Codename Lisa, it looks like those were added in this edit by Edokter, who does not appear to be actively editing anymore. Thanks! Plastikspork _―Œ^(talk) 06:03, 5 September 2017 (UTC)

Plastikspork, thank you. it looks like this edit is related (at nearly the same time). Frietjes (talk) 14:11, 5 September 2017 (UTC)

I ran into this exact same problem, and unchecking the gadget setting fixed it for me, thanks. Now how do we really fix this for other users? ɱ (talk) · vbm · coi) 03:19, 9 September 2017 (UTC)

Issue with total_width parameter

As with this edit, parameter |total_width= doesn't seem to work the way I expected it to. Based on the documentation is should resize all images to the same height which it currently doesn't. Rfassbind – talk 08:53, 2 February 2018 (UTC)

@Rfassbind: it also says "Do not use both total_width and width." This template is REALLY complex, and everything depends on the information you give it to make its calculations. "Provide height[n] and total_width parameters to obtain automatic resizing. Note the different meanings of the width[n] parameters with vs. without automatic resizing." —TheDJ (talk • contribs) 10:02, 2 February 2018 (UTC)

Ah, I see: "total_width" only works in conjunction with |height[n]= displaying the original height of the corresponding image (in pixel without px). In addition, the 3 examples in the documentation with "total_width" are also using |width[]=; so that doesn't hurt either. Keep up the hard work on this really complex template. Rfassbind – talk 11:20, 2 February 2018 (UTC)

@TheDJ, Rfassbind, and Mr. Stradivarius: according to the Lua reference manual we could automatically get the width and height information from the file metadata without requiring the user to provide it. however, I am concerned about the "this is expensive" warning in the documentation. what do you think? Frietjes (talk) 22:26, 2 February 2018 (UTC)

@Jackmcbarn: (who wrote Module:File dimensions) see the sandbox version of Test 15b which is using this technology (appears to work), but I have not tested all the possible bad-input scenarios. what do you think of this change? Frietjes (talk) 23:17, 2 February 2018 (UTC)

@Frietjes: Hi. :) Thanks for this info. My experiments with the version of infobox software in the sandbox were becoming hopeless. Maybe I should use this. —Best regards, Codename Lisa (talk) 10:55, 3 February 2018 (UTC)

Codename Lisa, I am not sure what you are trying to accomplish in {{infobox software}}? do you want Module:InfoboxImage to prevent image stretching? or is it something else? Frietjes (talk) 14:53, 3 February 2018 (UTC)

"Stretching" is close to what I have in mind. Module:InfoboxImage sometimes overscales them. I've currently developed code that confines very large icons and logos to 300×64px when there is a screenshot and confines the screenshot to 300px. But what about smaller images? They get upsized and overscaled. The only solution at this time is to specify an explicit size in |screenshot size= and keep changing this value whenever someone updated the image or some bot tampered with the resolution. (I've seen bots downsizing a 336px image to 325px, in the name of NFCC compliance!) I am looking for a much better solution. —Best regards, Codename Lisa (talk) 05:38, 4 February 2018 (UTC)

Auto image rescaling

I have updated the main module to allow for automatic image rescaling when |total_width= is used. hopefully there are no issues. to use the new feature, you simply omit all the width[n] and height[n] parameters, but use the |total_width= parameter. if all goes well, the module will fetch the dimensions from the file metadata for you. let me know if there are any problems. Frietjes (talk) 17:03, 10 February 2018 (UTC)

@Frietjes: Four articles were in the script errors category due to a weird issue with the new code. I edited the module to fix it. Consider the following:

    file = mw.title.new('File:Language_in_Albania_with_%25.png')  -- gives nil so adding ".file" is an error
    file = mw.title.new('File:Language in Albania with %.png')    -- works as expected so adding ".file" works

I put an extract from each of the problem articles at User:Johnuniq/sandbox2 (permalink). The extracts work at the moment due to my edit, but if you edit the 16:57, 10 February 2018 version of the module and preview it with "User:Johnuniq/sandbox2" the result shows four errors.

The images still seem to be broken and I'm hoping you will inspect my sandbox and work out what the problem is.

By the way, tonumber(x) is very safe. x can be nil or an empty string or a number with leading/trailing spaces (" 1.23 "), and the result is a number if it worked or nil if it didn't. I tweaked a couple of the tonumber instances but I noticed quite a few more. Johnuniq (talk) 06:59, 11 February 2018 (UTC)

Hmm, it turns out that decoding the image title seems to always work and shouldn't have much overhead. I just edited Module:Multiple image again, and now the images in sandbox2 work correctly. Before the latest edit, some of them were weirdly large and off the window. Johnuniq (talk) 08:53, 11 February 2018 (UTC)

Johnuniq, thank you for fixing the problem. it's hard to find all the issues until the change is deployed. I am surprised it was on about 4 articles, considering this module is used on over 20k pages. thank you again. Frietjes (talk) 15:09, 11 February 2018 (UTC)

Progress could not occur without trying things and there is no way anyone could have anticipated that strange result with the percent encoded title I mentioned above. Re my edit: it was focused on making the error go away. Perhaps there should be an error for this case. The code might try using the title as given (without mw.uri.decode) then give a hard error if it fails. However, it would use mw.uri.decode to tell the editor what needs to be done to fix the problem, something like "Error: BAD_TITLE should be GOOD_TITLE". Let me know if I should add that. Like a couple of others, I monitor the error category and will notice if there are any problems. I don't think a tracking category is warranted, just give an error. Johnuniq (talk) 22:10, 11 February 2018 (UTC)

Johnuniq, if the fix is really only needed for under ten pages, and there is a simple solution (correcting the image title), then I would say "yes", don't auto fix the title and instead issue an error message. thank you again. Frietjes (talk) 15:29, 12 February 2018 (UTC)

@Frietjes: I'm looking at the code planning to implement as above. Please check my edit to Module:Multiple image/sandbox, namely diff. As the module is now, it always outputs a category, either "auto scaled" or "manual scaled". Presumably that will always apply so there is no need for the nonautoscaledimages variable which I removed? Johnuniq (talk) 06:41, 13 February 2018 (UTC)

Scrub that question. I see the point now. Function getdimensions is called for each image so both variables might be set and the two categories might be output. Johnuniq (talk) 06:49, 13 February 2018 (UTC)

Johnuniq, correct, although I don't know if we really need the tracking categories going forward. I added that in the beginning so that I could have examples of images which weren't auto scaled before, but are auto scaled now, just to make sure nothing horrible happened. currently, the only pages populating the two categories are ones that use |total_width=, so there are also many pages that aren't in either category. however, now that it appears to be generally working, I am not as concerned. one interesting difference between the auto scaled and manual scaled is when you don't provide the native image dimensions. in that case, the image may be cropped, or not be full height. I found one article which was using this feature to crop a tall image (e.g. this version vs. this version). Frietjes (talk) 14:23, 13 February 2018 (UTC)

User image size preferences

I'm guessing there is a technical limitation preventing this template from being modified to respect user image size preferences. As it is, although it gives more flexible image positioning possibilities, it can be difficult to justify it because of the size problem. Is anyone aware of any alternative ways of setting images side-by-side or one above the other with a shared caption? -- DeFacto (talk). 10:05, 22 March 2018 (UTC)

DeFacto, it may be possible to use the |upright= parameter in the image syntax to scale the images from the user preference default, but (1) if I recall, images won't scale above the native resolution (may be a good thing), and (2) it will require some testing to get it right since we use absolute px spacing between the images. I will see if we can do something. Frietjes (talk) 15:38, 22 March 2018 (UTC)

@Frietjes: thanks. -- DeFacto (talk). 18:50, 22 March 2018 (UTC)

DeFacto, I made some changes to the sandbox version, but (as I suspected) making it actually work isn't that easy. it generally works, but I believe the upright scaling may be rounding the sizes in an unexpected way. Frietjes (talk) 18:53, 22 March 2018 (UTC)

you may also be interested in trying one of the modes in Gallery. if you put a 'style="float:right"' in the gallery tag, you can get the images to float to the right of the page. Frietjes (talk) 18:54, 22 March 2018 (UTC)

@Frietjes: ah, okay - thanks for looking it. -- DeFacto (talk). 19:20, 22 March 2018 (UTC)

Trying to Find Actual Wiki Markup for Template:Multiple images

So, I'm administrating my own wiki, but, I'm fairly new to this. I'm competent enough to follow intructions and whatnot, but, I can't figure this one out on my own. Normally, when I import a page, or a Template:, for example, there's something like

<noinclude> … [a whole bunch of wiki markup code] … </noinclude>

… or something like that.
And after that, there'll be a normal section that includes the "Usage" section. But, when I import this template, all I get is:

{{#invoke:Multiple image|render}}<noinclude>{{documentation}}<!-- PLEASE ADD CATEGORIES TO THE /doc SUBPAGE, THANKS --></noinclude>

So, even though I can find the markup for the "Usage", I can't actually use the Template, because the page is protected, and I can't even View Source to see it. Nor in the Template: … /documentation.

Can anyone tell me how to either import the code, or where to find it, so that I can put it on my wiki, too?
--IcarusATB (talk) 20:00, 23 December 2018 (UTC)

@IcarusATB: The {{#invoke:...}} means that one or more WP:Lua modules is being used. The module name comes immediately after; hence, this will be Module:Multiple image. Also, if you look at the documentation, there is a box at upper right headed "This template uses Lua:" that lists the modules. --Redrose64 🌹 (talk) 21:49, 23 December 2018 (UTC)

@IcarusATB: To use Lua, you will need to install Scribunto. Peter coxhead (talk) 22:08, 23 December 2018 (UTC)

Multiple image orientation template (SOLVED!)

A 18th-19th century Malayan style Kerambit (left), a 18th-19th century Sulawesi style Kerambit (top) and a 16th-19th century Sumatran style Kerambit (bottom).

Hi guys. I did this arrangement of images in an article but I could not figure out how to include a caption at the bottom of the combination of these multiple images. Is there a way to do a multiple images template in this arrangement with the regular caption and image thumbnail frame? Thanks. -Jeblat (talk) 04:15, 28 March 2018 (UTC)

Jeblat, at the moment, there is no way to have an image span multiple rows. it may be possible to do something in the future, but not yet. as far as I know, other photo array templates have the same restriction (e.g. {{photomontage}}). Frietjes (talk) 14:12, 28 March 2018 (UTC)

Thanks Frietjes! -Jeblat (talk) 15:15, 28 March 2018 (UTC)

Saw your edits on the Karambit article. Well done! I'll put the format that you did there over here. Thanks, Frietjes. -Jeblat (talk) 06:01, 29 March 2018 (UTC)

{| class="infobox" style="width:378px"
|rowspan=2 |[[File:Knife (Korambi) with Sheath MET 36.25.823ab 002june2014.jpg|161px]]
|[[File:Knife (Korambi) with Sheath MET 36.25.869ab 005july2014.jpg|218px]]
|-
|[[File:Knife (Korambi) with Sheath MET 36.25.873ab 002july2014.jpg|218px]]
|-
|colspan=2 style="text-align:center;" |A 18th-19th century Malayan style Kerambit (''left''), a 18th-19th century [[Sulawesi]] style Kerambit (''top'') and a 16th-19th century [[Sumatran]] style Kerambit (''bottom'').
|}

You can also try {{Image frame}} instead while necessary. --Great Brightstar (talk) 15:19, 9 February 2019 (UTC)

#mobile (stop using inline styles)

I've made this template mobile friendly by adding a stylesheet fixing display on pages such as Citole. Ideally we should stop using inline styles in this template and use the stylesheet so that we can cater better for mobile users. @TheDJ:. Jdlrobson (talk) 15:12, 11 August 2018 (UTC)

Jdlrobson, your edit has caused multiple images formatted to align horizontally to no longer display as such on the mobile site (see screenshot). That is a serious issue.Tvx1 14:25, 15 August 2018 (UTC)

My edit didn't introduce this. Reverting my change, I see it looks similar, if not worse (see my recent screenshot). At least they are centered now.

Screenshot of horizontal multiple image stacked vertically

There is a bigger issue here, in my opinion, which is the use of "left" and "right" in the caption which assumes a particular display, which is dangerous to do on mobile given all the formatting that occurs to make the article mobile friendly (see also: Wikipedia:Manual_of_Style/Layout#Images).

I can see several options here

• Rely on top and bottom and position them vertically
• Create a derivative image combining the two and use a single image.
• Update the template to support a special casing, which can be used when the combined width of the images is less than 320px (a typical lower limit for a mobile screen) that allows floating.

Jdlrobson (talk) 18:24, 15 August 2018 (UTC)

Jdlrobson, I moved the tag after the module call, which hopefully doesn't cause a problem, but does fix Fusion power#1970s. is there a particular reason why the module doesn't add the templatestyles tag directly (e.g., how it's done in Module:Flex columns)? Frietjes (talk) 19:46, 15 August 2018 (UTC)

Thanks! I was trying to avoid edits to Module's to make it easier to see the associated stylesheet but maybe that's a better idea. The phabricator ticket I opened didn't really help. I'm a little puzzled why it got declined despite acknowledging there is a bug so I will follow up on that later. Jdlrobson (talk) 03:15, 16 August 2018 (UTC)

If you feel that there is still a bug, then the bug is with any template that injects a newline at the top of its output. the problem here, and in most places, is fixed by not inserting a spurious newline after the . if the template creates a wikitable, then you can simply put the at the end of the table, or elsewhere. Frietjes (talk) 14:27, 16 August 2018 (UTC)

Jdlrobson, Frietjes the problem I reported still exists. Multiple images formatted to be arranged horizontally are still stacked vertically on the mobile site.Tvx1 18:07, 16 August 2018 (UTC)

Tvx1 I see the same problem, but only if the browser window is narrow (probably less than 720px per Template:Multiple image/styles.css). If I recall, before the recent changes, the images were wrapped, but only if there wasn't enough space to present the images horizontally. now, it happens whenever the browser window is less than some threshold, even if the images could fit. If we can't come up with a solution, we should remove the templatestyles until we can. Frietjes (talk) 19:57, 16 August 2018 (UTC)

Don't forget that we're talking about the mobile site here. The affected readers were concerned here don't generally access that version of the site on a large desktop screen, but rather on the small screens of mobile phones. Those are all affected by the stacking.Tvx1 20:17, 16 August 2018 (UTC)

I've explained this above. These images were always vertically stacked on mobile. This is an improvement on mobile screens. Before in many cases they looked broken like this tweet reports. Horizontally stacking on mobile does not scale to all the usages of this template and we should be making no assumptions about layout in image captions per Wikipedia:Manual_of_Style/Layout#Images.Jdlrobson (talk) 22:52, 16 August 2018 (UTC)

Well actually, the layout of this changed a couple of times, as we dealt with various bugs and rewrites of it. Regardless, this is fixable with some more flex box magic, but I need to find the time for that. —TheDJ (talk • contribs) 13:18, 17 August 2018 (UTC)

Well actually, the passage of the MOS you refer actually advises us not to refer image positions in plain text but to use captions to identify them instead. Now, we can't even use the captions because the image arrangement differs from platform to platform. What's the point of having a template that provides means to arrange a couple of images horizontally if we can't use it?Tvx1 13:59, 18 August 2018 (UTC)

TheDJ, Jdlrobson, Frietjes, just querying whether a solution has been found for this stacking problem.Tvx1 19:27, 30 August 2018 (UTC)

Tvx1, i haven't had the time to work on this. —TheDJ (talk • contribs) 19:48, 30 August 2018 (UTC)

Even with a flexbox solution this template is problematic if the combined width of images is greater than the screen resolution which would be most usages except the example where you have two side by side. Maybe referring to images from left in clockwise direction in caption would make the most sense, since order is the only thing that can really be guaranteed across devices. Jdlrobson (talk) 00:47, 31 August 2018 (UTC)

TheDJ, Jdlrobson, Frietjes, I noticed this stacking problem still exists. This is still quite a problem as it renders the horizontal orientation option rather useless.Tvx1 00:27, 25 January 2019 (UTC)

Tvx1, Jdlrobson, Frietjes.. I've prepped some changes in {{Multiple_image/sandbox/styles.css}} and Module:Multiple_image/sandbox. Should even be backwards compatible with float for older browsers (though less nice of course). Be careful judging these changes with the testcases as the currently existing CSS of the live version of multiple image pollutes the sandbox version (especially on mobile [i manually disable them with the inspector). I'll have to do some further cleaning up of the inline css styling thats still there, but this was the bulk of the job. —TheDJ (talk • contribs) 22:24, 17 March 2019 (UTC)

now deployed —TheDJ (talk • contribs) 11:47, 24 March 2019 (UTC)