This template is within the scope of WikiProject Infoboxes, a collaborative effort to improve the coverage of Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InfoboxesWikipedia:WikiProject InfoboxesTemplate:WikiProject InfoboxesInfoboxes
This template is within the scope of WikiProject Elections and Referendums, an ongoing effort to improve the quality of, expand upon and create new articles relating to elections, electoral reform and other aspects of democratic decision-making. For more information, visit our project page.Elections and ReferendumsWikipedia:WikiProject Elections and ReferendumsTemplate:WikiProject Elections and ReferendumsElections and Referendums
Got to be a way of fixing the text sandwiching because of massive width. We have thousands of pages that are an accessibility nightmare at 800px. We should ensure infoboxes are sized correctly so they don't push text unnecessarily so those with visual problems can still read the lead prose text. Moxy🍁07:56, 17 April 2025 (UTC)[reply]
Please link to at least one page as an example. When I go to 1996 United States presidential election and shrink my window to 800px wide (are we really worried about 800px windows in 2025?), the sidebars disappear and I get "Presidential elections were held in" as the first line of prose. The column is narrow, but that is exactly what I would expect at 800px wide. I don't see any sandwiching, because there is nothing on the left. I don't see the word "width" at Wikipedia:Manual of Style/Accessibility; what exactly is inaccessible about a narrow column of prose? – Jonesey95 (talk) 14:33, 19 April 2025 (UTC)[reply]
The sandwiching of text can occur because an image or in this case the info box is too large it doesn't need to be in between two things. Narrow columns of text can hinder accessibility by making it difficult for individuals with reading or vision disabilities to track the text and follow the flow of information. We should also avoid using narrow columns of content because they will not respond well to scaling. MOS:RESOLMoxy🍁15:16, 19 April 2025 (UTC)[reply]
The screen shot to the right does not make sense to me. It appears that the app being used, or something in the user's preferences, has greatly enlarged the body text while keeping the infobox text, which is supposed to render at 88% of the body text size, extremely small. Wikipedia's normal text-sizing settings are not designed for that sort of modification; there is no way to please everyone, especially people who customize in this way. The screen shot also shows a portrait-mode view of an article, which is clearly not the way to look at an article using this sort of enlarged text; any infobox or lead image would cause the same sort of problem, not just this infobox. What happens when you use a more reasonable landscape mode for viewing the article? – Jonesey95 (talk) 17:20, 19 April 2025 (UTC)[reply]
All will see it a bit different (like all elements) for some it wont be too bad for others it will be even worst then what is being presented here. Looking for solutions that will help all. I suggest looking at all platforms mobile and non mobile views to see what others see. Moxy🍁17:25, 19 April 2025 (UTC)[reply]
Agreed, but the text size disparity does not make sense to me. I think the image sizes are a problem, however, and have tried to address them below. – Jonesey95 (talk) 17:59, 19 April 2025 (UTC)[reply]
If you want to fix this issue, you will need to limit the size of the maps allowed (or by removing the option to set map widths). The template currently sets its width to the largest of the maps inside it, which is apparently around 500px for about 20 templates. Another thousand set it to 400-499. The remainder of the 34k uses of this template are less than that, with a default of 300px.
If that is not an appropriate solution, there is largely nothing that can be done. Some pages just aren't going to look good when we have the variety of templates we have. The best one might be able to offer would be to adjust when this template goes to full width, but it is unlikely there would be consensus for a number so large as 800. Izno (talk) 15:42, 19 April 2025 (UTC)[reply]
I see we say "The lead image in an infobox should not impinge on the default size of the infobox. Therefore, it should be no wider than upright=1.35 (equivalent to 300px...." We could also remove the side text beside the images place it in a better location perhaps to reduce the width? Moxy🍁15:46, 19 April 2025 (UTC)[reply]
|upright=1.35 is equivalent to 300px only when the user is logged in and also has 220px set as their preferred thumbnail size. For those people who are logged out, a recent change to the default thumbnail size, to 250px, means that the equivalent of 300px is now |upright=1.2 - if |upright=1.35 continues to be used, the effective width will be 340px. See m:Tech/News/2025/16 (currently posted at Wikipedia:Village pump (technical)#Tech News: 2025-16 and some user talk pages). --Redrose64 🌹 (talk) 16:27, 19 April 2025 (UTC)[reply]
I don't think the map is the problem at 2025 Canadian federal election. That map was 400px wide, but the infobox (I just edited the template to limit the map size to 300px wide, per the guideline), at least logged out on my screen, is 485px wide (in the screen shot, you can see white space on either side of the map).
Moxy may be noticing a result of the recent default thumbnail size increase. The three images of candidates at the top of the infobox are about 125px wide, which corresponds to upright=0.5, the default setting at {{Infobox election/row}} when there are three images. I changed that setting to 0.4 for three images and 0.6 for two images, which should limit the three images (or two images, if there are only two) to 300px wide, per the guideline. That change is not working for me, so there may be something else going on. I think limiting the width of the three candidates' images is needed to help this infobox comply with WP:IMGSIZELEAD. Coding help is welcome. – Jonesey95 (talk) 17:59, 19 April 2025 (UTC)[reply]
Follow-up: I went down the wrong rabbit hole with this one. That article and others use {{CSS image crop}} with a fixed image width to show candidate images. The change in the upright setting won't affect them, as far as I can tell. That template uses fixed pixel sizes, which will determine the width of the infobox. With three 120px images side-by-side and some heading text to the left, it's easy to end up with an infobox width of 460 to 490px. If WP:IMGSIZELEAD is to be followed here, someone would have to (with consensus) adjust all of the photos in these infoboxes to use fixed pixel widths of 100px or less. At least that's my conclusion after spending too much time digging into this issue. – Jonesey95 (talk) 18:25, 19 April 2025 (UTC)[reply]
Smaller candidate image sizes when there are three or more candidates
I have made a change in the sandbox to display the candidate images at a smaller size when there are three or more candidates. You can see the results at Template:Infobox election/testcases. As an example, on my screen, this 1997 election infobox goes from 490px wide to 390px wide. I believe that this change complies with the spirit of WP:IMGSIZELEAD, which suggests limiting lead images to 300px wide. The combined width of the three images is limited to 330px at the most, and usually renders at less than 300px.
I expect that this change may be controversial, since it significantly shrinks the size of many candidate images. I have not moved the code to the main template. We should probably seek wider comment if we wish to make this change.
I support this change. Ideally I'd also like to see the documentation updated to state that the image sizes should match the default to avoid situations where people are using css cropping and forcing much larger sizes. In the longer-term, a better solution would be to adopt the infobox style used on other languages (like es and fr) where candidates/parties are listed vertically, rather than horizontally and vertically – this would ensure a fixed width regardless of the number of candidates, and also avoid the situation that arises when there are 5/7/8 candidates in an infobox, resulting in empty spaces. Number5719:19, 19 April 2025 (UTC)[reply]
Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. There is no concrete edit request here, so I am deactivating the request. Discussion needs to happen about whether and how to implement whatever suggestion is being made here. – Jonesey95 (talk) 01:43, 5 May 2025 (UTC)[reply]
Adding a column parameter to make it so a new parameter does not need to be manually implemented.
See "First round," "Final round," and "Runoff" parameters on:
Again, there is no concrete "change this code to that code" request here. Any editor is welcome to edit the /sandbox version of the template to experiment with new parameters and display options. – Jonesey95 (talk) 17:02, 5 May 2025 (UTC)[reply]
Should we add a parameter for "first round" so that editors do not need to use the 1data and blank data templates? The options would be either adding just a first round parameter and leaving "Popular vote" to act as a final round, or we add both a first round and a final round parameter – whichever would make more sense. Pinging @Yoblyblob as you've raised this before DimensionalFusion (talk · she/her) 08:20, 5 June 2025 (UTC)[reply]
Showing the difference in votes between the first and final rounds is important imo. It should be a standard for the infobox. Wowzers122 (talk) 14:01, 5 June 2025 (UTC)[reply]
Should the poll parameters be depracated? Specifically, should the pollX_date, pollX_nomineeX, pollX_candidateX, pollX_source, and pollX_partyX fields be removed or depracated – reason being that I have never seen these be used in an actual article and that a search for use [1] shows that it is only used in one (1) article, and doesn't even display correctly in that article. I also think displaying polling data in the infobox may not be MOS:INFOBOXPURPOSE, but that's just my opinion. DimensionalFusion (talk · she/her) 17:41, 6 June 2025 (UTC)[reply]
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Description of suggested change: Removal of fields related to polling, as discussed above. Performed in sanbox with intended effect on Template:Infobox election/testcases#9 which is the only testcase to use the poll fields
(Last modification for now I promise!) Should the "Counties won" and "Counties with 25% vote" fields (template parameters being counties_wonX and counties_thresholdX) be removed? My reasoning is that including the number of counties won is too niche of a thing to include in the infobox, or just generally because it's unnecessary – counties won aren't like "states carried" because that's just not what counties do.
It's probably for this reason it is only used on one article, 2013 Kenyan general election and in no preceding or subsequent articles. The counterpoint to this is obviously that information that cannot be put anywhere else in an article, like the leader's seat parameter DimensionalFusion (talk · she/her) 23:31, 7 June 2025 (UTC)[reply]
It would probably make more sense to combine the parameter for counties and states won into a single parameter where you can define the name of the subdivision in question. Number5723:56, 7 June 2025 (UTC)[reply]
@Number 57 That's an interesting idea – I would think that would entail removing the counties_thresholdX parameter and renaming the counties_wonX parameter to something like subdivisions_wonX, as well as adding a subdivisions_name parameter. That would definitely allow more flexibility but I'm not sure how that would be squared with the existing states_carried functionality which would need to be retained DimensionalFusion (talk · she/her) 00:13, 8 June 2025 (UTC)[reply]
The idea is to replace them both with a subdivisions_won parameter and add a new parameter to define the subdivision. A bot could be programmed to replace all instances of states_carried with 'subdivisions_won' and 'subdivision=state' or something similar. Number5700:29, 8 June 2025 (UTC)[reply]
Whilst porting things over to a new functionality would probably be ideal, it might be better practise to retain the states_carried and just add it seperately DimensionalFusion (talk · she/her) 19:10, 10 June 2025 (UTC)[reply]
There are many pages where multiple uses of this template causes the page to exceed the post-expand include size that I've had to fix in the past few years (as I write this, 2024 United States House of Representatives elections in California is the current culprit, but I recently had an issue with 2021 New York City Council election that resulted in having to revert a lot of otherwise good content). One way to reduce the include size is to reduce nested templates. To this end, I have created Module:Infobox election, which means you can use {{#invoke:Infobox election|row}} as a drop-in replacement for {{Infobox election/row}}. I've implemented this in Template:infobox election/sandbox, all the testcases seem to produce identical results, and on average it seems to reduce the include size of the template by approximately 1/3. If there is no objection, I will go ahead and implement this in the main template.
_-_The_Noun_Project.svg?lang=en){kind=small}
Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. There is no concrete edit request here, so I am deactivating the request. Discussion needs to happen about whether and how to implement whatever suggestion is being made here. – Jonesey95 (talk) 01:43, 5 May 2025 (UTC)
Done Primefac (talk) 14:55, 7 June 2025 (UTC)