Module talk:List

Tests via template calls

Ordered not working

See Template talk:Ordered list#Not working. Very apparent on this module's documentation page. — Edokter (talk) — 13:07, 24 November 2013 (UTC)

Sorry, that was a variable clash. Should be fixed now. — Mr. Stradivarius ^{♪ talk ♪} 13:26, 24 November 2013 (UTC)

And now I've written some test cases which should catch things like this in the future. Better late than never, I suppose... — Mr. Stradivarius ^{♪ talk ♪} 14:21, 24 November 2013 (UTC)

Nice. I see some minor issues with list_style_type though. — Edokter (talk) — 14:27, 24 November 2013 (UTC)

Do you mean the Greek letters in the unbulleted table of the test cases? I can have a go at fixing that. — Mr. Stradivarius ^{♪ talk ♪} 14:36, 24 November 2013 (UTC)

Now fixed - let me know if there's anything else that you spotted. — Mr. Stradivarius ^{♪ talk ♪} 15:00, 24 November 2013 (UTC)

Seems to only fire with |ordered now, but not |bulleted. Is that by design? — Edokter (talk) — 16:32, 24 November 2013 (UTC)

@Edokter: I wasn't seeing any difference for my tests with <ul>...</ul> and list-style-type, so I assumed that it wasn't supposed to enabled for ul in MediaWiki and that there was no need to include it. But if it's supposed to be included, or we could change the backend somewhere to make it work, then it will be easy enough to enable it for bulleted lists too. — Mr. Stradivarius ^{♪ talk ♪} 10:31, 26 November 2013 (UTC)

It should basically behave as normal lists behave within MediaWiki. After some testing, I found that list-style-type indeed only works with ordered lists. Unordered lists work with the bullet image disabled (list-style-image overrides list-style-type). So it's not broken. — Edokter (talk) — 18:03, 26 November 2013 (UTC)

@Edokter: That sounds fair enough - we shouldn't be trying to second-guess the MediaWiki software, I suppose. So, just to be doubly sure, it looks like you want me to revert to this version (diff). Have I understood you correctly? — Mr. Stradivarius ^{♪ talk ♪} 01:56, 28 November 2013 (UTC)

All I can say is it behaves as expected in its current form. — Edokter (talk) — 10:50, 28 November 2013 (UTC)

Well, that sounds good enough for me. Thanks. :) — Mr. Stradivarius ^{♪ talk ♪} 11:30, 28 November 2013 (UTC)

horizontal_ordered and start value

Following a litle discussion at MediaWiki talk:Common.css#ordered list start with hlist, there is a way to specify a start value for ordered horizontal lists. My lua knowledge leaves to be desired but the solution is quite simple. When ordered and start=3 is passed, the module outputs <ol start="3">. When horizontal_ordered is given with start=3, it should (also) output <ol style="counter-reset: listitem 2;"> instead. And yes, you need to substract 1. For unknown reason, it does not work in IE8, which it should do so in theory, but who cares. — Edokter (talk) — 19:31, 6 January 2014 (UTC)

I've added it to the module, as well as switching the module to use Module:Arguments for argument processing. It's looking very nice - thank you for the fix! — Mr. Stradivarius ^{♪ talk ♪} 03:18, 7 January 2014 (UTC)

Thank you for implementing it. It works exactly as advertised. — Edokter (talk) — 11:16, 7 January 2014 (UTC)

Parameter names

Hello. For the sake of consistency with the parameter-naming pattern used in {{Navbox}}, {{Infobox}}, {{Sidebar}} etc, I've tried adding the alternate parameter names liststyle, itemstyle and itemNstyle to this version of the sandbox (current as of this message). As they seem to work, is it okay to add them to and start using them with the live version? Sardanaphalus (talk) 20:34, 31 August 2014 (UTC)

That would be the third variation of those parameter names to be allowed. This is getting a bit out of hand. This is not a user-usable template but a meta module, so I don't see the need. -- [[User:Edokter]] {{talk}} 21:04, 31 August 2014 (UTC)

