Template talk:Hlist

class=inline not working outside demo

Using |class=inline works on the doc page, but doesn't in real life. The difference is whether {{markup}} is used - compare

Markup	Renders as
Giant planets ({{hlist|class=inline|[[Jupiter|J]]|[[Saturn|S]]|[[Uranus|U]]|[[Neptune|N]]}}).	Giant planets ( J S U N ).

with

Giant planets ({{hlist|class=inline|[[Jupiter|J]]|[[Saturn|S]]|[[Uranus|U]]|[[Neptune|N]]}}).

Giant planets (

• J
• S
• U
• N

).

--Redrose64 🌹 (talk) 14:21, 3 February 2024 (UTC)

Got it. You need to wrap the whole line in a block element ({{markup}} uses <td>...</td>) in order to "kill" the implicit <p>...</p>, such as:

Giant planets (

• J
• S
• U
• N

).

It's not optimal. --Redrose64 🌹 (talk) 16:04, 3 February 2024 (UTC)

Shouldn't the documentation mention the work-around unless and until it is fixed? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:05, 30 April 2025 (UTC)

I've been trying and wondering why it doesn't work, having checked the documentation & played in the sandbox and everything. Came here to report it, and I'm not the only one. Yeah, it should be added to the documentation, it would've saved me time. Slovborg (talk) 21:01, 14 February 2026 (UTC)

Template for list of alternatives?

Is there a template for creating a list of alternatives separated by the Or ("pipe") character, e.g., {{alternatives|foo|bar|baz}} rendering as [[foo|bar|baz]] or {{foo|bar|baz}}? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:55, 4 November 2025 (UTC)

I'm confused by what you mean with the [[]] and {{}} notations. Are you saying it should output uninterpreted wikitext along the lines of {{template}}? Arlo James Barnes 04:48, 11 January 2026 (UTC)

hlist: non-breaking space before •

In Template:Hlist/styles.css on line 74 (content: " · ";), I would like to request that the space before the ‘·’ be changed to a non-breaking space, for a more consistent look in which word-wrapped horizontal lists don't end up with some lines ending in a dot and some beginning with one. That is the traditional behaviour from back when we faked horizontal lists using {{·}} or {{•}}; those templates start with a non-breaking space, and I see no reason why it shouldn't carry over to hlist. (Note, though, that a HTML entity like   won't work in CSS, so it needs to be a literal non-breaking space: “ ” \a0, as recommended below.) – McDutchie (talk) 05:55, 2 January 2026 (UTC)

No, it needn't (and shouldn't) be. You can use the value \a0 as used in these two rules:

.hlist ol > li::before {
	content: " " counter(listitem) "\a0";
}

.hlist dd ol > li:first-child::before,
.hlist dt ol > li:first-child::before,
.hlist li ol > li:first-child::before {
	content: " (" counter(listitem) "\a0";
}

that is to say

.hlist dd::after,
.hlist li::after {
	content: "\a0· ";
	font-weight: bold;
}

--Redrose64 🦌 (talk) 13:25, 2 January 2026 (UTC)

Thank you for that. Edited. – McDutchie (talk) 16:01, 2 January 2026 (UTC)

 Done * Pppery * _{it has begun...} 00:36, 6 January 2026 (UTC)

param for alternate separator

Some of the threads above get at this topic, but instead of doing it with the style parameter, couldn't it be supplied with a dedicated param? Arlo James Barnes 04:53, 11 January 2026 (UTC)

Requested move 3 August 2026

• Template:Hlist → Template:Horizontal listTemplate:Horizontal list
• Template:Flatlist → Template:Flat listTemplate:Flat list
• Template:Plainlist → Template:Plain listTemplate:Plain list
• Template:Columns-list → Template:Columns listTemplate:Columns list
• Template:Pagelist → Template:Page listTemplate:Page list
• Template:Br separated entries → Template:Br-separated listTemplate:Br-separated list
• Template:Nbsp separated entries → Template:Nbsp-separated listTemplate:Nbsp-separated list
• Template:Comma separated entries → Template:Comma-separated entriesTemplate:Comma-separated entries
• Template:Space separated entries → Template:Space-separated listTemplate:Space-separated list

– These templates are a holdout to the general trend towards expanding template names for clarity per Wikipedia:Template namespace § Template names:

Template names should be made of one or more words, and describe the template clearly, as in {{Math topics sidebar}}. Template names are easiest to remember if they follow standard English spelling, spacing, and capitalization. Avoid having templates whose names differ only in case, spacing, or punctuation.

Several sibling templates already follow this guidance and can be used as a model for what these should look like, for consistency: {{Bulleted list}}, {{Unbulleted list}}, {{unbulleted indent list}}, {{Ordered list}}, {{Horizontal ordered list}}, {{Indented plain list}}, {{Comma-separated list}}, {{Unbulleted grid list}}, {{Bulleted grid list}}, {{Tree list}}, {{Arrow list}}, {{Flowing list}}, {{Category list}} all use plain, spaced-out English names that describe exactly what the template does. There's no reason the remaining list templates, which do more or less the same kind of job, should stay behind as compressed or punctuation-only variants of the same idea. Most of the templates i nominated are just two ordinary words jammed together, which the current title, per the point about spacing above, discourages, and {{Columns-list}} mixes a hyphen into a two-word name for no reason.

