Module talk:List

Tests via template calls

Ordered not working
See Template talk:Ordered list. 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)
 * I wasn't seeing any difference for my tests with  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)
 * 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, 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  and   is passed, the module outputs. When  is given with , it should (also) output  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.  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.  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:
 * Add the more consistent set as a third set, but only temporarily while...
 * ...a bot is tasked to rename instances from one of the other sets, meaning that...
 * ...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.  16:07, 8 September 2014 (UTC)
 * In that case, can the templates that call Module:List (,, 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  and  .   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  when   should suffice? it seems to have something to do with , mentioned in Module:List. pointed out, "as it's a module, I rather suspect that several templates use it, so one of those may need the enclosing ." 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)
 * 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)
 * 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 [//www.w3.org/TR/html5/grouping-content.html#the-ol-element the  element] to enclose one or more [//www.w3.org/TR/html5/grouping-content.html#the-li-element   elements] like this: Minus TwoMinus OneZeroPlus One<li>Plus Two</ol> What your browser does with those  elements is largely outside our control - we can specify start value - this is the   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   attribute here. What we cannot do is specify how a minus sign is to be displayed. -- Red rose64 &#x1f339; (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  is not supported anywhere). Then the question is: can this be emulated using   with some styling to match the   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.
 * [//www.w3.org/TR/html5/grouping-content.html#the-ol-element The  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.
 * [//www.w3.org/TR/html5/grouping-content.html#the-dl-element The  element] represents an association list consisting of zero or more name-value groups (a description list).
 * [//www.w3.org/TR/html5/tabular-data.html#the-table-element The  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  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. -- Red rose64 &#x1f339; (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. — 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. — <span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius  ♪ talk ♪ 02:46, 2 March 2017 (UTC)
 * Looks interesting, but why even Firefox does not understand  and   from the W3C draft, requiring its own   and   instead?
 * Anyway, it seems that  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 [//www.w3.org/2017/Process-20170301/#maturity-levels section 6.1.2 Maturity Levels]), and so browser vendors like Mozilla are under no obligation to implement any of [//www.w3.org/TR/2011/WD-css3-lists-20110524/ 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 <ol type=A><li>No trump<li>Spades<li>Hearts<li>Diamonds<li>Clubs</ol>
 * 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. -- Red rose64 &#x1f339; (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  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 (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? -- Green  C  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 [//www.w3.org/TR/CSS21/generate.html#propdef-list-style-image the  property], and images may be drawn to any practical size. -- Red rose64 &#x1f339; (talk) 08:02, 2 May 2018 (UTC)
 * Would  be globally adjustable, such as in the Lua module, or only  local CSS? I'm not too familiar with CSS but see   defined in the module. What would happen if it was changed to   (the icon image of  • ). --  Green  C  13:57, 2 May 2018 (UTC)

Nested list bug?
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)
 * , 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   which has no extra new line.  the issue is most likely the extra  inside the list.  this could be potentially fixed by removing the  and moving the class specifiers into the <ul ></ul>.  I'm not sure why these need to be in a separate  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: 1. First item

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

Expected result:

<ol><li>First item </li><li>
 * Second item
 * is a nested list
 * of multiple items</li></ol>

Actual result:

<ol><li>First item</li><li>*Second item
 * is a nested list
 * of multiple items</li></ol>

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 at around that time? I put some [//en.wikipedia.org/w/index.php?title=Module:List/sandbox&diff=prev&oldid=913719626 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. &#32;
 * Second item
 * is a nested list
 * of multiple items
 * -- Red rose64 &#x1f339; (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 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 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)
 * Yes check.svg Done DannyS712 (talk) 04:13, 8 September 2019 (UTC)
 * . 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  elements were rendered outside of the the list's   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  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 [//en.wikipedia.org/w/index.php?title=Module%3AList%2Fsandbox&type=revision&diff=914652462&oldid=874524067 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)
 * ✅. 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. 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 attribute? –&#8239;Joe (talk) 12:01, 15 April 2020 (UTC)

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

Intro text: <ul style="display: inline-block;"> <li style="display: inline-block;">1st item</li> <li style="display: inline-block;">2nd item</li> <li style="display: inline-block;">3rd item</li> </ul>. Outro text.

The test needs CSS styling for spacing and to provide separators with, 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: 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 * <sub style="color:#800000">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, which may also relate to the topic above from a few years ago. DMacks (talk) 06:41, 24 November 2023 (UTC)
 * 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.

It looks like wikitext never got to adding a  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  to help close the list. Doesn't seem to help, at least according to comment-preview. Artoria2e5 <small style="font-weight:lighter">🌉 03:09, 8 January 2024 (UTC)

Special:ExpandTemplates gives some new insight: allegedly the invocation it first turns into <ol><li>a</li><li>b
 * ba
 * bb</li><li>c</li></ol>

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:

(There's one remaining mystery here: the thing somehow works with Template:Ordered list/testcases. What's trimming doing?) --Artoria2e5 <small style="font-weight:lighter">🌉 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 <small style="font-weight:lighter">🌉 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 <small style="font-weight:lighter">🌉 03:21, 8 January 2024 (UTC)
 * ✅ * Pppery * <sub style="color:#800000">it has begun... 16:55, 8 January 2024 (UTC)
 * FYI I think this edit affected the appearance of lists like the ones at 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. * Pppery * <sub style="color:#800000">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 <small style="font-weight:lighter">🌉 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:

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 &lt;/li&gt;. 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 &lt;nowiki/&gt;). --Artoria2e5 <small style="font-weight:lighter">🌉 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 &lt;nowiki/&gt; technique (why didn't I think of it earlier?).

Yep, that works. --Artoria2e5 <small style="font-weight:lighter">🌉 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 <small style="font-weight:lighter">🌉 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."

Regards, Rjjiii  (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:

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 (<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK PAGE ) 15:55, 15 March 2024 (UTC) PAGE ]]) 00:20, 26 March 2024 (UTC)
 * ✅ * Pppery * <sub style="color:#800000">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 * Pppery * <sub style="color:#800000">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 ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK
 * 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? &mdash; 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. ✅ * Pppery * <sub style="color:#800000">it has begun... 16:46, 19 May 2024 (UTC)