• "For the sake of consistency with the parameter-naming pattern used in {{Navbox}}, {{Infobox}}, {{Sidebar}} etc...".
  If three sets of names is too many, replace/remove one (or even both) of the other two. Sardanaphalus (talk) 00:15, 1 September 2014 (UTC)

• That would surely break backward compatibility with some templates. I'm all for consistency, but that is not always possible wihtout either too many variations or breaking too many legacy templates. -- [[User:Edokter]] {{talk}} 11:40, 1 September 2014 (UTC)

• Sorry not to've got back to your reply until now. If compatibility needs to be maintained – yes – but three sets of names is too many, how about:

1. Add the more consistent set as a third set, but only temporarily while...
2. ...a bot is tasked to rename instances from one of the other sets, meaning that...
3. ...that other set may then be removed, restoring the two-set limit...?

Sardanaphalus (talk) 11:32, 8 September 2014 (UTC)

I'm not going to do it. Also, modules are not templates; perhaps it is a good thing that module parameters have a different naming scheme to prevent potential conflicts and confusion. -- [[User:Edokter]] {{talk}} 16:07, 8 September 2014 (UTC)

• In that case, can the templates that call Module:List (hlist, ublist, etc) include conversions such as liststyle → list_style, itemNstyle → itemN_style, etc? Sardanaphalus (talk) 21:45, 9 September 2014 (UTC)

Unbulleted list doesn't work in another wiki.

Hello, I copied this module to Lithuanian Wikipedia, but the unbulleted doesn't seem working properly (haven't tried others). Can someone explain why? Here is the testcases page. Any help would be appreciated.--Zygimantus (talk) 15:30, 1 October 2015 (UTC)

You need to copy some classes from MediaWiki:Common.css, most notably .hlist and .plainlist. -- [[User:Edokter]] {{talk}} 16:08, 1 October 2015 (UTC)

Thank you very much, we changed Common.css now it works.--Zygimantus (talk) 19:31, 1 October 2015 (UTC)

Redundant div?

Why is {{Unbulleted list}} generating <div class="plainlist"><ul>...</ul></div> when <ul class="plainlist">...</ul> should suffice? it seems to have something to do with renderList(data), mentioned in Module:List. Redrose64 pointed out, "as it's a module, I rather suspect that several templates use it, so one of those may need the enclosing <div>...</div>." That's likely true, but I'm wondering if there's a way to have it only generate a div when asked to. It's better to have a small bit of extra code in a module than to have unneeded markup being sent out thousands of times per minute.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:44, 5 September 2016 (UTC)

@SMcCandlish: As far as I'm aware, it's redundant. I added the extra div to the module because that's the way all the old templates were, but I don't see any other particular reason why it should be so. If we want to change it we should be careful, though - for example, there could be CSS selectors in user scripts or gadgets that depend on the div being there in the HTML. — Mr. Stradivarius ^{♪ talk ♪} 23:56, 28 February 2017 (UTC)

@Mr. Stradivarius: I don't see a practical means of "being careful" other than changing it and being willing to change it back, or otherwise work with them, if people say something broke.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:50, 3 March 2017 (UTC)

Negative numbers

Is it possible to have negative numbers with correct typographic minuses (−) instead of hyphens (-)? As I understand, the current implementation uses built-in HTML numbering, which is not aware about proper formatting (outputs −1 as "-1" and does not even understand "−1" in the value property). Can it be modified somehow (to have it still as a list rather than emulating with a table) to get the proper formatting? If not, what is the best alternative? — Mikhail Ryazanov (talk) 20:16, 28 February 2017 (UTC)

We should use semantically valid HTML. This means using the ol element to enclose one or more li elements like this:

-2. Minus Two
-1. Minus One
0. Zero
1. Plus One
2. Plus Two

What your browser does with those li elements is largely outside our control - we can specify start value - this is the start=-2 attribute here; also whether numbers (decimal or Roman) or letters are to be used (also if capitals should be used for Roman numerals or letters) - this is the type=1 attribute here. What we cannot do is specify how a minus sign is to be displayed. --Redrose64 🌹 (talk) 20:36, 28 February 2017 (UTC)