I've also fixed the names so they comply with the MOS:HYPHEN guideline, which, while it doesn't strictly apply to templates, indicates the only grammatically correct way to name these templates.

Of course, the old titles will all still remain as redirects, so people can keep using them as shortcuts. FaviFake (talk) 09:13, 3 August 2026 (UTC) — Relisted. P.I. Ellsworth , ed. – welcome! – 13:33, 10 August 2026 (UTC)

Update 11:58, 10 August 2026 (UTC): I've updated the original proposal to change three lists named "... entries" to "... list". FaviFake (talk) 11:58, 10 August 2026 (UTC)

• Mostly support. I'd prefer "Br-separated entries" and "Nbsp-separated entries" though:
  • "Br-separated" is shorter, but more importantly it's clearer / more precise. When I read "line break", I think of a Unicode newline. Of course, that wouldn't make sense, because whitespace has little effect in HTML and Wikitext, but "Br-separated" makes it clear that it's an HTML <br/> tag.
  • "Nbsp-separated entries" is shorter. "Non-breaking space-separated entries" is awfully long and requires endash or emdash if we want to satisfy the MOS.

— Chrisahn (talk) 12:56, 3 August 2026 (UTC)

• Mildly support some: Ignore the first five, change the four lists named "... entries" to be lists named "... list", also with a redirect for a shorter version:
  • {{Nbsp separated entries}} → {{nbsp list}} → {{nbsp-separated list}}
  • {{Br separated entries}} → {{br list}} → {{br-separated list}}
  • {{Comma separated entries}} → {{comma list}} → {{comma-separated list}}
  • {{Space separated entries}} → {{space list}} → {{space-separated list}}

— Preceding unsigned comment added by GhostInTheMachine (talk • contribs) 13:28, 3 August 2026 (UTC)

change lists named "... entries" to be lists named "... list",
That wouldn't work for every template. For example, a different template called {{Comma-separated list}} already exists, for some reason...?

Given your comment and Chrisahn's, I have amended my proposal in favour of "Br-separated entries" and "Nbsp-separated entries". What do you think? ​ FaviFake (talk) 17:19, 3 August 2026 (UTC)

The original thread at Template talk:Br separated entries of why it is named "entries" and not "list" is pretty funny and so wikipedia. Frietjes (talk) 19:07, 4 August 2026 (UTC)

If we have two different templates designed to create a list with commas, then they should just be merged so that we do have: {{Comma separated entries}} → {{comma list}} → {{comma-separated list}} — GhostInTheMachine ^{talk to me} 11:53, 10 August 2026 (UTC)

I agree. I think the best solution would be to rename the second template as "Comma-separated entries" as proposed (or not rename it at all), and then after the RM closes start a TfD to figure out the details of the merge.

I've updated the original proposal to change the three remaining lists named "... entries" to "... list". FaviFake (talk) 11:56, 10 August 2026 (UTC)

Modifying the original proposal invalidates the discussion and votes. I suggest that this be closed and you possibly create a new proposal with a smaller scope — GhostInTheMachine ^{talk to me} 12:03, 10 August 2026 (UTC)

• Oppose hlist and plainlist given they have TemplateStyles pages that are widely used (and actually called with their names). That's makework to move those. No comment on the others. Izno (talk) 17:09, 3 August 2026 (UTC)

  You can just create a duplicate TemplateStyles page that's identical to the old name, rename the template, and then redirect the old TemplateStyles to the new copy. I do this routinely. Am I missing something? FaviFake (talk) 17:21, 3 August 2026 (UTC)

  These templatestyles pages are transcluded on millions of pages. You haven't edited anything remotely that widely transcluded. There's also the followup work of history merging the pages, which you forgot entirely. Yes, you are missing a few things. Izno (talk) 17:32, 3 August 2026 (UTC)

  Sure, but my point is that this process shouldn't take more than a minute or two, and has the benefit of making the template clearer to the hundreds of editors viewing them every week FaviFake (talk) 17:39, 3 August 2026 (UTC)

  No, it takes the thousands of minutes for every transclusion to update. Which is wasted processing power among other things (inconsistencies in pages, etc). For a name change that from what I can see has no significant reason to occur. Especially when we already have redirects in place.

  As I said, this is makework. Izno (talk) 17:41, 3 August 2026 (UTC)

  every transclusion to update
  That only needs to happen once, so WP:DWAP

  inconsistencies in pages
  You mean editors using a bog-standard template shortcut?

  no significant reason to occur
  It clearly violates the template guidelines, as I explained in my nomination. If you disagree with the guideline then you should try to change it, not avoid enforcing it. FaviFake (talk) 19:19, 3 August 2026 (UTC)

  You mean editors using a bog-standard template shortcut? No. Transclusions will need to update to use the new page rather than the old, and this can lead to inconsistencies in the pages in which they're used.

  If you disagree with the guideline then you should try to change it, not avoid enforcing it. Do I need to quote what's in the {{guideline}}? I do not in this case disagree with the guideline. I do disagree that it is the preferred guideline in this case compared to the other issues that arise with moving these pages. For no reason other than that guideline.

  I'll be disengaging from any responses you make now. I've got better things to do and you appear to be convinced this is a good decision to take. Izno (talk) 19:24, 3 August 2026 (UTC)

  (We have, many times in the past, said it was more important to have a stable template than it was for it to be named perfectly. If you don't know of such cases, that's fine, but it's not a new question to me that we will sometimes decide about a template's name different than what a guideline supposes it be called.) Izno (talk) 19:27, 3 August 2026 (UTC)

  I was referring to Template names should be made of one or more words [...], but sure. We agree to disagree. FaviFake (talk) 19:30, 3 August 2026 (UTC)

