Wikipedia talk:Manual of Style/Lists

WikiProject list discussion

There is a discussion at the WP:FRAT talk page about list creation/inclusion which could use outside input. Please join in the conversation here. Primefac (talk) 10:45, 9 May 2023 (UTC)

This seems to have pretty quickly archived to Wikipedia talk:WikiProject Fraternities and Sororities/Archive 9#Including list of fraternity/sorority founders., without a clear resolution. But there have been later follow-up discussions about lists there.  — SMcCandlish ☏ ¢ 😼  03:15, 14 November 2023 (UTC)

Bullet-space, or not bullet-space, that is the question

I work on a lot of disambiguation pages and name lists and alumni lists, which sometimes involves copying lines from, for example, a given name page to a surname page, or from a name page to an alumni list. These are typically bulleted lists, which may either be formatted as:

*Foo
*Bar
*Foobar

or:

* Foo
* Bar
* Foobar

The outcome is the same, so I am wondering if there is any technical reason who one should be preferred over the other. Frankly, I would prefer to have a set house style and conform pages to it generally. It is annoying to copy lines to multiple relevant lists and to have to edit that space every time to conform to the variations of individual pages. BD2412 T 21:54, 7 July 2023 (UTC)

Every time you use a bulleted list without the space, a fairy dies. Your choice of course — GhostInTheMachine ^{talk to me} 22:42, 7 July 2023 (UTC)

@GhostInTheMachine: I'm fine with having the space if someone can explain to me what purpose it serves. Is it just to make it easier to parse the wikitext? Should we have a preference expressed in the MOS? BD2412 T 00:40, 8 July 2023 (UTC)

The parser does not care about the space – you could have no space or five spaces and the HTML created by the parser is exactly the same. It is just an aesthetic thing and a kindness to the next editor – having a space after the asterisk helps visually when you are editing the source. Maybe the MOS could say something about that, but I don't see it as being important enough to be stated as policy — GhostInTheMachine ^{talk to me} 08:40, 8 July 2023 (UTC)

There is no technical reason to prefer one over the other. The difference is only when editing using the source editor, and even then it is purely aesthetic. If you are coming across people who are routinely adding spaces where there were none before (or removing them), that is the sort of thing that WP:COSMETICBOT and WP:AWBRULES rule 4 both discourage. --Redrose64 🌹 (talk) 09:53, 8 July 2023 (UTC)

Maybe we could compromise and use halfspaces? Eg

* Foo
* Bar
* Foobar

--Herostratus (talk) 11:32, 8 July 2023 (UTC)

Now that certainly would make a difference to the rendered output. But why would we want to do it anyway? --Redrose64 🌹 (talk) 12:20, 8 July 2023 (UTC)

I just want consistency. If there is no reason to have the spaces, then eliminate them (they do affect the page size, which theoretically affects loading time). If there is a reason to have them, such as improved readability while editing, then require them. BD2412 T 20:27, 14 July 2023 (UTC)

You won't get consistency. First, there is no reason to either eliminate or to require them; second, most people simply won't care; and third, the sheer number of pages presently using (i) spaces; (ii) no spaces; (iii) either one indiscriminately means that the amount of work necessary to harmonise two-thirds of pages to match the other third would simply not be worth the bother. Remember that every edit creates a new version of a page and all old versions are preserved, so editing a 10,000-byte page to remove ten spaces doesn't decrease the database size by 10 bytes, it increases it by 9990 bytes for the page text, plus all the entries in the revision and link tables. Any intended net saving of space is always a net loss of space.

The spaces after the asterisks only affect the page size when opening the page or section for editing, and the contents of the edit window form a surprisingly small amount of the data that is served to your browser when you do that. So the addition or removal of a few spaces won't make any measurable difference. When you save the edit, as GhostInTheMachine pointed out, the HTML created by the parser is exactly the same - here is the HTML from your original two examples:

<ul><li>Foo</li>
<li>Bar</li>
<li>Foobar</li></ul>

and

<ul><li>Foo</li>
<li>Bar</li>
<li>Foobar</li></ul>

the spaces simply do not appear. --Redrose64 🌹 (talk) 14:20, 15 July 2023 (UTC)

"Is it just to make it easier to parse the wikitext?" Yes. Some editors prefer it, and that's the only reason, but it's not a compelling reason to change the style. "Should we have a preference expressed in the MOS?" No, for WP:MOSBLOAT reasons, and more in particular because people have repeatedly proposed this and several other forms of "coding standards" (like ==Foo== versus == Foo ==) be worked into MoS, and the result is always a consensus against the idea, because MoS exists for ensuring quality and consistent and understandable content for the readers (and secondarily for reducing editorial conflicts about styling that content), but this sort of thing isn't styling the content, having no effect on what editors see, or any accessibility effect on editors or readers, possibly the only other reason we'd care about a code-formatting matter. There's just not a consensus to prefer one style over the other. To the extent anything in MoS would apply to this stuff, it would be MOS:STYLEVAR: if there are two acceptable styles, don't arbitrarily change from one to the other. For my part, when I encounter messy lists, I normalize to which ever style already dominates in the page. If there is no clear "winner", and just a really random mess, I usually normalize to the spaced style as marginally more readable for editors. But only if making a more substantial improvement in the same edit.  — SMcCandlish ☏ ¢ 😼  03:12, 14 November 2023 (UTC)

It's to make the wikitext more human-readable. The software parser doesn't care.