Well, yes — it seems that HTML/CSS does not give any control for how the list markers are displayed (and ::marker is not supported anywhere). Then the question is: can this be emulated using <dl> with some styling to match the <ol> format? Or I really have to use a table? — Mikhail Ryazanov (talk) 01:14, 1 March 2017 (UTC)

Again, we should use semantically valid HTML.

• The ol element represents a list of items, where the items have been intentionally ordered, such that changing the order would change the meaning of the document.
• The dl element represents an association list consisting of zero or more name-value groups (a description list).
• The table element represents data with more than one dimension, in the form of a table.

If the information is an ordered list of items, we use the the ol element, and must not use a different element for other than its intended purpose. Quite apart from appearance, we must consider accessibility.

It would help greatly if you gave an example of the page(s) where you are having these difficulties. --Redrose64 🌹 (talk) 10:19, 1 March 2017 (UTC)

I totally agree that we should strive for semantically correct and accessible code, and that is why I was asking how to achieve a typographically correct appearance while still keeping the list as a list (in this respect a description list is a general case of a numbered list). The particular example of the problem is in Absement#Higher_integrals. — Mikhail Ryazanov (talk) 23:50, 1 March 2017 (UTC)

There is a working draft for CSS to allow customisation of the negative sign in ordered lists, but unfortunately it only currently has support in Firefox. — Mr. Stradivarius ^{♪ talk ♪} 02:46, 2 March 2017 (UTC)

Looks interesting, but why even Firefox does not understand type and glyphs from the W3C draft, requiring its own system and symbols instead?

Anyway, it seems that <ol> should be considered literally ordered rather than numbered, since copy-pasting such lists completely looses the numbers in plain-text mode and loses the numbering system (just renumbers the copied items as "1.", "2.", "3.", ...) in reach-text mode (at least, this is what VisualEditor here does), so it is quite useless/harmful when the actual numbering is important. — Mikhail Ryazanov (talk) 05:30, 2 March 2017 (UTC)

The doc linked by Mr. Stradivarius is a W3C Working Draft; that means that it is a long way from being accepted as a W3C Recommendation (see World Wide Web Consortium Process Document section 6.1.2 Maturity Levels), and so browser vendors like Mozilla are under no obligation to implement any of that proposal. Indeed, it may change significantly before adoption, or even be cropped entirely and wind up as a Working Group Note.

The tag name <ol>...</ol> stands for "ordered list". It implies nothing about numbering; indeed, a list which is ordered yet not numbered might be

1. No trump
2. Spades
3. Hearts
4. Diamonds
5. Clubs

When you copypaste one or more items of a HTML list (ordered or otherwise), whether the item markers are copied or not is browser-dependent. --Redrose64 🌹 (talk) 17:32, 2 March 2017 (UTC)

Are you a mathematician? ;–)

Although the current standard does not call it "numbered" explicitly, the numbering is implied by the presence of the start attribute and that the items have ordinal values, which form a continuous sequence. (The draft from 19 October 2010 is more explicit, saying: "The start attribute on the ol element was deprecated in a previous version of HTML, but is no longer deprecated, as it has meaning and is not simply presentational.")

In any case, do you have any suggestions about the example that I gave above? — Mikhail Ryazanov (talk) 04:09, 4 March 2017 (UTC)

:after

I want to apply a style to all items (item_style), but after them. Final product should be like:

.hlist li:after{content:"-after"}

Is there some option, how to achieve this? --Dvorapa (talk) 17:43, 1 May 2017 (UTC)

bulleted list

I'd like to make a bulleted list in a table using {{bulleted list}} (or equiv result), but with a "bullet" that is smaller and/or rounder, not the standard square bullet. Such as with  • .. Is it possible to change bullet caliber? -- GreenC 01:11, 2 May 2018 (UTC)

The default bullet is set in the sitewide CSS and is not adjustable. There are also no CSS properties which will alter the size of a bullet, which is largely browser-dependent. But it is possible to replace the bullet with an image, using the list-style-image: property, and images may be drawn to any practical size. --Redrose64 🌹 (talk) 08:02, 2 May 2018 (UTC)

