Wikipedia talk:Manual of Style/Lists
This is the talk page for discussing improvements to the Manual of Style/Lists page. |
|
Archives: 1, 2, 3, 4, 5, 6, 7, 8Auto-archiving period: 60 days |
This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
Bullet-space, or not bullet-space, that is the question
[edit]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 --Herostratus (talk) 11:32, 8 July 2023 (UTC)
* Foo * Bar * Foobar
- 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)
- Maybe we could compromise and use halfspaces? Eg
- @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)
- 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: 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)<ul><li>Foo</li> <li>Bar</li> <li>Foobar</li></ul>
- "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-item lists
[edit]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)
- 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)
- 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)
- 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)
Discussion at Wikipedia talk:WikiProject Lists § Should Template:Dynamic list be used in sections that also have Template:Main?
[edit]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
[edit]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)
- Redrose64, that sounds like good advice that *should* be in a Wikipedia policy or guideline that discusses comparison articles -- and perhaps already is. Similarly, I think I've read somewhere that: comparison articles should cite sources that actually compare things, and if no such sources can be found, then a stand-alone "comparison article" likely doesn't meet Wikipedia's Wikipedia:Notability guideline (but the same information may be OK as a subsection of the topic article).
- Alas, I've been unable remember where I read that, hence the original question.
- To answer your literal question: I'm often editing articles in the Category:Software comparisons category, which generally *do* already have sources doing the comparing.
- --DavidCary (talk) 05:56, 13 May 2024 (UTC)
Are these proper MOS:PSEUDOHEAD / MOS:DEFLIST edits?
[edit]Ost316 is making many edits like this one, claiming that bold headers are a MOS-related improvement over semicolon and asterisk markup. The semicolon markup appears to me to conform with MOS:DEFLIST's description of name-value or topic-value pairs, but I will defer to the experts here. The editor appears to have made hundreds of these edits. – Jonesey95 (talk) 00:04, 22 August 2024 (UTC)
- This seems like a pretty core use-case of definition lists. Remsense ‥ 论 00:33, 22 August 2024 (UTC)
- A definition list (MOS:DEFLIST) is a ; line followed by one or more : lines, not by * list items. So Ost316 is certainly right that the old syntax they are fixing is not proper deflist syntax and likely produces invalid HTML. Gawaon (talk) 06:17, 22 August 2024 (UTC)
- Right, of course. How is one meant to mix the two again, just open a
{{blist}}
after the:
? Remsense ‥ 论 06:36, 22 August 2024 (UTC)- I have never tried, but I suppose that would work. Gawaon (talk) 07:37, 22 August 2024 (UTC)
- There are nonzero infobox situations where I'd just like to separate a bulleted list with headers thusly, even after slimming it down as appropriate. Unno. Remsense ‥ 论 07:41, 22 August 2024 (UTC)
- In that case, just using bold markup around the header line, like Ost316 does it, doesn't seem the worst solution. Gawaon (talk) 08:12, 22 August 2024 (UTC)
- Thanks for the responses. I searched the MOS:PSEUDOHEAD page for "semicolon", which I should have done earlier, and I found this explicit guidance, which says not to put * after ; markup. – Jonesey95 (talk) 14:15, 22 August 2024 (UTC)
- So I've just done a rudimentary bit of brainstorming, and I quickly realized this is a really easy—seemingly not previously addressed—itch to scratch. Behold,
{{Bulleted dl}}
: - Labor unions
- Communications Workers of America District 1 and Local 1126
- New York State AFL–CIO
- Newspapers
- The Post-Standard
- So I've just done a rudimentary bit of brainstorming, and I quickly realized this is a really easy—seemingly not previously addressed—itch to scratch. Behold,
- Thanks for the responses. I searched the MOS:PSEUDOHEAD page for "semicolon", which I should have done earlier, and I found this explicit guidance, which says not to put * after ; markup. – Jonesey95 (talk) 14:15, 22 August 2024 (UTC)
- In that case, just using bold markup around the header line, like Ost316 does it, doesn't seem the worst solution. Gawaon (talk) 08:12, 22 August 2024 (UTC)
- There are nonzero infobox situations where I'd just like to separate a bulleted list with headers thusly, even after slimming it down as appropriate. Unno. Remsense ‥ 论 07:41, 22 August 2024 (UTC)
- I have never tried, but I suppose that would work. Gawaon (talk) 07:37, 22 August 2024 (UTC)
- Right, of course. How is one meant to mix the two again, just open a
Remsense ‥ 论 20:54, 22 August 2024 (UTC)
You are invited to join the discussion at List of genocides § List ordering: Reverse or regular chronology. —Alalch E. 00:50, 30 August 2024 (UTC)
List formatting at Conversations about Important Things#List of Important Conversations lessons
[edit]Due to Conversations about Important Things entering its third year, I am exploring the idea of converting the list of topics from a table to a list, because most of the entries do not have a description. I wish to ask what format could I employ, taking into account the use of colons, dashes, and parentheses in the topic names? --Minoa (talk) 17:33, 2 September 2024 (UTC)