Eventually, it will get mostly standardized as whatever the visual editor is doing, which is (presently, but, if memory serves, not originally) adding a space. WhatamIdoing (talk) 07:14, 9 January 2024 (UTC)

Single reference for every list item

Here is a humdrum example of a common phenomenon: A list ("Festivals") with a single reference ("^[4]") atop, and presumably for, all the items. Let's avoid what's irrelevant to the question I'm about to pose, and instead assume that the referenced source is reliable, and that it does indeed back up the appropriateness of each list item. A reference index floating by itself looks wrong (to me). An obvious alternative is to repeat the (named) reference for every list item; easily done, of course but the result would look lame-brained (to me). Another obvious (but worse) alternative would be to append the reference to the last item; but then it would be unclear whether this reference was supplied for the list as a whole or merely for its last item. And one could supply an introductory sentence ("According to Taiwan Docs,^[4] the film has been shown in the following festivals:"), but this adds flab. Is there a better way of referencing an entire list? -- Hoary (talk) 01:23, 14 November 2023 (UTC)

For most lists (any that could be subject to changes in entries), repeat the ref for every list item, no matter how "lame-brained" you think it looks; this isn't VisualDesignPedia. Use shorthand <ref name="foo" /> format or {{sfn}} or some other shorthand for entries after the first one; obviously don't repeat the entire citation over and over again. Every list item should be sourceable, various of them will accrete additional citations over time, and more people will add new entries with (we certainly hope) other citations to back them up. The exception would be when it's a list of a permanently fixed number of things that do not change (e.g. already-complete list of presidents of a company that no longer exists). In such a case, have an intro sentence/phrase above the list with a single citation at the end of that sentence/phrase.  — SMcCandlish ☏ ¢ 😼  01:44, 14 November 2023 (UTC)

Thank you, SMcCandlish. Well, even aside from its commendable adaptability, that's clearly preferable to this approach. -- Hoary (talk) 02:00, 14 November 2023 (UTC)

Yeah, that's no bueno, since we don't put templates and other complex code inside headings.  — SMcCandlish ☏ ¢ 😼  02:59, 14 November 2023 (UTC)

You name the atrocity, I've probably perpetrated it in my time. -- Hoary (talk) 04:37, 14 November 2023 (UTC)

Oh, sure. Been here since something like 2005, and probably broken everything at some point. I even had templates in my sig at first, despite that being a big no-no I hadn't read about yet. Heh.  — SMcCandlish ☏ ¢ 😼  06:17, 14 November 2023 (UTC)

single-item lists

The template {{infobox cocktail}} automatically forces a bulleted list for its main-alcohol parameters. Bulleted lists in infoboxes aren't unheard-of, though rare. However, that template forces a bullet even for single entrants, making the oxymoronic single-item list. Given there is no actual list created, should that template be invoking list markup for single variables? — Fourthords | =Λ= | 22:27, 29 December 2023 (UTC)

What do you mean specifically? Can you point to an usage of the template where this is visible? Gawaon (talk) 04:39, 30 December 2023 (UTC)

Sure, easy-peasy. In the infobox's implementation at mojito, there's a bulleted list with one item (rum). Given how the bulleted-list markup interacts with other variables like scrapers, screen readers, and more, are there any technical, grammatical, accessibility, or stylistic problems caused by a 'list' that then only has one entrant? — Fourthords | =Λ= | 06:00, 30 December 2023 (UTC)

Yeah, I agree that looks odd. I'd say it should just be a plain wikilink in such a case, not a list. But ultimately you'll have to discuss that with the template authors. Gawaon (talk) 06:18, 30 December 2023 (UTC)

Fixing that is a simple #if test to check for multiple parameter values. And it should probably use an unbulleted list, since bulleted ones are unusual in infoboxes and waste space in them. The more general ingredients list lower in the i'box might sensibly use a bullet list, but it could be CSS kerned to waste less horizontal space.  — SMcCandlish ☏ ¢ 😼  00:28, 3 January 2024 (UTC)

A "bullet" (i.e., Unordered) list with no bullet at all would be better, as the list of recipe ingredients would look like a list of recipe ingredients. Try Template:Plainlist. WhatamIdoing (talk) 07:21, 9 January 2024 (UTC)

Made that recommendation in the template documentation. We'll see if it sticks.  — SMcCandlish ☏ ¢ 😼  10:30, 9 January 2024 (UTC)

Discussion at Wikipedia talk:WikiProject Lists § Should Template:Dynamic list be used in sections that also have Template:Main?

 You are invited to join the discussion at Wikipedia talk:WikiProject Lists § Should Template:Dynamic list be used in sections that also have Template:Main?. {{u|Sdkb}} ^talk 21:32, 2 January 2024 (UTC)

comparison articles

Many Wikipedia articles have a title that begins with "Comparison of ...". Is there a Wikipedia policy or guideline that specifically discusses such comparison articles? I hoped to find such a discussion when I went to WP:Comparison, but that currently redirects to Wikipedia:Manual of Style/Lists, which only mentions the word "comparison" once, and even then it's not referring to comparison articles.

Is there perhaps some other Wikipedia policy or guideline that WP:Comparison *should* redirect to? DavidCary (talk) 17:21, 4 May 2024 (UTC)

Who is doing the comparing - you or your sources? If it's you, then you possibly fall foul of WP:NOR and/or WP:SYNTH. --Redrose64 🌹 (talk) 17:37, 4 May 2024 (UTC)