Would list-style-image be globally adjustable, such as in the Lua module, or only local CSS? I'm not too familiar with CSS but see data.listTag = 'ul' defined in the module. What would happen if it was changed to ul { list-style-image: url("https://commons.wikimedia.org/wiki/File:Vector-bullet-icon.svg") } (the icon image of  • ). -- GreenC 13:57, 2 May 2018 (UTC)

Nested list bug?

{{hlist|1|2|3|{{hlist|A|B|C}}}}

Expected output (approximated): 1 * 2 * 3 (A * B * C)

Real output:

• 1
• 2
• 3
• • A
  • B
  • C

Is the nested list supposed to go to a new line? This seems like unexpected behavior, especially since I thought the semantic of nesting an hlist inside another was supposed to be a *sublist*. That is, A,B,C should not have a * separator from 3. Also, should it be inserting a newline at the front of the list, too, as it is now? lethargilistic (talk) 09:12, 21 August 2018 (UTC)

Lethargilistic, note that you probably don't want the bar between the "3" and the nested list. however, that aside, if you put your example through Special:ExpandTemplates, you get

<div class="hlist hlist-separated"><ul><li>1</li><li>2</li><li>3</li><li><div class="hlist hlist-separated"><ul><li>A</li><li>B</li><li>C</li></ul></div></li></ul></div>

which has no extra new line. the issue is most likely the extra <div>...</div> inside the list. this could be potentially fixed by removing the <div>...</div> and moving the class specifiers into the <ul>...</ul>. I'm not sure why these need to be in a separate <div>...</div> container. another option could be to add "display:inline" to the div. to do this, you would want to make changes at MediaWiki:Common.css, since it would be better to put that in the hlist class directly. Frietjes (talk) 14:33, 21 August 2018 (UTC)

OK, thanks! I'll move the bug over to MediaWiki talk:Common.css. lethargilistic (talk) 21:18, 21 August 2018 (UTC)

Nested list broken

Wikitext:

{{Ordered list
|First item
|
*Second item
*is a nested list
*of multiple items}}

Expected result:

1. First item
2. • Second item
   • is a nested list
   • of multiple items

Actual result:

1. First item
2. *Second item
   • is a nested list
   • of multiple items

The module seems to cause it by removing the leading whitespace from parameters. It was broken between May and June 2014. Petr Matas 17:26, 2 September 2019 (UTC)

Petr Matas, possibly due to the refactor by Mr. Stradivarius at around that time? I put some code in the sandbox (taken from the documentation for Module:Arguments) which seems to fix the problem. Frietjes (talk) 20:19, 2 September 2019 (UTC)

Add an escaped space thus:

1. First item
2. • Second item
   • is a nested list
   • of multiple items

--Redrose64 🌹 (talk) 21:18, 2 September 2019 (UTC)

Yes, that workaround is possible. But should not we fix the bug instead? Are there any good reasons for trimming the parameters? Note that no workaround was needed before the trimming was introduced in 2014. Petr Matas 21:26, 2 September 2019 (UTC)

Frietjes, thanks for showing me where to look. Cannot we just add trim = false? Petr Matas 21:26, 2 September 2019 (UTC)

Petr Matas probably, since named parameters are automatically trimmed. Frietjes (talk) 21:27, 2 September 2019 (UTC)

On second thoughts, unlike my version, yours removes whitespace-only arguments, which is probably desired. Petr Matas 23:26, 2 September 2019 (UTC)

I have simplified your version a bit without changing its behavior. Petr Matas 08:39, 3 September 2019 (UTC)

Diff/610143502 by Mr. Stradivarius added the trimming, because it removed the valueFunc, which originally read:

		local args = getArgs(frame, {
			valueFunc = function (key, value)
				if type(key) == 'number' or value ~= '' then
					return value
				end
			end
		})

I guess that he did it to remove all blank arguments, but inadvertently introduced the trimming. Petr Matas 22:17, 2 September 2019 (UTC)