Support moving hlist, flatlist, and plainlist, as the ones I'm most familiar with; neutral on the others. Mr. Starfleet Command (talk) 01:36, 4 August 2026 (UTC)

Support. Someone's finally gone and done it. I was just thinking about this the other day lol. Axolitl (talk | contribs) 02:22, 4 August 2026 (UTC)

Oppose moving "entries" to "list" because it serves a necessary distinction. The entries are not lists, they are just items put together. This is in contrast to, for example, {{Comma-separated list}}, which uses html list item tags to properly format them for accessibility. {{Comma-separated entries}} does not do this, and would turn {{Comma-separated entries|Item 1|item 2|item 3}} into literally just Item 1, item 2, item 3, rather than a properly formatted html list. Axolitl (talk | contribs) 18:00, 10 August 2026 (UTC)

Huh, that's interesting, I didn't know there was a technical difference. Can you confirm this distinction also applies to the other 3 "... entries" templates, and that the rest of the templates named "... list" are all actual HTML lists? ​ FaviFake (talk) 18:04, 10 August 2026 (UTC)

I know this is the case for {{Comma separated entries}}, {{Br separated entries}}, {{Nbsp separated entries}}, and {{Space separated entries}}. I think all of the list templates use proper HTML formatting (I know for a fact that the high-use ones like {{ublist}}, {{hlist}}, {{plainlist}}, etc. do) but I'm not 100% sure. Axolitl (talk | contribs) 18:11, 10 August 2026 (UTC)

•  Relist note:  the original proposal has been altered, so involved editors need time to respond to those changes. P.I. Ellsworth , ed. – welcome! – 13:33, 10 August 2026 (UTC)

Ok I can see changing entries to lists and having the new shotcuts but im confused on why we need to hyphenate everthing. Why is this necessary? Can't we just use "Nbsp separated list" or "nbsp list" rather than forcing the abbreviation or first word in a three or more worded template name to a 2 worded template name? I mean the MOS:Dash doesnt actually state that it needs to be used for Templates and neither does the Wikipedia:Template namespace & Template names states that template names that it can have 1 OR more words/abbrviations for the template name. Both the Wikipedia:Template namespace & Template names AND MOS:Dash are not required to combine. To me it just seems like you dont like three letter named templates. I mean if you plan on doing this i have to image you want to change the others like "unbulleted grid list" -> "unbulleted-gird list". See it doesnt make sense. plus it makes it harder to edit on mobile (I do both desktop and mobile edits). I think you are trying to force something into so called compliance when it in the first place needs to be editing to be "in compliance". idk how to state that mos:dash and the template names rules dont mandate that they must be followed together... its not i need to do force every three letter template name into the dash format. the dash format says that it DOESNT HAVE to be followed all the time. To my understanding it is like a general guideline but not a hard and fast rule like it is for other subjects to the mos dash. i think the the word im thining of is inclusive/exculusive. GamerDeltaUS (talk) 13:40, 10 August 2026 (UTC)

*note that im not used to this whole comments formating so sorry for missing a lot of the proper formating of the above response.. GamerDeltaUS (talk) 13:41, 10 August 2026 (UTC)

Four-year-old children

Four year-old children

Four-year old children

A man eating fish

A man-eating fish

Officials help dog-bite victim.

Officials help dog bite victim.

Why is this necessary? Can't we just use "Nbsp separated list" or "nbsp list"
No, that's grammatically incorrect per every Manual of Style you will find, including Wikipedia's.

I mean the MOS:Dash
My proposal suggested adding hyphens, not dashes, so MOS:HYPHEN (point 3) applies here, not MOS:Dash.

I mean if you plan on doing this i have to image you want to change the others like "unbulleted grid list" -> "unbulleted-gird list". See it doesnt make sense.
Nope, that would be incorrect per the same MOS:HYPHEN guideline.

plus it makes it harder to edit on mobile (I do both desktop and mobile edits).
In what way? These templates cannot be edited by non–template editors and you can still use the old name when adding it to articles.

its not i need to do force every three letter template name into the dash format. the dash format says that it DOESNT HAVE to be followed all the time.
Again, these are hyphens, not dashes. Here's a hyphen: -. Here's a dash: —. Dashes are longer. FaviFake (talk) 13:51, 10 August 2026 (UTC)