View source for Template talk:Navbox/Archive 23

{{talkarchivenav}}

== Request for an "experimental" parameter to allow innovation in getting navboxes to show up on mobile ==

Hi there! I come here from [[Template_talk:Taxonbar#Making_Taxonbar_mobile-friendly_and_serve_half_of_all_Wikipedia_readers]]. As you may be aware, many navboxes are unusable on mobile and break the reading experience and as a result are removed by brute force from the mobile site.

This was meant to be a short term solution, but as with most short term solutions has become long term (see [[phab:T124168]]. I'm keen to make steps to rectify this beginning with the [[Template:Taxonbar]], however I need a slight adjustment here to allow me to do this.

My hope here is to provide a general solution that can be applied to other templates.

Any element with the `navbox` class will be removed from the HTML on mobile, so to workaround this issue and allow experimentation in the area, a temporary parameter is needed that will allow us to use a different class to e.g. `navbox-experimental`. Feel free to name this parameter/class anything that makes sense. It could also be mobile=1 and `navbox-mobile-friendly` for example. The important thing is the `navbox` class should not be added.

e.g. proposed change:

<pre>
		local nav = res:tag('div')
			:attr('role', 'navigation')
			:addClass('navbox')
			:addClass(args.navboxclass)
</pre>

to 

<pre>
		local nav = res:tag('div')
			:attr('role', 'navigation')
			:addClass(args.experimental ? 'navbox-experimental': 'navbox') # not sure if this is valid Lua code but hopefully it's clear what I'm trying to do here. The class should be navbox-experimental when the flag is set.
			:addClass(args.navboxclass)
</pre>

Is this possible? If so I promise to report back when I have something cool to show. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 23:24, 24 November 2020 (UTC)
:I actually recently just set everything to display block in a media query and it actually looks pretty reasonable as a first-try stupid solution. There's some white space that is showing up that's weird and I don't know how it will go with e.g. the image cell. Try it in Timeless or Minerva on the desktop domain while on mobile. (I haven't had a chance to look at Anonymous's solution yet since he put something on the task recently.)
: I'm not really a fan of a parameter for it.... If it's successful it's a lot of cleanup of an unused parameter and if it's not successful it's a lot of cleanup of an unused parameter. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 00:38, 25 November 2020 (UTC)
:: I'm not a fan of a parameter either TBH, but without the parameter, I see this as a little deadlocked as I don't have any intention of fixing all the navboxes right now. The alternative would be to fork the template e.g. [[Template:NavboxV2]]. Would that be better? [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 02:04, 25 November 2020 (UTC)
:::You don't have to fork it, just use [[Module:Navbox/sandbox]]. I gather you plan to make a sandbox with some text and a modified navbox, then view the result on mobile? And experiment to see what is needed to make mobile work? Another approach would be to use [[Special:ExpandTemplates]] to get the output of whatever you are working on, then edit the raw html in a sandbox. As I recall, this module puts everything in one line which make editing a bit ugly. I think that's why I once used [[Module:Dump#Dumping a navbox]]. Lua uses "and...or" as a useful kludge for "?...:". I can put that in a module if needed. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 05:58, 25 November 2020 (UTC)
:::It might just be preferable to write in a hard exception here as in 'if name = Authority control then navbox-exp else navbox'. That said, that particular template is a really simple example to try to work on these problems, and I'm fairly sure it will not extend. As for TemplateStyles, we still have not decided how to deal with TemplateStyles in these meta modules; the solution I'm coming around to supporting is something of the "for templatestyles..n parameters, add a templatestyles tag" so that multiple invoking templates (i.e. navbox -> intermediate navbox -> final navbox) can have access to their own tstyles. (This of course makes the special 'single border' CSS harder to write.)
:::In general, just spitballing and/or providing info. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:37, 25 November 2020 (UTC)
::::(On an aside, I am not entirely certain Authority control needs to be written using navbox at all; it's such a simple template that it could reasonably be written in like 4 lines of Lua to remove the navbox dependency. I don't know what the collective thoughts are on such a thing. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:39, 25 November 2020 (UTC))

== Non-unique id ==

I noticed that this template uses the title of the navbox as an ID (<code>:attr('id', mw.uri.anchorEncode(args.title))</code>). However, it cannot be assumed that these IDs will always be unique, which creates invalid HTML. For an example of this, see the article [[Madame Nhu]], which has a section titled [[Madame Nhu#Buddhist crisis|Buddhist crisis]], as well as a navbox [[Template:Buddhist crisis|Buddhist crisis]]. The fact that navboxes are usually present on related subjects makes such occurrences likely. I propose that when the ID is created, that it be prefixed with "navbox_" so it doesn't clash with any section headers or user-added anchors. [[User:Opencooper|Opencooper]] ([[User talk:Opencooper|talk]]) 17:01, 17 December 2020 (UTC)
:Not sure what you mean by "invalid HTML"; what tangible effect is this having on the page? [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 17:08, 17 December 2020 (UTC)
::For now, maybe none (though I noticed it because I have a userscript that does stuff with IDs and the elements ended up getting switched). However, the concern is that any CSS or code that targets this specific ID in the navbox will instead end up being applied to an anchor that comes before it (run <code>document.getElementById("Buddhist_crisis")</code> on the Nhu page and you'll only get the header). Currently I see the following inline style being applied: <code>font-size:114%; margin:0 4em</code>. Given that eventually the goal is to move inline styles to [[wp:TemplateStyles|TemplateStyles]], this might end up happening inadvertently.
::And the HTML is invalid because IDs are supposed to be unique within a document. Here it is straight [https://html.spec.whatwg.org/multipage/dom.html#the-id-attribute from the spec]: {{tq|When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree}} (note, "must"). Given that we could make our HTML valid just by prefixing the ID, I think this should be addressed. [[User:Opencooper|Opencooper]] ([[User talk:Opencooper|talk]]) 17:39, 17 December 2020 (UTC)
:Yeah, I noticed this template was emitting an ID the other day and wasn't sure how to deal with it. Given its use for ARIA labelledby, I think tacking on a "_navbox_aria" in the string creation makes sense (or something to that effect). Still can't do much about the testcases page, but that's not exactly a use case envisioned by W3C/WHATWG regarding IDs. Best would be an overhaul of this template to not use tables, which may/not come around the time TemplateStyles get integrated. (I've slowly been working on the latter if you are interested at [[Mediawiki talk:Common.css/to do]].) --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:06, 17 December 2020 (UTC)
::I think it's fine if the testcases page has duplicates since that's not really reader-facing. Agreed with your proposed solution, though it might all be moot if the whole thing gets overhauled. [[User:Opencooper|Opencooper]] ([[User talk:Opencooper|talk]]) 18:45, 17 December 2020 (UTC)

== Can |groupwidth = __ be used to ''narrow'' cells? ==

Using the "|groupwidth = #em " parameter appears to force ''extra'' whitespace and widen the group column of a subgroup, but is there a way to force the column to be ''narrower''?  I am asking because a long group name can force extra whitespace into all of the other group names.  I can insert <nowiki><br /></nowiki> line breaks manually to adjust this, but I was wondering if there is a way to let auto-formatting take care of that via a fixed groupwidth. -[[User:2pou|2pou]] ([[User talk:2pou|talk]]) 19:54, 17 December 2020 (UTC)
: {{ping|2pou}} You have to override the nowrap, so {{para|groupstyle|width:8em;white-space:normal;}} should do it, or whatever width is appropriate.  Thanks! [[User:Plastikspork|Plastikspork]] [[User talk:Plastikspork|<sub style="font-size: 60%">―Œ</sub><sup style="margin-left:-3ex">(talk)</sup>]] 14:57, 18 December 2020 (UTC)
::Thanks, {{u|Plastikspork}}!  The white-space:normal worked like a charm: [[Special:Diff/994992577]].  I couldn't get the width part to narrow down any further, but this does what I was looking for. -[[User:2pou|2pou]] ([[User talk:2pou|talk]]) 16:53, 18 December 2020 (UTC)

== Group without a child list item ==

Inside the template [[Template:Trade unions in Myanmar navbox]] for ''list2='' item, I am forced to put something there, otherwise even the group2 won't show. Does anyone have a work around, besides for empty/invisible string? [[User:Shushugah|Shushugah]] ([[User talk:Shushugah|talk]]) 21:40, 25 February 2021 (UTC)
:1, The navbox shouldn't exist with that many redlinks. 2, you shouldn't have group with no list items. 3, if you needed it you can use above/below to put that link. But once again, this navbox should only exist to navigate between existing pages. [[User:DLManiac|DLManiac]] ([[User talk:DLManiac|talk]]) 22:14, 25 February 2021 (UTC)
::Agreed. If you're trying to have a navbox where only the group shows, you need to rethink and/or restructure your navbox. Personally, with that navbox I would use sequential indentation for {{para|list1}}, having what are currently your "groups" under * and all of the values in "list1" having ** indentation. That will still give you the necessary splits without having to bodge things up. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 15:28, 26 February 2021 (UTC)

== Parameter alias ==

{{edit template-protected|answered=yes}}
I think that {{para|status}} would be a decent alias for the existing parameter {{para|state}}. Or at least, this seemed like an intuitive option [https://en.wikipedia.org/enwiki/w/index.php?title=COVID-19_misinformation_by_China&type=revision&diff=1014332781&oldid=1014332534 to me, here]; and templates should be more user friendly if possible. Now I don't know enough about template syntax to know what needs to be done, so asking nicely here in case somebody with more of a clue can help. [[User:RandomCanadian|RandomCanadian]] ([[User talk:RandomCanadian|talk]] / [[Special:Contributions/RandomCanadian|contribs]])  14:18, 26 March 2021 (UTC)
:[[File:Red information icon with gradient background.svg|20px|link=|alt=]] '''Not done for now:'''<!-- Template:ETp --> One name for the parameter seems quite sufficient to me. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:08, 26 March 2021 (UTC)
::Thank you. Aliases cause confusion. If someone sees "status" in one article and "state" in another, they are going to waste time wondering what the difference is and which should be used. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 22:55, 26 March 2021 (UTC)
:::Aliases make templates more user friendly - it's always possible and straightforward to mention them in the documentation... [[User:RandomCanadian|RandomCanadian]] ([[User talk:RandomCanadian|talk]] / [[Special:Contributions/RandomCanadian|contribs]])  04:06, 27 March 2021 (UTC)
::::Even if status was added to the Navbox template, it would also need adding to every template that uses Navbox before it could be used as a parameter from an article. -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 11:46, 27 March 2021 (UTC)

== Expanded by default ==

Would it be possible to set a preference or some CSS so that navboxes and their collapsed sections are all visible to me by default? [[User:NemesisAT|NemesisAT]] ([[User talk:NemesisAT|talk]]) 12:01, 9 May 2021 (UTC)
:It can't be done in CSS alone, because the collapsing is done by means of JavaScript which alters the <code>style=""</code> attribute of table rows to add or remove the declaration <code>display: none;</code>. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 19:51, 9 May 2021 (UTC)
::Thanks for this. Maybe that can be overwritten with <code>!important;</code>? I'll have to take a closer look. [[User:NemesisAT|NemesisAT]] ([[User talk:NemesisAT|talk]]) 15:05, 10 May 2021 (UTC)
:::No. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 22:51, 10 May 2021 (UTC)
:::You could probably write yourself some Javascript to run for yourself after the relevant Javascript has run that would remove the display: nones. But no, not CSS directly. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 06:07, 17 May 2021 (UTC)

== "Purely decorative" images ==

The template documentation says of its image field that "Typically it is purely decorative"... yet [[MOS:DECOR]] says "Icons should serve an encyclopedic purpose and not merely be decorative." Should the documentation reflect that, and discourage images that only add decoration? If so, where's the line drawn for what's "decorative"?

I had the policy pointed out to me by someone removing a picture of a potato from [[:Template:Potato dishes]], which is maybe fair enough, but that kind of usage seems fairly common across navbox templates. --[[User:Lord Belbury|Lord Belbury]] ([[User talk:Lord Belbury|talk]]) 17:59, 12 January 2021 (UTC)
:I've taken [[WP:BOLD|a bold approach]] and [[special:diff/1000636370|edited the doc]]. — [[user:Mike Novikoff|Mike Novikoff]] 00:50, 16 January 2021 (UTC)
:[[WP:DECOR]] is about icons, little national flags and that sort of thing, ''not'' images in general. Also it is a manual of style matter, offering guidance, not hard rules. The bold edit above saying most images should be removed on sight is grossly inappropriate and, in my view, should be reverted. DECOR does not apply and this discussion should not have been regarded as concluded. [[User:Thincat|Thincat]] ([[User talk:Thincat|talk]]) 11:10, 22 January 2021 (UTC)
::WP:DECOR also talks about navigation and discourages images that serve no navigational purpose. I agree that images should be in navboxes only in exceptional circumstances. They take up space better used for navigational links, and they do that typically on many pages. WP:DECOR's {{tq|They should provide additional useful information on the ... subject, serve as visual cues that aid the reader's comprehension, or improve navigation.}} is good advice. -- [[User:Michael Bednarek|Michael Bednarek]] ([[User talk:Michael Bednarek|talk]]) 12:10, 22 January 2021 (UTC)
:::Are we referring to different guidelines? By my understanding [[WP:DECOR]] is the section of the manual of style relating to ''icons''. What you say may be the case but it isn't DECOR that says it. [[User:Thincat|Thincat]] ([[User talk:Thincat|talk]]) 13:03, 22 January 2021 (UTC)
::::WP:DECOR defines icons as any small images and it deals with navigational issues. This discussion start with concerns about [[Template:Potato dishes]]; what possible value does the small image in {{Oldid2|991959282|this version}} of that template have? -- [[User:Michael Bednarek|Michael Bednarek]] ([[User talk:Michael Bednarek|talk]]) 17:16, 23 January 2021 (UTC)
:::::I'm not giving any opinion on its value. I'm saying it isn't an icon. And DECOR doesn't say either icons or small images should be removed on sight. [[User:Thincat|Thincat]] ([[User talk:Thincat|talk]]) 19:06, 23 January 2021 (UTC)
:::::If pages with multiple navboxes collapse them all by default, which seems to be the case, I suppose there can be no possible navigational purpose to the image field - the user has to navigate to and open the box before they see the image. Stacked navboxes on an article like [[Knish]] would be quicker to navigate if they all had recognisable icons (the excessive example at [[:File:Navboxes - Jennifer Doudna - en.Wikipedia - 2020-10-07.png]] has clear Nobel Prize sections even at illegible thumbnail size), but not if they all start off collapsed. --[[User:Lord Belbury|Lord Belbury]] ([[User talk:Lord Belbury|talk]]) 12:32, 4 February 2021 (UTC)
:::::: I find the image in [//en.wikipedia.org/enwiki/w/index.php?title=Template:Jewish_cuisine&oldid=986873996 Template:Jewish cuisine] counter productive.  Without it, there would be less wasted whitespace, and I wouldn't need to scroll to see all the links.  The image in [[Template:History of biology]] is better because the aspect ratio is more compatible with the box content. Thanks! [[User:Plastikspork|Plastikspork]] [[User talk:Plastikspork|<sub style="font-size: 60%">―Œ</sub><sup style="margin-left:-3ex">(talk)</sup>]] 14:53, 4 February 2021 (UTC)
::::::: [[Template:History of biology]]'s tall side image looks good, but seems just as "purely decorative" as any other example listed here: probably moreso, as I don't think the icon communicates "biology" at a glance to the average reader. It should be "removed on sight" if we're sticking with the bold instruction from January. --[[User:Lord Belbury|Lord Belbury]] ([[User talk:Lord Belbury|talk]]) 09:59, 17 May 2021 (UTC)
::::::::I agree that that image, in addition to not aiding navigation, doesn't convey anything about "biology". Its use in the article on its creator, [[Nicolaas Hartsoeker]] (who is not mentioned in the template), is a good illustration, but it's pointless in the template. -- [[User:Michael Bednarek|Michael Bednarek]] ([[User talk:Michael Bednarek|talk]]) 11:04, 17 May 2021 (UTC)

== Localization ==

Would it be possible to make this module more localization friendly? Given that other wikis use it, it would be great if you could specify localized parameter names (and values like "autocollapse", "collapsed", "expanded", "plain", "off" etc.) so that they could be used alongside the original, English ones. – [[User:Srđan|Srđan]] ([[User talk:Srđan|talk]]) 09:56, 5 April 2021 (UTC)

:I'm willing to help if there are no objections, although help from more experienced Lua editors would be great.  [[:bs:Modul:Infobox]] is a quite good take on how i18n can be implemented, although it could be improved to make it more generalizable. [[User:MarioGom|MarioGom]] ([[User talk:MarioGom|talk]]) 10:03, 5 April 2021 (UTC)
::[[Module:Arguments]] which is used by [[Module:Navbox]] has an undocumented translate option for parameter names that could be used. -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 12:01, 5 April 2021 (UTC)
:::Any update on this? Do you know how to do it and would you be willing to implement it? – [[User:Srđan|Srđan]] ([[User talk:Srđan|talk]]) 17:37, 21 April 2021 (UTC)
:{{ping|Srđan|MarioGom|WOSlinker}} I did a rough job in the sandbox. Does not support numbered parameters as it should but most of the relevant strings got pulled out. Please, uh, test. Also, I didn't use the module:arguments translate stuff given that it's not documented for idiots. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 06:24, 17 May 2021 (UTC)
::{{ping|Izno}} Re [[Module:Navbox/sandbox]] and comment "where is code set???": <code>changer</code> is a function and <code>code</code> is set as its parameter when <code>changer</code> is called. That occurs in the final <code>gsub</code> which calls the function for each match of <code>REGEX_MARKER</code>. That part of the module is extremely tricky, good luck!{{pb}}Re <code>needsHorizontalLists</code> and your FIXME: I don't follow. The original code adds the tracking category [[:Category:Navigational boxes without horizontal lists]] if parameter listclass is not one of the named classes (plainlist, hlist, etc.); same with parameter bodyclass. I guess you know the module wouldn't work at the moment because it would try to index a nonexistent variable (<code>list_classes</code>). [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 07:11, 17 May 2021 (UTC)
:::Right, my point is that listclass might in fact be something other than those listed while also including one of the usual list classes, so what the module should be doing is trying to find one of those classes, instead of checking for equality.
:::The relevant variable should exist now. :^)
:::I probably just don't get lambdas. heh [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 07:17, 17 May 2021 (UTC)
::::Given that the category contains 1950 pages, perhaps it is not useful and could be removed? I don't know it's purpose, I just retained the logic of the original. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 07:31, 17 May 2021 (UTC)
:::::That category was useful when there were lots of navboxes that didn't use the hlist class but now, all that is left are ones that are all the exceptions that don't actually need a list converting to the hlist format.  So i think that category could be removed. -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 07:53, 17 May 2021 (UTC)
::::::Yeah, but we'll need an implementation that does find these things because when hlist and plainlist gets TemplateStyled I am not going to go around to the ~100,000 navboxes with an hlist class to switch to {{tl|hlist}}, {{tl|plainlist}}, and any other applicable templates, I'm just going to insert the relevant templatestyles invocation. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 15:59, 17 May 2021 (UTC)
:::::::The {{c|Navigational boxes without horizontal lists}} category was mainly to do with accessibility improvements - until hlist was introduced, most navboxes used bullets between entries, often using the {{tlx|•}} template, which was very bad for accessibility. Back in November/December 2011 we decided to sort this out, with edits {{diff|Template:Railway stations in Oxfordshire|prev|476018142|like this}}. The category was used to find out what still needed fixing. WOSlinker was heavily involved. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 20:08, 17 May 2021 (UTC)

==Discussion at [[:Wikipedia:Village pump (proposals)#WikiProject links in navigational templates|Wikipedia:Village pump (proposals) §&nbsp;WikiProject links in navigational templates]]==
[[File:Symbol watching blue lashes high contrast.svg|25px|link=|alt=]]&nbsp;You are invited to join the discussion at [[:Wikipedia:Village pump (proposals)#WikiProject links in navigational templates|Wikipedia:Village pump (proposals) §&nbsp;WikiProject links in navigational templates]].  --[[User:Trialpears|Trialpears]] ([[User talk:Trialpears|talk]]) 16:02, 8 July 2021 (UTC)<!-- [[Template:Please see]] -->

== Autocollapse ==

Hello. I added a navbox to [[Web testing]], with no state, so I assume it is defaulting to autocollapse. Interestingly, it is choosing to fully collapse, despite there being no other navboxes on the page. Any idea why? Is this expected behavior? Thanks. –[[User:Novem Linguae|<span style="color:limegreen">'''Novem Linguae'''</span>]] <small>([[User talk:Novem Linguae|talk]])</small> 06:49, 14 May 2021 (UTC)
:I'm pretty sure it's because of the {{tl|multiple issues}} box on that page, which is also collapsible. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 13:20, 14 May 2021 (UTC)
::Definitely {{tlx|multiple issues}}; the two templates that it encloses have no bearing on the matter. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 17:40, 14 May 2021 (UTC)
:::Wouldn't it be a good idea to tweak {{tlf|multiple issues}}, or probably rather {{tlx|Ambox}} which does the work, so this doesn't happen? -- [[User:Michael Bednarek|Michael Bednarek]] ([[User talk:Michael Bednarek|talk]]) 00:38, 15 May 2021 (UTC)
::::It's not {{tlx|ambox}} itself, it's the <code>mw-collapsible</code> class that is applied to the {{tag|div}} enclosed by the ambox. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 09:11, 15 May 2021 (UTC)
:TheDJ has previously suggested on [[MediaWiki talk:Common.css]] and/or [[MediaWiki talk:Common.js]] that perhaps how autocollapse works should be limited to certain templates like navbox. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:29, 20 August 2021 (UTC)

== How to use <nowiki>{{Navbox}}</nowiki> for a different Template namespace (4010 custom site-specific namespace instead of default 10) ==
Hi! I am using this template on my MediaWiki site and it's in the default Template namespace (10), however, I also have an additional namespace for templates (4010), the site is configured to allow everyone to edit 4010, but not 10 (which is reserved for synchronized from latest versions of widely used templates). I noticed the V T E links at top-left corner of the navbox links to Template (10) namespace, but I want to configure it to use the custom site 4010 namespace. Is there a way to do this in the <nowiki>{{Navbox...}}</nowiki> wikitext markup? I see the Navbar module appears to have a configuration for the template namespace to use [[Module:Navbar/configuration#L-4]] but I don't think the Navbox template passes this to also be configurable. [[User:Jasonkhanlar|Jasonkhanlar]] ([[User talk:Jasonkhanlar|talk]]) 04:26, 3 May 2022 (UTC)
: Solved! The `name` argument should be the path of the template including the namespace. All links work now. [[User:Jasonkhanlar|Jasonkhanlar]] ([[User talk:Jasonkhanlar|talk]]) 05:12, 3 May 2022 (UTC)

== i18n and TemplateStyles improvements ==

Thanks to {{u|Frietjes}} and {{U|Plastikspork}}'s recent work, the navbox class is no longer used in the wild unless through a template driven by [[Module:Navbox]]. As such, I've [https://en.wikipedia.org/enwiki/w/index.php?title=Special%3AComparePages&page1=Module%3ANavbox&page2=Module%3ANavbox%2Fsandbox sandboxed changes] (see also [[Module:Navbox/configuration]] and [[Module:Navbox/styles.css]]) to the module which enable TemplateStyles in the template in preparation for [[MediaWiki talk:Common.css/to do#description|removal from Common.css]].

I've also finalized the improvements listed [[Template talk:Navbox/Archive 23#Localization|in the localization discussion earlier this year]].

The sandboxes are currently 'passing' (behavior is replicated between old and new), so please take a look at those and any favorite navboxes you might have to see if behavior has changed in those as well.

Some potential improvements for this release besides the TODOs in the sandboxes would be:
# Remove the inline styles totally from the module into the stylesheet

Other major improvements that could be done but I'm not doing now:
# Work on allowing some modules like [[Module:Taxonbar]] to display on mobile
# Converting from table-based template to div-based template (see also [[User:Izno/Sandbox/Navbox]])

Questions/concerns welcome. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 01:29, 16 November 2021 (UTC)
:Impressive work. It looks good although I don't know about the styles. Re "we have infinite now, so why is this limited to 20?": There is no good way to enumerate all the template parameters in the wanted order, and there is no way to know when you have reached the end. A loop with <code>pairs</code> would normally be used but that could read arguments in a strange order conflicting with the comment that the intention is to make reference numbers appear in the right order. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 03:37, 16 November 2021 (UTC)
::Right, using iterators won't work in this context. Still leaves me wondering if we couldn't still bump 20 up a bit (maybe 50ish? -- I idly wonder what our numbers are for groups globally), or at least leave a note that we know this is a limited case I guess. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 04:41, 16 November 2021 (UTC)
:::No one is likely to notice if references after 20 are numbered in a strange order, and it's not even certain that a strange order would occur. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 05:50, 16 November 2021 (UTC)
::::"People won't notice" is how you get that chunk of code in the first place. :P It's fine, I added a note there to skip future questions. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 05:53, 16 November 2021 (UTC)
:::::On the configuration page, there is a slight inconsistency in the category table with orphan being a different format to all the others. Would be nice to be the same as the others. -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 09:01, 16 November 2021 (UTC)
::::::The category is being used both to add to the page and then to be removed from the page. There's really not another way to handle it unless we split it into two keys (which might be safer tbh). [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 17:09, 16 November 2021 (UTC)
: looks great.  it would be cool to replace lines like <code><nowiki>fontstyle = (args.basestyle or '') .. ';' .. (args.titlestyle or '') .. ';background:none transparent;border:none;box-shadow:none;padding:0;'</nowiki></code> with something that just extracted the last "color:" parameter.  the reason for the <code>background:none transparent;border:none;box-shadow:none;</code> is to override prior values potentially set in basestyle and/or titlestyle, so we end up sending a bunch of extraneous styles to navbar.  but, what we have works, so maybe it's not worth the extra processing. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 15:10, 16 November 2021 (UTC)
::That seems easy enough actually if the color is really all we want in that context (is it?). Maybe post-release.
::Another way to handle that would be to move the overrides to the stylesheet and drop a bunch of !important on them. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 17:08, 16 November 2021 (UTC)
::{{U|Frietjes}}, I've edited [[Module:Navbox/sandbox]] to remove the styles we don't want. Testcases specifically for that function are in [[Module:Sandbox/Izno/testcases]], with a few navbox test cases (a box-shadow one particularly) on [[Template:Navbox/testcases]]. Right now we are sending a <code>style=";"</code> which it would be nice not to send if we can avoid it. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 02:06, 18 May 2022 (UTC)
::: [[User:Izno|Izno]], nice work. I would replace <code>sanitizeCSS</code> with something that extracts the last color from the css [//en.wikipedia.org/enwiki/w/index.php?title=Module:Navbox/sandbox&diff=prev&oldid=1088522592 like this].  I don't think there is any other css that we should allow for styling the navbar. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 14:43, 18 May 2022 (UTC)
::::{{U|Frietjes}} I don't really want to make an assumption about what CSS ends up in that parameter, but honestly can't see a reason not to do something like that.
::::I do think yours makes an assumption about the presence of certain semicolons, particularly the end semicolon, which may not be true. Hence the mw.text.split in my copy. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 17:21, 18 May 2022 (UTC)
::::: [[User:Izno|Izno]], if you check [[Module:Navbox/sandbox#L-85|line 85]] you will see that I enclose the string with ';' before parsing, so no assumptions about any trailing semicolons. but please let me know if there is something that I am missing.  [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 18:22, 18 May 2022 (UTC)
::::::I looked at that several times and somehow didn't remember to actually consider it in my response. Sigh.
::::::I've made an adjustment to return nil out of the color function. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 19:34, 18 May 2022 (UTC)
::::::: yes, I agree, returning nil is even better in this case. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 19:40, 18 May 2022 (UTC)
:Deployed this round. I also added a check for titlegroup, which [https://en.wikipedia.org/enwiki/w/index.php?search=insource%3Atitlegroup+-intitle%3Asandbox&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1 doesn't look like it exists meaningfully]. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 00:07, 27 November 2021 (UTC)

=== TemplateStyles followup ===
Some followup!

I have removed the Lua that deals with titlegroup out of the sandbox. The category dragged up nothing in the past month. I'll remove this when I sync the module later.

Separately, [https://en.wikipedia.org/enwiki/w/index.php?title=Module:Navbox/styles.css&diff=prev&oldid=1061467846 I have adjusted the CSS] in the TemplateStyles page due to [https://en.wikipedia.org/enwiki/w/index.php?title=Module%3ANavbox%2Fstyles.css&type=revision&diff=1057682214&oldid=1055622440 this series of edits]. {{U|Neveselbert}} identified that the <code>.navbox th</code> style, when appended with the <code>.mw-parser-output</code> and subsequently embedded into a page by TemplateStyles, would override the table header styles of <code>wikitable</code> tables, which apparently impacted succession boxes in particular.

What this second change means is that handcrafted tables in navboxes will no longer be styled after removal from Common.css some time from now while the TemplateStyles styles are updated by the job queue again. ({{U|Neveselbert}}, please leave a talk page note in the future with an appropriate ping so that we can get this sorted quicker rather than a month down the road.) I see in the history of MediaWiki:Common.css that this has caused some consternation in the past, but with so few templates, the majority now using at least the same 'external' appearance via the module (i.e., the table header/title), and the fallback being fairly graceful to uncolored embedded tables, I feel comfortable fixing the CSS this way.

There are approximately 900 affected templates, which are now probably mostly using [[Module:Navbox top and bottom]] in case anyone should care to fix those in the future. Fixing the 900 templates involves probably 1 or 2 possible paths:

# Adding appropriate navbox classes to the headers of interest in each of those templates (not recommended).
# Converting those templates to use navbox or one of its derivatives fully rather than the navbox top and bottom solution.

Please let me know if you have significant heartburn. I will leave a pointer about this change at VPT and at Common.css. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 22:23, 21 December 2021 (UTC)
: [[User:Izno|Izno]], if I recall, the primary reason for using [[Module:Navbox top and bottom]] or the top and bottom in [[Module:Navboxes]] is that either (a) you want to embed a wikitable inside the navbox without heaving use of pipe templates or nowiki hacks, or (b) the post-expand size is exceeded from embedding a group of navboxes inside of another navbox.  Would it be possible to merge the top/bottom functions with Module:Navbox?  Thanks! [[User:Plastikspork|Plastikspork]] [[User talk:Plastikspork|<sub style="font-size: 60%">―Œ</sub><sup style="margin-left:-3ex">(talk)</sup>]] 16:07, 23 December 2021 (UTC)
:: correct me if I am wrong, but this isn't an issue with [[Module:Navbox top and bottom]] per se, but could be a problem if you are expecting a table embedded inside a navbox to inherit the styling of the navbox?  I spot checked a few, and I don't see any issues with the ones I checked.  but, I do agree that adding a top/bottom feature to [[Module:navbox]] could reduce the complexity of [[Module:Navbox top and bottom]], but I don't know if the reduction would be significant. thank you. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 16:41, 23 December 2021 (UTC)
:::Yes, this is the correct read {{U|Frietjes}}, but also if you're expecting the table headers (a la navbox with columns, which will be fine after this change) of the top level thing called a navbox to get colors.
:::I honestly don't want top and bottom to be anything more than 'it's a workaround', and if we could it would make more sense to get all those using it to use some more official form of module supporting them. I suspect that will be a long/lengthy/complex task of figuring out exactly why each of the 900 or so are using that module. What was your read on it? [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 19:07, 23 December 2021 (UTC)
:::: [[User:Izno|Izno]], I agree that the top/bottom templates should only be used when nothing else works well.  many of the top/bottom templates could probably be replaced with [[Template:Timeline]], but that would take some effort to convert them. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 19:10, 23 December 2021 (UTC)
:Styles are now solely in [[Module:Navbox/styles.css]]. {{para|titlegroup}} and related parameters have also been removed. :D :D :D [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 04:42, 10 January 2022 (UTC)
::Very nice work Izno ! —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:02, 10 January 2022 (UTC)

== question re horizontal bar  ==

hi everyone. I have a simple formatting question, about our [[template:navbox]]. how would I put a simple horizontal bar across the navbox, with some text inside it, to delineate a separate section? 

please note, this bar does ''not'' need to be the top of a collapsible section; it is simply for visual purposes only, in separating one part of the navbox from the other parts. 

appreciate any help. if you want, you can simply link me to an existing navbox which would have this feature. thanks!  --[[User:Sm8900|Sm8900]] ([[User talk:Sm8900|talk]]) 13:47, 16 June 2022 (UTC)
:You could add a {{tag|hr|s}} tag before the {{para|group''n''}} parameter. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 14:41, 16 June 2022 (UTC)

::Sm8900, do you mean something like this?
{{navbox
| name   = insert template name here
| state  = uncollapsed
| title  = {{{title}}}
| above  = {{{above}}}
| image  = {{{image}}}
| group1 = {{{group1}}}
| list1  = {{{list1}}} 
| group2 = {{{group2}}}
| list2  = {{{list2}}}
| list3  = {{Navbox|subgroup|above = Subheading}}
| group4 = {{{group4}}}
| list4  = {{{list4}}}
| below  = {{{below}}} 
}}
:: --<span style="box-shadow:2px 2px 6px #999">[[User:Dr Greg|<b style="color:#FFF8C0;background:#494">&nbsp;Dr&nbsp;Greg&nbsp;</b>]][[User talk:Dr Greg|<span style="color:#494;background:#FFF8C0">&nbsp;<small>talk</small>&nbsp;</span>]]</span> 15:27, 16 June 2022 (UTC)

== Invisibility of Premier League==
I have learnt in another discussion that there was a deliberate decision by the developers that Navbox is not supposed to be displayed on mobile devices, because they don't work properly. But the problem slowly increases as the percentage of mobile users has reached 65% of pageviews and even more critical as the [[Premier League]] is affected. Imagine a premier league match is streamed on mobile devices with only one team visible because the other team doesn't work properly. {{tl|Tottenham Hotspur F.C.}}, {{tl|West Ham United F.C.}}, {{tl|Manchester United F.C.}}, {{tl|Chelsea F.C.}}, {{tl|Liverpool F.C.}} and all the others are beautiful creations based on hard work using Navbox but they are invisible on mobile devices. No substitute is available on the template bench of Wiki for the incomplete {{tl|navbox}}. How can we kick off a new discussion to vote for the development of a technical solution of this problem? [[User:Ruedi33a|Ruedi33a]] ([[User talk:Ruedi33a|talk]]) 16:38, 30 August 2021 (UTC)

:@[[User:Ruedi33a|Ruedi33a]], I fully support your goals as expressed above. how about if we bring this to the Village Pump for some creative discussion and problem-solving? would you like to do that? full disclosure; my own technical knowledge about items like this is about nil. however, I'm in favor of interested editors helping each other and working together, on items such as these. feel free to advise. thanks!! --[[User:Sm8900|Sm8900]] ([[User talk:Sm8900|talk]]) 13:49, 16 June 2022 (UTC)

::@[[User:Sm8900|Sm8900]], thanks a lot for your support. But I have invested already a lot of work with no significant results. You can look at [[Ca' Pesaro]] and the change with the comment "The sequence enables mobile users to click the previous or the next landmark listed in the navbox Venice landmarks below, although a navbox is invisible in mobile view". [[User:Ruedi33a|Ruedi33a]] ([[User talk:Ruedi33a|talk]]) 21:14, 16 June 2022 (UTC)

== Image parameter ==

Should we depreciate the use of <code>|image =</code> parameter from the navbox, as a result for  [[Wikipedia:Navigation_template#Navigation_templates_are_not_arbitrarily_decorative]]. [[Special:Contributions/112.204.221.155|112.204.221.155]] ([[User talk:112.204.221.155|talk]]) 16:43, 11 September 2022 (UTC)
:No. "images are rarely appropriate in navboxes" means that sometimes they are appropriate. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:00, 11 September 2022 (UTC)
::When are they appropriate? I wondered about this last year at [[Template_talk:Navbox/Archive_23#"Purely_decorative"_images]]. I'm in favour of the images aesthetically, on most navboxes, but beyond basic visual design (relevant subject, distinguishable at a small size, maybe a transparent background) still don't have a clear idea of what a good, non-decorative navbox image would be.
::Somebody else boldly updated the template documentation at the start of that discussion to say that, in their opinion, {{tq|most of such images don't comply with MOS:DECOR and should be removed at sight}}, which is still there, and I've stopped trying to add images to navboxes since. --[[User:Lord Belbury|Lord Belbury]] ([[User talk:Lord Belbury|talk]]) 19:20, 11 September 2022 (UTC)
:::The second bullet point literally gives [[Special:PermaLink/995622594|an example]] of when it is acceptable. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 19:36, 11 September 2022 (UTC)

== TemplateStyles for plainlist ==

I've gotten to the point where I'm implementing plainlist as TemplateStyles (see [[MediaWiki talk:Common.css/to do#Plainlist]] for details) and I've done some work on Navbox to support it, since Navbox mentions the class. The consolidated diff is [https://en.wikipedia.org/enwiki/w/index.php?title=Module%3ANavbox%2Fsandbox&type=revision&diff=1127484687&oldid=1127299274 this change].

[https://en.wikipedia.org/enwiki/w/index.php?title=Module%3ANavbox%2Fsandbox&type=revision&diff=1127304988&oldid=1127299274 Part one of the change] makes it so that when Navbox sees the class <code>plainlist</code> in one of its class parameters (and later, <code>hlist</code>, when I'm to that point), it will emit plainlist TemplateStyles inside the <code>navbox-styles</code> div. I hope this will be a fairly limited function for this module in the interest of limiting how much this module needs to know about arbitrary styles as basically a big workaround for how many uses of this module invoke the raw list class, but it could be extended to arbitrary TemplateStyles classes with consensus. A version of it has been deployed at [[mw:Module:Navbox|MediaWiki wiki]] for a while. The test case at [[Template:Navbox/testcases#Horizontal/plain lists]] should give an idea of what happens.

[https://en.wikipedia.org/enwiki/w/index.php?title=Module%3ANavbox%2Fsandbox&type=revision&diff=1127484687&oldid=1127304988 Part two of the change] is something I've had on my mind for a bit. Right now, [[phab:T303378]] happens: in brief, MobileFrontend removes initial definitions of TemplateStyles if they're found there (as well as later references, but those are not an issue as they become <code>&lt;link></code>), at least in the mainspace (my personal test case page doesn't work any more because MobileFrontend seems to have stopped removing the div there entirely, at least in user space). The second change finds TemplateStyles strip markers and moves them to the <code>navbox-styles</code> div so that Navbox can guarantee styles haven't disappeared from mobile. (As a result, I have to remove <code>nomobile</code> from that div.) While Navbox particularly doesn't have a lot of worry about it ([[Module:Military navigation]] is probably the large exception in non-wide mode which most-often appears near the tops of articles; it should probably be using [[Module:Sidebar]]), I also plan to implement this in [[Module:Sidebar]], which currently does appear early in the document in most cases. I'm asking for someone to take a look and see if there's another way this could be done more efficiently than <code>find_hiding_templatestyles()</code> does now. (I am pretty sure I cannot avoid gsubbing the arg as this would introduce the literal same strip token twice.)

This second part is demonstrated at [[Template:Navbox/testcases#Save the TemplateStyles]].

I'd like to entertain adding one more change (cc @[[User:Frietjes|Frietjes]]) which is the change discussed earlier regarding sanitizing the inputs to the style parameters for Navbar. That was in the context of [[Template talk:Navbox/Archive 23#i18n and TemplateStyles improvements]]. It would be the reversion of [https://en.wikipedia.org/enwiki/w/index.php?title=Module:Navbox/sandbox&diff=1127299274&oldid=1088556247 this removal from the sandbox]. We had not deployed it for some reason I don't know and I think it would be a benefit.

There's probably a fourth change which should happen in the near term, which is getting all the rest of the styles out of the module and into the TemplateStyles page. You see a few of them there in the output of the testcases for change 2. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 00:48, 15 December 2022 (UTC)

:Parts 1 and 2 are now live for plainlist, though currently there's a bug on that front that I'll correct when I do hlist Soon. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 05:39, 26 December 2022 (UTC)

== Groupstyle vs Groupwidth ==

{{ping|Izno}} I would expect these to give the same result
{{navbox|title=Test 1|groupstyle=width:30em|group1=Group 1|list1 = List 1}}
{{navbox|title=Test 1|groupwidth=30em|group1=Group 1|list1 = List 1}}
but they don't.  we should either fix the css order, or add a tracking category to find/fix these? [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 20:05, 5 January 2023 (UTC)

:@[[User:Frietjes|Frietjes]], some thoughts, in a jumbled order, roughly progressing from easiest to hardest (but also toward most desirable):
:# The fix for this is trivial, just move <code>:css('width', args[cfg.arg.groupwidth] or '1%')</code> below the other declarations on the cell. (I don't understand why the ordering there is as it is or why groupCell is there a second time.)
:# We probably shouldn't have groupwidth. (There's an argument to keep groupwidth until #4 is done, which is that we can just turn support off somewhat arbitrarily when this template handles small resolutions.)
:# We probably shouldn't have the 1% inline style either. That's change 4 in [[#TemplateStyles for plainlist]]. (Take a look at change 3 while you're looking.)
:# We should mark all inline styles as deprecated in favor of TemplateStyles. :) That's blocked on #2. And should probably not be done until this template supports low resolution better, which is blocked on a grid version of this template. Which I have experimented with in [[User:Izno/Sandbox/Navbox]].
:So, yes is the answer to your question. :^) [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 23:29, 5 January 2023 (UTC)
:: {{re|Izno}} the reason for groupwidth is to align the widths of groups in different subgroups, but otherwise, I agree there is no need for it.  of course, that could also be potentially fixed with templatestyles.  can we add tracking for "width" in groupstyle or liststyle (including groupXstyle and listXstyle)?  I have cleaned up about 500 of them today using various regular expressions to find them.  thank you. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 23:33, 5 January 2023 (UTC)
:::I don't think we need to do any tracking, item 1 just fixes it (for now). I was imploring that you revisit your change (which is change 3 above) and/or that we should get all of the in-module styles out of the module as in change 4 (up there) and then we can make a marginally wider ranging change at the same time which also fixes the issue.
:::NB of course if those cases have survived without the parameter which avoids this bug and haven't caused complaints here, does this really need changing? :) [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 23:41, 5 January 2023 (UTC)
:::: when {{para|groupwidth}} is set, <code>width:100%</code> is omitted from the adjacent list cell. if you put the two examples in [[Special:ExpandTemplates]] you will see the difference. by "change 4" in [[#TemplateStyles for plainlist]], I am assuming you mean "extractcolor" for passing the color to navbar?  if so, yes, we should add that to reduce unnecessary css in the navbar.  it would also be fun to clean duplicate css (e.g., "background:white; background:black;" -> "background:black;") but I am not sure if it's worth the effort. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 18:20, 6 January 2023 (UTC)

== Formatting issue ==

Not sure this is worth fixing or can be fixed, but we came across a formatting issue.
The following code:
<pre>{{Navbox 
| title  = [[Barrie]]
| below = '''[[List of municipalities in Ontario]]'''
* [[:Category:Barrie|Category]]
}}{{Authority control|qid=Q4863550}}</pre>
looks like this:
{{Navbox 
| title  = [[Barrie]]
| below = '''[[List of municipalities in Ontario]]'''
* [[:Category:Barrie|Category]]
}}{{Authority control|qid=Q4863550}}
You'll see the problem with the formatting in the authority control template spread over 5 lines &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 08:12, 14 February 2023 (UTC)
:I don't think this is necessarily a problem with navbox. The authority control template, like many templates of its type, needs to be on a new line. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 15:44, 14 February 2023 (UTC)
::Unfortunately there is at least one script which removes these newlines, thus breaking the display. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 16:16, 14 February 2023 (UTC)
:::It sounds like we're having this discussion at the wrong talk page. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 16:49, 14 February 2023 (UTC)
::::Indeed, I don't see any reason why a script should  be removing these lines, but that is not an issue for this page specifically. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 11:02, 16 February 2023 (UTC)
:::::It might even be VE, see {{diff|Glasgow, Paisley, Kilmarnock and Ayr Railway|prev|1139927785|this VE edit}} that removed a newline whilst inserting a banner. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 14:04, 18 February 2023 (UTC)
::::::If it's VE, then we're pissing into the wind if we try to get it fixed. I'm still finding pages with nowiki tags all over the place and that's been a known issue for years now. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 15:19, 19 February 2023 (UTC)
:::::::Unfortunately, that is [https://phabricator.wikimedia.org/maniphest/query/PMifgvtgl3WE/ probably true]. It appears that the team that left Visual Editor in a perpetual beta state has moved on to Vector 2022 as the next big software project that they will leave 85% done. <small>Oops, sorry, my cynicism is showing! How embarrassing.</small> – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 19:37, 20 February 2023 (UTC)

== Initial visibility ==

The initial visibility seems to be stuck in the ''expanded'' state, as seen in articles with multiple navboxes (e.g. articles [[Safeway]], [[Star Wars]], etc). Forcing the parameter with <code><nowiki>|state=collapsed</nowiki></code> appears to do nothing, as multiple navboxes are still displayed fully expanded; the default ''autocollapsed'' is similarly ignored. I'm viewing the pages in desktop mode at 90% zoom (because at 100% zoom, [[Template:Reflist|Reflist]] no longer autodivides into columns). <span class="nowrap">&#8212;&#160;[[User:CJDOS|CJDOS,&#160;Sheridan,&#160;OR]]&#160;([[User talk:CJDOS|talk]]) 12:28, 6 April 2023 (UTC)</span>
:I am unable to reproduce this problem. At [[Safeway]], the Albertsons navbox is appropriately expanded, and the rest are collapsed. At [[Star Wars]], all of the navboxes are collapsed. As for Reflist, you are seeing the consequences of the Vector 2022 skin's excessive white space. I have modified my personal CSS to allow for wider content, which results in a three-column reflist for me on those (and most) pages. If you can't stand it, you could always change your Preferences (under Appearance) to go back to Vector 2010. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 14:25, 6 April 2023 (UTC)
::I wish to add that when I signed in just now, the Preferences page is no longer listed in a tab-like format, but instead as vertical boxes down the page. It didn't display like that previously (this year), even using the default Vector 2022 skin. So, there has indeed been some changes. I kept the default Vector 2022 appearance so that I would see what most people would see. I would like more input from editors who have ''not'' modified their selected skins, and I will give switching back to Vector Legacy serious consideration. Is there a list of editors who are critical of the Vector 2022 skin? <span class="nowrap">&#8212;&#160;[[User:CJDOS|CJDOS,&#160;Sheridan,&#160;OR]]&#160;([[User talk:CJDOS|talk]]) 17:18, 6 April 2023 (UTC)</span>
:::It works fine for me. Either your browser is not processing the JavaScript properly, or you have some custom setup which is incompatible with these pages. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 21:13, 6 April 2023 (UTC)
:::Answering my own question, yes, there is a page at [[mw:Talk:Reading/Web/Desktop Improvements]] for discussing the changes, and the 2022 skin. <span class="nowrap">&#8212;&#160;[[User:CJDOS|CJDOS,&#160;Sheridan,&#160;OR]]&#160;([[User talk:CJDOS|talk]]) 02:34, 7 April 2023 (UTC)</span>
::::Based on [[User:Redrose64|Redrose64]]'s suggestion, I tried viewing one of the exampled pages on an entirely different machine—everything seems to appear as it should, nothing weird of note. I haven't modified my skin nor added script, so it seems Wikipedia no longer supports my system. This thread may thus be disregarded; thank you for the replies. <span class="nowrap">&#8212;&#160;[[User:CJDOS|CJDOS,&#160;Sheridan,&#160;OR]]&#160;([[User talk:CJDOS|talk]]) 02:17, 7 April 2023 (UTC)</span>
:@[[User:CJDOS|CJDOS]], what OS and browser version are you using? [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:59, 13 April 2023 (UTC)

== Short-circuit in ternary expression at line 143 ==

This module has a mistake at line 143 ({{code|1=:attr('id', args[cfg.arg.title] and nil or mw.uri.anchorEncode(args[cfg.arg.above]))|lang=lua}}); this line attempts to output <code>nil</code> if <code>args[cfg.arg.title]</code> is truthy and otherwise {{code|1=mw.uri.anchorEncode(args[cfg.arg.above]))|lang=lua}}, but because <code>nil</code> is falsy, the <code>or</code> always triggers, and as such the line always short-circuits to {{code|1=:attr('id', mw.uri.anchorEncode(args[cfg.arg.above]))|lang=lua}}. {&#123;'''[[User:Lemondoge|Lemondoge]]'''&#124;[[User talk:Lemondoge|Talk]]&#124;[[Special:Contributions/Lemondoge|Contributions]]&#125;} 00:37, 13 April 2023 (UTC)
:{{replyto|Lemondoge}} Presumably you mean [[Module:Navbox]]. If not, please be specific. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 06:52, 13 April 2023 (UTC)
::Yes, it's [[Module:Navbox#L-143]] added in [[Special:Diff/846052229|diff]] on 15 June 2018 and then [[Special:Diff/1057332100|tweaked]] on 27 November 2021. {{ping|Matt Fitzpatrick|Izno}}, the OP is correct. Code <code>x and nil or y</code> is <code>(x and nil) or y</code> which is <code>nil or y</code> which is <code>y</code>. I remember trying to handle this operation somewhere—that is, trying to find a clean way of making <code>:attr(...)</code> add an attribute if a certain condition applied, but otherwise add nothing. I can't find what I did and don't have any suggestions at the moment. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 07:54, 13 April 2023 (UTC)
:Should be fine just to invert the logic which should short circuit correctly.
:<syntaxhighlight lang=lua>:attr('id', !args[cfg.arg.title] and mw.uri.anchorEncode(args[cfg.arg.above]) or nil)</syntaxhighlight> [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 17:30, 13 April 2023 (UTC)
::{{Done}} ({{code|:attr('id', (not args[cfg.arg.title]) and mw.uri.anchorEncode(args[cfg.arg.above]) or nil)|lang=lua}}) {&#123;'''[[User:Lemondoge|Lemondoge]]'''&#124;[[User talk:Lemondoge|Talk]]&#124;[[Special:Contributions/Lemondoge|Contributions]]&#125;} 13:49, 17 April 2023 (UTC)

== Colour accessibility of show/hide when using non-default background colour ==

Is it possible to change the navbox so that the show/hide option has sufficient colour contrast in cases where the navbox uses a non-standard background colour? There are many navboxes where it is hard to see it, for example with {{tl|Everton F.C.}}, where it would be helpful to either have a different text colour as has been done for the VTE links and title, or for show/hide to be displayed within a separate white/pale background. [[User:EdwardUK|EdwardUK]] ([[User talk:EdwardUK|talk]]) 00:19, 25 April 2023 (UTC)
:I suspect that you'd need to <del>modify [[Module:Navbar]]</del> <ins>amend the JavaScript that handles the <code>mw-collapsible</code> class</ins> rather than [[Module:Navbox]]. But have a look at how refs are handled by [[Module:Episode table]], see for example the last two column heders of [[Doctor Who (season 1)#Serials]].
:Alternatively, use a coloured border rather than a coloured background, see my comments at [[Wikipedia talk:WikiProject Geology/Archive 5#Colors]]. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 07:01, 25 April 2023 (UTC)
::I have had a look at the manual for collapsible elements on mediawiki and I can just about understand the coding for modules, but I think I would need to do a lot more research to work out the exact changes necessary. Though this may still be easier than suggesting to some (mostly sports) editors to make any changes to their navbox. However, for now the coloured borders seem like a good option that I can use. [[User:EdwardUK|EdwardUK]] ([[User talk:EdwardUK|talk]]) 13:56, 25 April 2023 (UTC)
: {{ping|TheDJ}} it looks respective styling in [[MediaWiki:Common.js]] needs to be adjusted in relation to [[phab:T333357]]. [[Special:Contributions/2001:7D0:88D7:B880:58B7:B8B8:B652:7E50|2001:7D0:88D7:B880:58B7:B8B8:B652:7E50]] ([[User talk:2001:7D0:88D7:B880:58B7:B8B8:B652:7E50|talk]]) 10:19, 28 April 2023 (UTC)
:Related: [[Template talk:Infobox station#"Collapsible" feature not working]] and [[Wikipedia:Village pump (technical)#I need help!]] --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 17:15, 28 April 2023 (UTC)

== Standalone navbox which can double as a child navbox ==
: {{courtesy link|fr:Modèle:Palette Shoah en France}}

This is both a question, and a note to self: we already have the ability to have a navbox which can either be used stand-alone in an article, or be transcluded as a child navbox of another nav template and work appropriately in both guises, but imho the feature is underused because the how-to isn't documented, and people aren't aware of the possibility. Does anyone know if there is a standard or conventional way already in use to format such a double-duty navbox? If so, we could just describe that. Either way, something should be added to the doc about it imho, because it is a very useful feature, but would probably be difficult for the occasional template coder to figure out on their own.

I think we could cover it in a new section, probably a subsection of {{slink|Template:Navbox/doc|Child navboxes}} called "Transclusion of child navbox" or some such. For a live example in the wild, see French navbox [[:fr:Modèle:Palette Shoah en France|Modèle:Palette Shoah en France]] (wd-linked to our [[Template:Holocaust in France]], which does not use the feature) which has two child navboxes ([[:fr:Modèle:Palette Shoah en France/Victimes|*/Victimes]] and [[:fr:Modèle:Palette Shoah en France/Survivants|*/Survivants]]), each of which may stand alone as a nav template, or be transcluded in another one.  As nothing new needs to be created to do this, it's exclusively a documentation issue to help those who wish to take advantage of the feature. In that regard, this is a "note to self", or to anyone else who feels like tackling it in the doc, as I have no idea when I'll be able to get back to it and wanted to record it here. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:27, 28 April 2023 (UTC)

== When will mobile visibility be fixed? ==

Please, please, it drives me close to tears with frustration every time I'm driven to the point of desperately changing every setting in my profile to no avail just to try to find a way to avoid the misery of switching my browser to desktop view, changing the URL to match, fiddling around with zooming and diagonal scrolling and everything to try to be able to click on the links, and then switching back to mobile to make the linked article actually readable which guarantees I'll have do the same thing again in ten minutes, every time I try to use a group of articles connected by navbox, or even every time an article seems like it ''might'' have one since there's no indication. What is the purpose of this nightmare? To avoid some relatively vastly less significant "problem" like horizontal scrolling or weird formatting? You'll notice that the forced desktop/mobile switching still involves the former, so you haven't even managed that. Whose terrible idea was this? [[User:Elliefint|Elliefint]] ([[User talk:Elliefint|talk]]) 01:36, 3 June 2023 (UTC)
:This is Phabricator feature request {{phab|T124168}} from 2016. From my reading of the objections, they are that navboxes increase the page size (in bytes) by about 10%, which was a problem in 2016. I don't see why it would still be a problem in 2023. Surely the capacity of everything that transmits bytes has increased by more than 10% in the intervening seven years. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 05:20, 3 June 2023 (UTC)
::It looks like many navboxes disappear when the screen is narrower than about 70 characters.  Try https://en.wikipedia.org/wiki/Michelle_Obama?useskin=minerva#External_links on a laptop/wider screen, and then change the screen width.  The navboxes are visible until the screen gets too narrow, and then they disappear.
::A 10% increase in page size will disproportionately affect people in developing countries.  Whether it's worth it depends primarily on how much benefit people get from the navboxes.  I don't use navboxes much, and I found it irritating just to scroll down far enough to find them in the Obama article. 
::@[[User:Elliefint|Elliefint]], there's a compromise option that might work for you.  It will require you to be logged in (and maybe also require keeping cookies).  
::Here are the steps:
::# Scroll to the bottom of the page and switch to desktop mode.
::# Scroll to the top.  If it says "Create account Log in" then log in.
::# When you're logged in, you'll see your username and a few icons.  Find [[Special:Preferences|Preferences]] in the menu.
::# Inside the preferences page, find the "Appearances" tab.  (It's the second one.)
::# At the top of the "Appearances" tab, there's a list of skins.  Pick "MinervaNeue".  (This is the name of the appearance normally used for the mobile view.  You're in desktop view [so navboxes won't be suppressed completely], but telling it to look like mobile view [so you can have almost the same appearance for reading].)
::# Scroll all the way to the bottom of the preferences page to find the blue button to save your change to your preferences.
::# Scroll back to the top and use the search box to go to a new article (anything you haven't seen today that seems like a big enough subject to have a navbox, such as a popular musician or a different country).
::# Now for the test:  Scroll to the bottom where the navbox should be.  If you don't see it, turn your phone sideways and check again.  If the navbox doesn't appear, use your browser controls to shrink the font size way down.  On my (small) iPhone, I have to set the font size to 50% if I'm holding my phone in the usual vertical position, or 85% if it's horizontal ...and the navboxes magically appear.  They don't disappear with a pinch-to-zoom maneuver, so I can then zoom in to read them.  After clicking, I can switch back to a normal font size.
::While this won't be perfect, it's possible that this will be less bad than what you're doing now.  If you decide that you don't like it, then of course you just undo the steps:  reset your preferences in the desktop mode, switch back to the mobile view, and carry on like you were doing it before. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 16:06, 3 June 2023 (UTC)
:::Thank you so much! I'm going to try this! (As for the point about the effect on users in developing countries, that's fair and definitely an important concern, but I do have to wonder if it's a more significant negative effect than that of blocking access to parts of articles for users on certain devices without these kinds of elaborate workarounds -- I'm thinking in particular of cases where the navboxes convey valuable information about the relationships between the current article and the articles linked therein, like the IPA chart navbox on phonetics articles. I don't know the answer to that without having the input of the users who would be most affected by larger page sizes and/or who don't have access to desktop devices, but I would be interested to hear that input.) [[User:Elliefint|Elliefint]] ([[User talk:Elliefint|talk]]) 16:32, 3 June 2023 (UTC)
::::It worked, thank you! [[User:Elliefint|Elliefint]] ([[User talk:Elliefint|talk]]) 16:35, 3 June 2023 (UTC)

== "[[:Template:Navboxrugby]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] ==
[[File:Information.svg|30px]]
The redirect <span class="plainlinks">[//en.wikipedia.org/enwiki/w/index.php?title=Template:Navboxrugby&redirect=no Template:Navboxrugby]</span> has been listed at [[Wikipedia:Redirects for discussion|redirects for discussion]] to determine whether its use and function meets the [[Wikipedia:Redirect|redirect guidelines]]. Readers of this page are welcome to comment on this redirect at '''{{slink|Wikipedia:Redirects for discussion/Log/2023 July 5#Template:Navboxrugby}}''' until a consensus is reached. <!-- from Template:RFDNote --> [[User:SWinxy|SWinxy]] ([[User talk:SWinxy|talk]]) 18:40, 5 July 2023 (UTC)

== Possible feature upgrade? ==

I was thinking about [https://templatetransclusioncheck.toolforge.org/index.php?lang=en&name= The Template Transclusion Check] earlier today, and wondered if there was a way to enable (opt-in, of course) a tracking cat in the navbox directly to check if the page a template is transcluded on is included in the navbox? I feel like I've seen similar things before in other modules, but if it's not possible that's fine I guess.

For example, a navbox {{t|example}} does not link to [[Example]] but that article transcludes the template. I was thinking this might be useful for "squad" navboxes where the navbox links may change but the transclusions often do not get updated to match. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 09:35, 24 August 2023 (UTC)
:Are you looking for {{tl|Check completeness of transclusions}}? Try it at {{tl|Watford F.C. squad}}, for example. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 12:33, 24 August 2023 (UTC)
::No, I want it to be part of {{t|navbox}} itself. To give a specific example - at the moment {{t|Top British male singles tennis players}} is transcluded at [[Paul Jubb]] but he is not listed in the template; I would like the option to have the navbox populate a category to indicate that the template should be removed from Jubb's page (e.g. ''Category:Tennis player biography with unnecessary navbox'' or something equally specific). [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 12:47, 24 August 2023 (UTC)
:::This sounds like a job for a report. The "check completeness" tool lives on toolforge. I wonder if someone clever could set up a periodic report that ran a check on every template whose doc page transcludes {{tl|Check completeness of transclusions}} and then listed "Transclusion but no link" items from those checks. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 13:39, 24 August 2023 (UTC)