Please apply this change to fix the issue described above. It is equivalent to the change proposed by Frietjes above, but more concisely coded. Edit summary to be added: Do not trim arguments, but still remove whitespace-only arguments. Petr Matas 03:49, 8 September 2019 (UTC)

 Done DannyS712 (talk) 04:13, 8 September 2019 (UTC)

 Undone. To editor DannyS712: this edit broke {{Hlist}}, which uses this module. Needs more testing. P. I. Ellsworth, ed. ^put'r there 14:31, 8 September 2019 (UTC)

This edit also caused {{WikiProject status}} to render its list of shortcuts improperly, but I fixed the problem. {{WikiProject status}} uses {{Ombox/shortcut}}, which renders the shortcuts with {{Ubl}}. After this edit, the second to fifth <li> elements were rendered outside of the the list's <ul> element, and caused a bullet point to appear in front of them. The incorrect rendering was traced to line breaks inside {{Ubl}}, and the list renders correctly after the line breaks were removed. (I confirmed this in {{Ombox/shortcut/sandbox}} two minutes before Paine Ellsworth reverted the module edit.) — Newslinger talk 14:44, 8 September 2019 (UTC)

So, it seems like we will need something more advanced. in Module:infobox we do some context-sensitive trimming where we add newlines when the entry starts with a "*" or "#" or ":" or ";" or "{|". so, we could probably adapt the more complicated version to skip trimming when the entry starts with one of these. Frietjes (talk) 16:34, 8 September 2019 (UTC)

totally untested, but something like this. Frietjes (talk) 16:41, 8 September 2019 (UTC)

Tested with {{Hlist/sandbox}}, which invokes Module:List/sandbox, and appears to work fine, just like {{Hlist}}. P. I. Ellsworth, ed. ^put'r there 19:18, 11 September 2019 (UTC)

Also, the other templates mentioned, {{WikiProject status}} → {{Ombox/shortcut}} → {{Ubl}} → Module:List, will render as expected. If no other objections/failed tests arise, we can try this again. P. I. Ellsworth, ed. ^put'r there 20:00, 11 September 2019 (UTC)

{{WikiProject status/sandbox}} works properly, even after restoring the line breaks in {{Ombox/shortcut}}. — Newslinger talk 21:12, 11 September 2019 (UTC)

{{Infobox person}} → {{Unbulleted list}} → Module:List will render normally; also {{Ordered list/sandbox}} is as expected. P. I. Ellsworth, ed. ^put'r there 20:48, 11 September 2019 (UTC)

 Done. To editors Petr Matas, Frietjes, Redrose64, DannyS712 and Newslinger: fingers crossed. P. I. Ellsworth, ed. ^put'r there 21:16, 11 September 2019 (UTC)

I have added corresponding testcases. Petr Matas 07:28, 12 September 2019 (UTC)

...and handling of "{|". See my edit. To editor Frietjes: Is there any reason for not using mw.text.trim()? Petr Matas 07:58, 12 September 2019 (UTC)

Reverse ordered lists?

Is it possible to use this module (or another module/template) to create reverse ordered lists, i.e. using the reversed attribute? – Joe (talk) 12:01, 15 April 2020 (UTC)

Feature req.: inline-block version for horizontal lists

Both {{Hlist}} and {{Flatlist}} could really use a version that worked inline, instead of forcing a new block. I believe that this would work with display: inline-block; on the surrounding list element as well as the list items. This could be triggered by an |inline=y (or other positive-value) template parameter. Here's a raw-HTML test:

Intro text:

• 1st item
• 2nd item
• 3rd item

. Outro text.

The test needs CSS styling for spacing and to provide separators with :before, but it proves that the method works.

I'm a chicken, bawk-bawk, when it comes to modifying Lua modules that are in heavy use, so I'll punt the brunt unto the Scribunto junta.
 — SMcCandlish ☏ ¢ 😼  10:46, 4 April 2021 (UTC)

This already works for {{hlist}}: {{hlist|style=display:inline|list_style=display:inline-block|1st item|2nd item|3rd item}} procudes
Intro text:

• 1st item
• 2nd item
• 3rd item

Outro text
I do agree that it may be a good idea to add a |inline= parameter to do that. {{flatlist}}, confusingly, is a pure-wikitext template and is not implemented using this module. * Pppery * _{it has begun...} 16:02, 4 April 2021 (UTC)

Inlining styles via TemplateStyles. Who can help?

Moving this convo to MediaWiki talk:Common.css for other feedback, since this module page seems to be out of way for other watchers. --Izno (talk) 22:54, 3 October 2021 (UTC)

Alternate bullet symbols

Please join Template talk:Bulleted list#Style problem, which may also relate to the #bulleted list topic above from a few years ago. DMacks (talk) 06:41, 24 November 2023 (UTC)

@GreenC and Redrose64: you were part of that old discussion. DMacks (talk) 06:42, 24 November 2023 (UTC)

Nested wikitext list runs on

I try to use a wikitext list in Module:List's items. Unexpected, the nested list never ends, running on to contaminate other entries of the Module's list.

Code	Expected	Actual (from subst)
{{#invoke:list|ordered |1=a |2=b * ba * bb |3=c }}	a b ba bb c	a b ba bb c

It looks like wikitext() never got to adding a </ul> for the nested list. Tidy somehow then decides, from whatever we are feeding it, that the correct topology is to let the internal list run on.

I tried adding item:done() to the sandbox version, thinking it might insert a </li> to help close the list. Doesn't seem to help, at least according to comment-preview. Artoria2e5 🌉 03:09, 8 January 2024 (UTC)

Special:ExpandTemplates gives some new insight: allegedly the invocation it first turns into

<div><ol><li>a</li><li>b
* ba
* bb</li><li>c</li></ol></div>

This is a little bit of a pitfall on the Scribunto side, since mw.html:wikitext() obviously doesn't really so much build HTML then just insert raw wikitext into its output. I added an explicit newline to break the list on the sandbox and it seems to help:

1. a
2. b
   • ba
   • bb
   • c

(There's one remaining mystery here: the thing somehow works with Template:Ordered list/testcases. What's trimming doing?) --Artoria2e5 🌉 03:21, 8 January 2024 (UTC)

Solved my mystery: proceeding text is required to trigger problem. Also, thanks to peppery for fixing my fat finger mistake. Artoria2e5 🌉 06:53, 8 January 2024 (UTC)

Protected edit request on 8 January 2024

Per above, I intentionally added a newline after the end of each li node to prevent running-on of wikitext lists. Although doing so appear to break 3 Lua tests, they should have zero actual effect on the final HTML output after Tidy. I would even go so far to argue that the tests are wrong.

Please apply my last revision at Module:List/sandbox (1194269755 right now) to the main version. Artoria2e5 🌉 03:21, 8 January 2024 (UTC)

 Done * Pppery * _{it has begun...} 16:55, 8 January 2024 (UTC)

@Artoria2e5 and Pppery: FYI I think this edit affected the appearance of lists like the ones at Wikipedia:Administrators' newsletter/2023/12 (and every other admin newsletter). I'm not technically proficient enough to come up with an explanation or resolution though, so just wanted to point it out. DanCherek (talk) 18:17, 8 January 2024 (UTC)

Yeah, that looks bad.  Reverted * Pppery * _{it has begun...} 18:18, 8 January 2024 (UTC)

Interesting. I’m a little late here, but I think I can try and reproduce with hlist/sandbox when I get up… Artoria2e5 🌉 01:43, 9 January 2024 (UTC)

If people are experimenting with this further, please check {{Politics of Turkey}}, one of many sidebar templates that appears to have been negatively affected by the above change. It's fine after the revert, but it had a Linter syntax error that you could see on the Page information page, and maybe some bad rendering. – Jonesey95 (talk) 01:52, 9 January 2024 (UTC)

Debug session

Alright, let's see what went wrong. Here are the extracted testcases:

Admin newsletter case

[[File:Wikipedia Administrator.svg|20px|alt=]] '''Administrator changes'''
:[[File:Gnome-colors-list-add.svg|20px|alt=added|Added]] {{hlist|class=inline
|[[Wikipedia:Requests for adminship/Ganesha811|Ganesha811]]
|[[Wikipedia:Requests_for_adminship/JPxG|JPxG]]
}}

{{hlist}}	→	Administrator changes Ganesha811 JPxG
{{hlist/sandbox}}	→	Administrator changes Ganesha811 JPxG

Turkiye sidebar case

* Recent elections
*: [[Parliamentary elections in Turkey|Parliamentary]]
*:: {{hlist |[[November 2015 Turkish general election|2015]] |[[2018 Turkish parliamentary election|2018]] |[[2023 Turkish parliamentary election|2023]]}}
*: [[Turkish presidential elections|Presidential]]

{{hlist}}	→	Recent elections Parliamentary 2015 2018 2023 Presidential
{{hlist/sandbox}}	→	Recent elections Parliamentary 2015 2018 2023 Presidential

The common theme here is that a list not supposed to be broken is broken, which is kinda an obvious consequence of the newline. How do we make sure the list breaks when we want it to, and also doesn't when we don't want it to?

I'm going to first try newline before </li>. If that doesn't work, we might have to explicitly signal when to add a newline, or ask users to insert some invisble but untrimmable thing after the list (like a <nowiki/>). --Artoria2e5 🌉 06:20, 9 January 2024 (UTC)

Nope, this does not work. I think an explicit newline argument is overkill; let's just change the doc to mention the <nowiki/> technique (why didn't I think of it earlier?).

Run-on avoidance

{{#invoke:list|ordered|1=a
|2=b
* ba
* bb
<nowiki/>
|3=c}}

{{#invoke:list}}	→	a b ba bb c
{{#invoke:list/sandbox}}	→	a b ba bb c

Yep, that works. --Artoria2e5 🌉 06:25, 9 January 2024 (UTC)

My brain is a little stuck. I am having trouble thinking of where to put that workaround advice. Maybe later. Artoria2e5 🌉 06:41, 9 January 2024 (UTC)

{{Bulleted list}} says it is for situations "where the equivalent wiki markup (asterisks at the starts of new lines) may be awkward or impossible to use."

Markup	Renders as
{{#invoke:list|ordered|1=a |2=b{{bulleted list |ba |bb }} |3=c }}	a b ba bb c

Regards, Rjjⁱⁱⁱ (talk) 06:51, 9 January 2024 (UTC)

Protected edit request on 15 March 2024

Sync with Special:Diff/1213864199, which adds the following after line 186:

			frameOnly = ((frame.args.frameonly or '') ~= ''),

This will add a |frameonly= parameter, which allows the module to be called directly from a template (for reduced post-expand include size) without the module getting confused by parameters passed to the calling template. --Ahecht (TALK
PAGE) 15:55, 15 March 2024 (UTC)

 Done * Pppery * _{it has begun...} 20:44, 25 March 2024 (UTC)

Note this was later reverted because it broke things. I've coded what I believe is a fixed version in the sandbox, but I will let a different admin deploy this time, so reactivating the request. Cc Ahecht * Pppery * _{it has begun...} 20:55, 25 March 2024 (UTC)

Good catch. I don't think that that error would occur in the real world except in a corner case where a module artificially created a new frame and set the arguments equal to nil, but it's better safe than sorry. --Ahecht (TALK
PAGE) 00:20, 26 March 2024 (UTC)

Sandbox code looks fine to me. But using the "wrappers" option in Module:Arguments has always worked well for me in the past. In their a reason this approach can't be used to automatically switch between frame and parent frame parameters? — Martin (MSGJ · talk) 15:19, 28 March 2024 (UTC)

The problems is that there are pages dependent on mixing behavior like {{Unbulleted list citebundle}}. This is one of the highest-use templates on the project so has Hyrum's law-ed beyond all recognition and we should avoid what could even be seen as a breaking change. Ahecht and I both learned that lesson the hard way, and we don't want to repeat it. Pppery (alt) (talk) 19:26, 28 March 2024 (UTC)

Apparently I'm the only admin willing to touch this with a ten-foot pole.  Done * Pppery * _{it has begun...} 16:46, 19 May 2024 (UTC)