Template talk:Navbox/Archive 20

Archive 15

←

Archive 18

Archive 19

Archive 20

Archive 21

Archive 22

→

Archive 24

"Sublists"(?) within a navbox group

I came across this template via Template:National sports teams of Japan. In this, a single bullet point * is used to delineate sports, and double points ** are used to list the various teams (e.g. men's and women's) within the sport. I noticed that an opening bracket is placed before the first item listed with **, but a corresponding bracket is not placed after the last item; there is a bullet point instead. On that particular template I have manually inserted a closing bracket at the end of each group, but there is still an issue of there being two bullet points sometimes separating items. Is this a problem that can be fixed? AtHomeIn神戸 (talk) 02:42, 18 November 2015 (UTC)

Now I have two round closing brackets. Before I had only one. Instead of solving things your intervention is making the situation worse, at least on my monitor. Carlotm (talk) 03:06, 18 November 2015 (UTC)

Really? The top line of the current version of Template:National sports teams of Japan (following my edit to it) displays like this for me:

American football · Association Football (F · M · MU-23 · FU-20 · MU-20 · FU-17 · MU-17) · · Australian rules football

Now that you mention it, I had never noticed the problem before on similar templates, so perhaps it is a problem with my display... AtHomeIn神戸 (talk) 03:17, 18 November 2015 (UTC)

• I've just had a look on my mobile and it was displaying correctly. So the problem must be with my browser. I'll revert my additions, but that raises a different question of why doesn't it display correctly. Perhaps this is not the correct forum for that question though. AtHomeIn神戸 (talk) 03:26, 18 November 2015 (UTC)

It seems that the double asterisk (**) is interpreted as to put under round brackets all characters that follow it until the next single asterisk. Unfortunately this interpretation is not always correct. To solve the problem we need simply to take out the double asterisks and put in place the normal round brackets whenever we want. I'll try this on my sandbox. Carlotm (talk) 03:54, 18 November 2015 (UTC)

By the way, thanks for making think about it more before I made it too much worse. AtHomeIn神戸 (talk) 04:04, 18 November 2015 (UTC)

You can look at it in my sandbox. But I will not change the current template because its layout for editing is much clearer. I would like to hear from others: if what happened to you is a larger issue, then we can make changes. (If you want to edit the template in my sandbox, you have to edit my sandbox page; otherwise you'll see the template in the current status). Cheers. Carlotm (talk) 04:26, 18 November 2015 (UTC)

It is the CSS for horizontal lists that generates the brackets for **. In normal lists, sublists are indented. Are you using Internet Explorer 8? IE8 will have javascript support removed soon, and in anticipation of that, I have removed some javascript that IE8 needs for proper display of the closing brackets. Please don't remove any ** because of this; that would create accessability issues by not using proper sublists. -- [[User:Edokter]] {{talk}} 11:58, 18 November 2015 (UTC)

Is this being fixed? I'm still seeing the problem in various templates with double asterisk (**) sublists. And I'm using IE8 due to restrictions I cannot circumvent. Is it really impossible to have this working on IE8? Donama (talk) 04:09, 23 November 2015 (UTC)

IE8 is deprecated across the Wikimedia enterprise at this point. It was working but now isn't, deliberately. @Edokter: Can you provide this person the .js for his common.js file? --Izno (talk) 12:03, 23 November 2015 (UTC)

You can find the CSS and JS snippets for it at mw:Snippets/Horizontal lists, and need to use an old version which still has the IE8 hack. I'd guess adding snippets to your user CSS and JS should do the trick. N.B. IE8 is officially obsolete everywhere (MS are dropping all support for it), and you really should be using something newer, as it will progressively become bad at rendering more and more websites, since web developers will progressively no longer care if things look reasonable on IE8 (these IE8-specific hacks are to workaround missing/broken features in it which cause modern HTML to render incorrectly). If it's a corporate policy that is forcing you to use IE8, then that policy is fundamentally broken at this point in time and really needs to change. --Murph9000 (talk) 15:54, 23 November 2015 (UTC)

Okay, fair enough. And you're right - use of IE8 a corporate limitation. For an employer of 168,000+ poor broken souls it is very fundamentally broken! Donama (talk) 01:05, 25 November 2015 (UTC)

Mobile navbox

Recently I have started to browse Wikipedia pages on mobile and encountered problem with Navbox. Yes, I saw the notice about its (mal)functioning when reading pages using mobile. On Polish Wikipedia this template is used mostly as a ready-to-show shortcut to a category pages. Lack of working Navbox is a major drawback for towns and villages, as it is (mostly) the single link to nearby villages. Wikipedia Mobile does not offer a direct link to neither other pages withing the same category nor the category itself. However, the German version ([1]) is shown on mobile devices in a correct manner (as a reader I mean visible, readable and clickable). Please consider an update.

An example of a navbox working as expected: [2] (look up for Einzelnachweise and below) Bonvol (talk) 20:33, 1 October 2015 (UTC)

I'd like to see this template working on mobile devices, but looks like even this german template is not working 100%, the image is cut in a half Maxtremus (talk) 01:20, 18 October 2015 (UTC)

Is there any update on this? Or can an alternative template be used? Wiki-uk (talk) 17:55, 4 January 2016 (UTC)

Inline CSS

Navbox has had a few snippets of static inline CSS (that is, it doesn't change regardless of parameter values unless the element it's styling simply isn't used in a given navbox) for many years now, probably dating back to its massive rewrite in 2008 or even earlier. Considering it's been styled via MediaWiki:Common.css since time immemorial, I've always been curious whether there were technical reasons preventing any of this inline CSS from being moved there. Is anyone aware of such problems, or are there none and this has simply never been looked at before? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 06:03, 2 December 2015 (UTC)

Basically, it's time for another rewrite/restyle, avoiding inline CSS alltogether. I have some ideas floating around in my head, but making them work with all the current navbox implementations is daunting. -- [[User:Edokter]] {{talk}} 11:55, 2 December 2015 (UTC)

Another editor and myself (mostly the other editor) did some work on a new version of Navbox several months back that replaces the current tables with divs and definition lists; while we never got anywhere near a drop-in replacement, what we did get may be of interest/use for informing your own ideas and work. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:53, 2 December 2015 (UTC)

Some interesting concepts there, but it has its shortcomings like needing set widths. -- [[User:Edokter]] {{talk}} 19:06, 4 January 2016 (UTC)

Data update problem

I use Template:Willamette River Steamboats in articles. When I finish an article covered by the navbox, I put the link in the navbox. However the navbox does not update across all articles. It only updates if the navbox is deleted from a particular article, and then retyped or cut & pasted back in, and then the article has to be resaved. There's a lot of articles, and it's not feasible to do this every time a new article is added to the navbox. Any suggesttions?Mtsmallwood (talk) 14:00, 18 January 2016 (UTC)

Relax, you most likely have encountered a standard MediaWiki feature, but equally a feature that constantly raises that issue. Changes to templates are not immediately reflected across all articles which use the template. The updates are added to the job queue, and the wiki server will eventually get around to them. How long depends on the size of the queue and how busy the server is. If you really need an update immediately for a particular article, you can WP:PURGE it, but should really only do that when necessary, as you are basically queue jumping and slowing down everyone else's updates. So, as long as it's not horribly broken in general, the correct thing to do is normally just to wait for the server to catch up. --Murph9000 (talk) 14:09, 18 January 2016 (UTC)

oh, that's good, afraid I was doing something wrong. I see now that the navbox updates eventually. You mean it doesn't happen by magic? ;-) Mtsmallwood (talk) 14:20, 18 January 2016 (UTC)

It basically is magic, just very slow magic. No miracles here. --Izno (talk) 14:40, 18 January 2016 (UTC)

list1 div with a note

I'm working on a module that is currently invoked from {{Football manager history/sandbox}}. It calls _navbox in Module:Navbox which is effectively using {{navbox}} for the result. There are over 1,000 navboxes using the system. Some of them have a note at the bottom, and that note is inside a div in some, and outside in others. I would like to know which it should be. In the call to navbox, the issue concerns the list1 parameter which is used like this:

| list1=<div>
*Line 1
*Line 2
<small>This is an example note</small>
</div>

In that case, the note is inside the div. The following shows the results from two simplified examples that use identical wikitext except that the second has the note outside the div.

The note (c) = caretaker manager is inside the div

The note (c) = caretaker manager is after the div

What difference does it make? Which should be used? The history of some of the navboxes show that they used |below= for the note at one stage, but the way it was done was pretty ugly, and the current small text seems fine. Johnuniq (talk) 09:34, 8 February 2016 (UTC)

There's also the option of not using any div at all. Not sure which is "best" though. -- WOSlinker (talk) 19:38, 8 February 2016 (UTC)

Groan, I see you are right and a preview shows that omitting div seems to give the same result. The navbox docs include "Format is inline, although the text can be entered on separate lines if the entire list is enclosed within <div> </div>." The fact that div is currently used and that the docs endorse it makes me think it has a reason, and I would like my module to generate the "correct" output. Johnuniq (talk) 22:18, 8 February 2016 (UTC)

Display issue on Chrome

Template:The Boat Race uses image and also imageleft. As you can see from the screenshot, (taken with Google Chrome) a lot of space is wasted. Removing the imageleft seems to sort the problem, but I wonder why Chrome does this? — Martin (MSGJ · talk) 12:52, 18 February 2016 (UTC)

I'm guessing it's the same problem previously reported at VPT. SiBr₄ (talk) 17:55, 18 February 2016 (UTC)

Yes, the suggested fix at Template talk:Navbox/Archive 18#Width having opposite effect seems to have fixed it for now. Needs a proper fix though really. — Martin (MSGJ · talk) 08:58, 22 February 2016 (UTC)

triple level lists

Sorry if this has been explained before. I was looking at Template:Android tablets and noticed that within the lists, it seemed like line breaks were randomly placed. Going through the source code, I noticed a pattern. Level 1 were prefixed with a ";" (semicolon), level 2 with a ":" (single colon), and level 3 with a "::" (two colons). Whenever level 1 followed a level 3 line ("::"), it started on a new line. Whenever level 1 followed a level 2 line (":"), it stayed on the same line. This leads to a random display with some lines having less than five items, but other lines having more than fifty items. What is the correct way to format this list to have a uniform display? Thanks, 15zulu (talk) 07:12, 11 March 2016 (UTC)

That's odd. It no doubt has to do with the hlist CSS... I will look to see if I can hack the template sometime today or tomorrow, since that's mostly correct. Good observation. Meanwhile... --Izno (talk) 12:55, 11 March 2016 (UTC)

@Izno: Have you had a chance to look at it? Thank you, 15zulu (talk) 02:44, 26 March 2016 (UTC)

You can't 'skip' levels as it resets the list, and ';' always start a new list, thus on a new line. You are using definition lists, and those are somewhat nitpicky when it comes to formatting. It is not a CSS issue, but a result of how Mediawiki handles lists. -- [[User:Edokter]] {{talk}} 11:19, 26 March 2016 (UTC)

I only came to the list because I noticed one item missing. However, while adding, I noticed the inconsistent line breaks. I wanted to fix the problem, but my knowledge ran short, so I came to this page hoping for a solution. ";" only starts new list after "::", not after ":". Back to my original question, what is the correct way to format this list to have a uniform display? Thank you, 15zulu (talk) 18:36, 26 March 2016 (UTC)

Alternatives for mobile users?

Navboxes and other templates using the navbox or vertical-navbox attributes are not displayed on the Mobile Web site for Wikipedia, which accounts for approximately 45% of readers. - From the main article, May 2016.

Are there any alternatives to Navbox that have similar functionality/layout, but are supported on Mobiles? I'm looking for something to use on an independent wiki, and our mobile users are likely to be 60-80%. juckto (talk) 00:21, 6 May 2016 (UTC)

The only reason mobile doesn't support it is because it's removed from mobile CSS. You should be able to re-add it just by tweaking your CSS. --Izno (talk) 00:37, 6 May 2016 (UTC)

Is HTML Tidy actually required?

The documentation says this template requires HTML Tidy to be turned on. However I've found a conversation in the archives that says it's not actually required anymore (though it's quite old, ~2011) and there are a few other similar and older discussions with mixed conclusions. So I was wondering if the current version does still have this requirement in order to be ported over other projects/wikis. Thank you. 93.57.251.180 (talk) 19:19, 6 May 2016 (UTC)

I don't think anyone really knows right now, but if you find it is no longer required, then please report back, so that this statement can be removed. —TheDJ (talk • contribs) 19:28, 6 May 2016 (UTC)

.navbox related common.css edit request

Just a heads up, I'm putting up an edit request for MediaWiki:Common.css shortly for the benefit of {{Portal bar}}, but the edit involves .navbox selectors. Old revision of User:Matt Fitzpatrick/common.css summarizes the edit request. The new CSS should resolve visual discrepancies in Template:Portal bar/testcases, but should not affect any part of Template:Navbox/testcases. Please let me know if you notice anything's gone wrong. Matt Fitzpatrick (talk) 23:20, 14 July 2016 (UTC)

Redundant whitespace

Hello! Please have a look at the {{Virtualization software}} template, which has a short triple-level list that produces redundant whitespace between closing brackets, after Virtuozzo and before FreeBSD jail (see also a screenshot). That whitespace seems redundant to me, not like something intentional, and the logic of {{Navbox}} template should be fixed not to produce such whitespace. — Dsimic (talk | contribs) 08:44, 4 July 2016 (UTC)

• cgroups-based
  • CoreOS
  • lmctfy
  • Linux-VServer
  • LXC
  • Docker
  • OpenVZ
    • Virtuozzo
• FreeBSD jail
• iCore Virtual Accounts
• Kubernetes
• Linux namespaces
• Solaris Containers
• Workload Partitions

Dsimic, are you sure it's a navbox issue and not a horizontal list issue? the styling of multi-level horizontal lists is controlled by MediaWiki:Common.css. Frietjes (talk) 20:42, 15 July 2016 (UTC)

This is an unavoidable artifact of browser suckage. --Izno (talk) 21:55, 15 July 2016 (UTC)

auto width broken

Just a heads up. It was reported at Wikipedia:Village pump (technical)#Long navbox template that my recent edit to Module:Navbox broke |style=width:auto.

• One fix is display:table on the div wrapper, which would be super easy, but would not work in IE6-7.
• Another fix is a new parameter to get the same visual effect, which may or may not work for IE6-7, will have to mess around in the sandbox tonight to see.

Any other ideas? Matt Fitzpatrick (talk) 22:20, 17 July 2016 (UTC)

In the specific case of {{Events by month links/box}}, rewriting the table dependent |style=width:auto; min-width:35em; as |style=margin-left:auto; margin-right:auto; width:36em; |style=width:36em; seems to fix the issue. Maybe this could also be a general solution for similar "width:auto" templates? Matt Fitzpatrick (talk) 22:44, 17 July 2016 (UTC)

Edit: Deleted margin declarations, redundant with common.css. Matt Fitzpatrick (talk) 04:10, 18 July 2016 (UTC)

Copying/translating a template from another wiki

I want to create an English version of fr:Modèle:Palette Grottes ornées. What's the best way to go about this? I should be able to deal with the translation issues, it's the technical issues I need help with. Thanks. Doug Weller talk 14:15, 24 July 2016 (UTC)

I've ported over the template syntax at Draft:Navbox_prehistoric_caves, so should just be a case of translating the text. Joe Roe (talk) 19:13, 24 July 2016 (UTC)

Fantastic. Doug Weller talk 14:57, 25 July 2016 (UTC)

Template-protected edit request on 29 July 2016

Hi! Some fellow Wikipedians asked me to help them create the "Navbox prehistoric caves", a draft is HERE. Predictably the navbox will grow soon and as far as i have read, the maximum number of groups that can be created is 20. Is there a more suitable template out there or can there an alternative Navbox be made, that does not restrict the number of goups? ATB Wikirictor (talk) 16:05, 29 July 2016 (UTC)

Wikirictor (talk) 16:05, 29 July 2016 (UTC)

You should consider re-structuring your navbox. A navbox of more than 20 groups is unlikely to provide the navigation desired by the common reader. I have some draft navboxes for musicians at User:Natalie.Desautels/sandbox/Classical and flamenco guitar templates#Modern era which might inform a navbox which doesn't need 20 groups for navigation. (Aside: The pictures should go since they don't aid in navigation and the flags should go per WP:MOSFLAG.) --Izno (talk) 16:17, 29 July 2016 (UTC)

Also,  Not done on your edit request. Though your desire is probably reasonable in some sense, it does not have consensus for a template under massive use. Please establish such a consensus. --Izno (talk) 16:18, 29 July 2016 (UTC)

Thanks for your clarifications. I will pass on your advice. ATBWikirictor (talk) 17:46, 29 July 2016 (UTC)

Wikirictor, In addition to Izno's comments...

• Would it help to split it into "Navbox prehistoric caves/Africa", "Navbox prehistoric caves/Asia"... and set "Navbox prehistoric caves" to transclude them?
• For specific help, and to ensure your efforts are consistent with other efforts, check at Wikipedia:WikiProject Anthropology and Wikipedia:WikiProject Archaeology. Have a look at how other articles & templates in that project area handle the problem. Both projects have an assessment tables that link to the templates in the project's scope.
• The first link from your navbox I tried was to Abîme, a generic geographical term rather than an actual location. You need to take care and double check all the links you're providing.
• Bear in mind, the purpose of a navbox is to assist in navigation. Keep your navbox to the essentials to serve that purpose and it'll more likely gain acceptance and widespread usage.

Hope that helps, for (;;) (talk) 16:36, 29 July 2016 (UTC)

Thanks a lot for your support and suggestions - i will pass these on as well. ATBWikirictor (talk) 17:51, 29 July 2016 (UTC)

Wikirictor, have you actually tried adding more than 20 groups? -- WOSlinker (talk) 17:41, 29 July 2016 (UTC)

Do you mean adding these above tags or an actual 21st group. Yes, tried the latter and it did not work. Thanks a lot anyway for your (and the others) quick and competent help. I will check out your snippet.ATBWikirictor (talk) 17:58, 29 July 2016 (UTC)

Wikirictor, {{Navbox subgroup}} is limited to 20 but {{Navbox}} is not. You can use Navbox with the |border=child option instead of Navbox subgroup. -- WOSlinker (talk) 19:33, 29 July 2016 (UTC)

width of the 'group' column

Please add a feature to adjust the width of the 'group' column, so that it won't be too narrow in some cases.--水水 (talk) 08:21, 28 September 2016 (UTC)

@水水: Have you tried the |groupwidth=9em option (adjust width to taste, and always use "em" sizes, so that it should adjust to minor variations in user fonts)? The normal use of that option is when you have multiple child navboxes, to match group width across them, e.g. Template:British Rail Coaches. Also, it might help to see an example where it is "too narrow", as it mostly works fairly well without specifying that (at least for reasonably simple and normal navboxes on English Wikipedia). Murph9000 (talk) 08:55, 28 September 2016 (UTC)

Thanks.--水水 (talk) 09:39, 28 September 2016 (UTC)

Empty navbox

Hello. Is it possible returning the navbox only if there is data? For example in {{Navbox with columns}} or in es:plantilla:Bases de datos taxonómicas:

Thanks, Juan Mayordomo (talk) 19:21, 14 October 2016 (UTC)

HTML Tidy

"Using this template on other wikis requires HTML Tidy to be turned on." Is the template going to be fixed not to require it, since Tidy will be replaced at some point? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:05, 3 November 2016 (UTC)

I'm actually fairly certain Tidy isn't required even now, since the entire template is generated using a module rather than the hack of wiki-text it used to be. However, once Tidy is finally switched off here in favor of the Html5 parser, we can check to see whether the Navbox was affected, and if not, updated the module and/or the documentation. --Izno (talk) 04:35, 8 November 2016 (UTC)

List separators

I'm not deeply into WP editing; I have tweaked a few pages here and there, but this looks way beyond my capabilities. Would it be possible to change the code here (or wherever it actually is - I'm not even sure it is here) to prevent lines in an inline list of links (such as foo · bar · baz · booger) from starting with a separator bullet? If this was regular markup, I'd just replace the spaces after the bullets with "nbsp"s, but it's obviously more complicated than that, and wisely, this template is protected from idiots like me who might accidentally destroy Wikipedia trying to improve it. 98.114.13.110 (talk) 19:27, 2 November 2016 (UTC)

I don't understand what you mean when you say prevent lines in an inline list of links. Can you clarify or provide a screenshot of the negative behavior you're experiencing? --Izno (talk) 11:34, 3 November 2016 (UTC)

I think you missed the point of that sentence. It's to prevent lines ... from starting with a separator. As I said, there's a lot I don't know about WP, including how to post a screen shot, but for Template:The Voice (U.S.), in my browser, at less than full screen, I see

Vicci Martinez · Frenchie Davis · Rebecca Loebe · · ·

· Serabee · Casey Desmond · Justin Grennan · · · ·

RaeLynn · Jesse Campbell · Chris Mann · · · ·

Katrina Parker · Erin Martin · Moses Stone · · · ·

and another misplaced bullet in front of Koryn Hawthorne further down the list. (And that's just one example; I've always noticed this Navbox formatting glitch, but recently happened to hit it several times in quick succession, and decided to see if I could do anything about it.) 98.114.13.110 (talk) 21:58, 5 November 2016 (UTC)

I see what you mean. I don't know if it can be coded into Module:Navbox but this might be solved by defining some rules for the linebreaks inside navbox group and subgroups. E. g. the separator bullets would have to be attached to the previous entry in the list. De728631 (talk) 04:38, 6 November 2016 (UTC)

(←) 98.114: This can't be fixed. From memory it's an issue with a still-supported version of Internet Explorer, but you can verify in the archives of either mediawiki talk:Common.css or in these archives.

@De7: It's an issue with browser renderings of certain CSS rules. --Izno (talk) 04:32, 8 November 2016 (UTC)

Izno: For the record, I believe the archived discussion you were intending to refer me to is this one, but I still don't understand how a difficulty with disabling word wrap within multi-word list items translates to an inability to swap the whitespace character(s) after a bullet for a nbsp when assembling these lists - but again, I'm sure the issues are way more complicated than I'm capable of comprehending. 98.114.13.110 (talk) 23:57, 11 November 2016 (UTC)

I'm using Firefox v. 49 and it also displays this rendering behaviour so it's not limited to early IE versions. De728631 (talk) 14:06, 12 November 2016 (UTC)

De7: Izno didn't mean that the bullet problem only occurs in old IEs; he meant (I think) that the fix they tried for the bullet problem had to be reversed because it caused other problems in old IEs. 98.114.13.110 (talk) 22:37, 12 November 2016 (UTC)

Header

@Johnuniq: Would it be possible to make it so that instead of having the V · T · E links and the [collapse] button affect the width of the title's <div>, the title could be enclosed in a <div> with margin-left: 50px; margin-right: 50px; like the {{Routemap}} header? (This would fix one of the issues listed at the end of the documentation, which I'm a bit surprised no one has bothered to fix in six years.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:26, 7 January 2017 (UTC)

@Johnuniq: It seems the issue doesn't exist, but I've modified the header anyway. Note that this change would require removal of several lines of site CSS (lines 345 and 360–364 in Common.css), because navboxes would no longer need the 6em padding from the V · T · E links or the [show]/[hide] button (the rules are currently affecting the display of the very narrow navboxes in the section above). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:38, 10 January 2017 (UTC)

I won't be able to think about this for a couple of days at least. I guess there is no rush? I will be working out how to test the results in Module:Navbox/sandbox with respect to Module:Navbox and will look at your changes later. Johnuniq (talk) 09:56, 10 January 2017 (UTC)

@Jc86035: I'm trying to understand your changes to Module:Navbox/sandbox. The old module (like the current Module:Navbox) had some code which switched off the navbar if the original template was Template:Navbox or Template:Navbox/sandbox. That does not happen for something like Template:Tools which uses Template:Navbox to display a navbox. The issue is illustrated by the following wikitext which renders as shown below.

{{Navbox
|title=Example
|group1=GROUP1
|list1=LIST1
|group2=GROUP2
|list2=LIST2
}}
{{Navbox/sandbox
|title=Example/sandbox
|group1=GROUP1
|list1=LIST1
|group2=GROUP2
|list2=LIST2
}}

The second navbox has V·T·E links while the first does not. Is that intentional? That is, is the sandbox doing what is wanted? Johnuniq (talk) 09:10, 16 January 2017 (UTC)

@Johnuniq: Should be fixed; I forgot to copy part of a line of code in removing the spacer code. (In addition, if the change is implemented and the CSS is changed, {{navbar-collapsible}} should also be modified to use Module:Navbar's collapsible function without any extra wikicode (see its talk page).) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:49, 16 January 2017 (UTC)

Row colour

(pinging Johnuniq) Is there a way to make the Lua code automatically colour the lists correctly when some of them are skipped? This would fix the row display of navboxes like {{Beijing Subway Station}}, which is never used with all of its lists. (I know it's probably possible, but I don't really know how this particular module works.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:56, 22 December 2016 (UTC)

This is possible, but we need to take into account |swap= if no others. --Izno (talk) 10:37, 22 December 2016 (UTC)

@Jc86035: I won't be able to do any thinking for a while. If I forget please try me again in a few days if still wanted. What should the sample a/b/c show? My guess is that the rows should alternate background color? What should the first color be? Presumably there are only two background colors, and the problem is that they do not alternate in the sample? What should swap do (or should I read the doc!)? Johnuniq (talk) 10:43, 22 December 2016 (UTC)

@Johnuniq: idk I just pinged you because you're good at Lua The sample should be light grey–dark grey–light grey, and swap (I think it's |evenodd=swap?) would probably make it start on dark grey instead. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:45, 22 December 2016 (UTC)

OK, I'll look at it later if not fixed by then, but I might need a reminder if things get too jolly here. Johnuniq (talk) 10:47, 22 December 2016 (UTC)

@Jc86035: I had a look and the required fix is simple. However I'm a bit reluctant to drop even a simple change into such a widely used module without some testing. Also, some points in the code could do with a cleanup and I would recommend changing the indentation style to use tabs. Module:Navbox/sandbox exists and currently has identical content with Module:Navbox but I can't see any testcases other than Template:Navbox/lua/testcases which is currently broken because it is using {{navbox/lua}} which breaks the mechanism that passes arguments to the module. I could create the testcases page copied from the fixed testcases, but someone would have to check that the results are correct and have a reasonable coverage of commonly used parameters.

The current module does some special processing for list1 which is mentioned in the template documentation as "For the image to display properly, the list1 parameter must be specified." I would like to change that so the special processing is done for the first list_n which might not be list1. That would be easy with the fix you requested, but I'm not sure if there would be any bad side effects. What do you think? Johnuniq (talk) 09:27, 23 December 2016 (UTC)

@Johnuniq: (pinging Izno) I'm not sure, although it seems to be a legacy of the pre-Lua template, as the image used to be hardcoded after the |list1= code and before |list2=. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:37, 23 December 2016 (UTC)

I'll wait and will probably set up the sandbox and testcases in due course although when is hard to predict at this time of year. Johnuniq (talk) 09:48, 23 December 2016 (UTC)

The test cases can be found in the template space at Template:Navbox/testcases. Naturally these aren't true programming test cases, but usually the template cases are sufficient for most programming on wiki. --Izno (talk) 10:49, 23 December 2016 (UTC)

Oops, don't know how I missed seeing that, thanks. I previewed my changes (without saving) and could see no differences except in the Missing parameter tests section. The new code displays the flag image despite List1 being omitted. It also uses the normal striping starting with the odd background instead of the even background currently used because the first item is List2. I might get bold later if no one knows a reason the new behavior would be unwanted. Johnuniq (talk) 22:18, 23 December 2016 (UTC)

Johnuniq and Jc86035, see Module:Navbox with striping, implemented in Template:Navbox with striping. I would be happy to see that merged (see this thread). and, on a related topic, we should merge Module:Navbox with nowrap lists. Frietjes (talk) 22:50, 23 December 2016 (UTC)

@Frietjes: What's the use case for making lists class=nowrap? I've tried using {{Navbox/sandbox3}}, but the hlist class is gone and when an item is wider than the navbox width it just goes off the page without giving the table cell a scroll bar. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:03, 24 December 2016 (UTC)

Jc86035, the idea isn't to make all hlist items nowrap, just when a flag is turned on. see Module:Team roster navbox and the pages that link to it. Frietjes (talk) 13:29, 24 December 2016 (UTC)

@Jc86035, Izno, and Frietjes: I put my changes in the sandbox module using three edits to show each step (clean whitespace, minor tweaks, change discussed above).

• Module:Navbox • Module:Navbox/sandbox • different (diff)

I could do more tweaks but that will do for now. We can think about the results in a couple of days. Johnuniq (talk) 07:26, 24 December 2016 (UTC)

@Johnuniq: Looks good. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:00, 24 December 2016 (UTC)

@Jc86035, Izno, and Johnuniq:, just make sure we don't entirely disable striping with subboxes, or there will be some complaints. this is why I had suggested that we have flag for turning this feature on, unless you have a way to detect this case. Frietjes (talk) 13:29, 24 December 2016 (UTC)

@Frietjes: Maybe have a tracking category for "pages with more than three lists wherein at least two are non-consecutive" (not templates, because some could be noincluded) and then use PetScan to find the category's intersection with (a) a tracking category for pages using Navbox with |child=yes and (b) transclusions of {{Navbox subgroup}}.

We also need to consider {{Navbox with columns}}, which skips |list2=. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:43, 24 December 2016 (UTC)

Jc86035, tracking is fine but you have to have a way to fix it after you find it. are we going to have something like |gap2=y to tell it that we are intentionally leaving 2 blank in the example above? Frietjes (talk) 13:46, 24 December 2016 (UTC)

@Frietjes: |matching=off? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:57, 24 December 2016 (UTC)

Jc86035, that wouldn't fix your original example where you want to have a gap between Line 14 and Line 15 due to the subgroup in Line 14. Frietjes (talk) 14:00, 24 December 2016 (UTC)

@Frietjes: I actually didn't notice that was there, but that does complicate things a lot. The easiest thing I can think of is to allow subgroup parameters like |list11.1= and |list11.2=, because the current structure of having {{Navbox subgroup}} inside it would mean that {{Beijing Subway Station}} would have to count its own parameters in its own template code to make the rows match. I thought of searching each parameter for the number of times the navbox-even and navbox-odd CSS classes are mentioned, but that would still leave the subgroups unmatched. There's also the option of using subpages like you/I did two years ago for {{MTR Light Rail routes}}, but that would also require more manual handling for any subgroups. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:35, 24 December 2016 (UTC)

Jc86035, the easiest thing I can think of is to have |skip2=yes or something similar, since that wouldn't require changing every navbox that uses subgroups. Frietjes (talk) 14:44, 24 December 2016 (UTC)

@Frietjes: The problem with doing that with {{Beijing Subway stations}} would be that the colour order would be wrong if either an odd or even number of rows were before the Line 14 subgroup, unless the number of rows before it were counted in {{Beijing Subway Station}} and then passed to the subgroup template. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:51, 24 December 2016 (UTC)

Jc86035, then add something like |rowspan2=2, but the subgroup would still need to know if it should have |evenodd=swap. Frietjes (talk) 14:52, 24 December 2016 (UTC)

@Frietjes: It's still a bit clunky though because you'd need to use {{#expr:}} to find the number of rows used above it and then determine if the number is odd to [de]activate |evenodd=swap in addition to using the skip/rowspan parameter. I guess it still is a pretty limited use case, so maybe {{Navbox with striping}} should be modified instead; and if sublist parameters are added it could be renamed to something more befitting its features. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:01, 24 December 2016 (UTC)

Jc86035, I am still for having Module:Navbox with striping merged, but we should just make this new feature optional and turned off by default. how about if we have |evenodd=auto to turn on the feature? over the long term, I would like to see |group1.1=, |list1.1= added as a feature, but until that happens. Frietjes (talk) 15:06, 24 December 2016 (UTC)

@Frietjes: Sure, okay. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:10, 24 December 2016 (UTC)

I have been contemplating the problem. A solution seems to need the bluesky plan mentioned above. If the following wikitext displayed the navbox shown, would it solve known issues?

{{navbox|state=expanded|title=Bluesky
|group1 = GROUP1
|group1.1 = GROUP1.1
|list1.1 = LIST1.1
|group1.2 = GROUP1.2
|list1.2 = LIST1.2
|group3 = GROUP3
|list3 = LIST3
|group4 = GROUP4
|list4 = LIST4
}}

The 1.2.3 notation would apply to parameters group + list + groupstyle + liststyle (for example, |list1.2.3style=whatever would be the style for |list1.2.3=text). The idea is that there would not be a need to nest navboxes so striping would work correctly. Is this worth investigating? I think it would work for {{Beijing Subway Station}}? Johnuniq (talk) 00:06, 31 December 2016 (UTC) Typo corrected. Johnuniq (talk) 05:07, 31 December 2016 (UTC)

@Johnuniq: This would definitely make template nesting less necessary (particularly if we managed to implement this in {{Navbox with collapsible subgroups}} and {{Navbox with columns}}), although I'm not sure how many layers should be possible (maybe 4 or 5?). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:03, 31 December 2016 (UTC)

I have some thoughts about some of this but haven't had the time to sit and look at it in detail. --Izno (talk) 14:42, 6 January 2017 (UTC)

Automatic striping

I put an experiment in Module:Navbox/sandbox which can be tried with {{navbox/sandbox}}. While contemplating the "bluesky plan" mentioned above I saw that it involves rather massive changes and would require all nested navboxes to be rewritten with a new "list1.2.3" syntax. And there are apparently lots of cases I am not aware of where different navbox templates are nested. So I looked for a magic alternative and came up with a simple idea—each navbox would use a unique marker to identify where an odd/even style is needed, and the outermost navbox would finish with a simple substitute that ensure rows strictly alternate odd/even/odd/even/... regardless of list numbers and subgroups.

It works well, but some problems can be seen at Template:Navbox/lua/testcases#Container tests where the original code starts each subgroup as an odd row, while the new sandbox code (used on that testcasts page) strictly alternates. I'll think about that, but I thought I would post to see if there are any ideas on whether this approach might be useful or not, if that glitch can be reasonably overcome. Johnuniq (talk) 10:53, 6 January 2017 (UTC)

@Johnuniq: I guess you could make it so that if a subgroup has a header, then the odd/even numbering resets? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:41, 6 January 2017 (UTC)

I added some code to detect a subgroup that has a title and the tests at Template:Navbox/lua/testcases now seem perfect. The nice point is that I edited the testcases page to remove all occurrences of |evenodd=swap so the results shown are automatic without any adjustments required. In fact the sandbox module ignores evenodd in subgroups. Lots more testing will be needed of course. Johnuniq (talk) 08:55, 7 January 2017 (UTC)

@Johnuniq: Thanks for updating the sandbox; it appears to work quite well (although it completely breaks when the template is substituted, which shouldn't really be a problem because that's not possible in the main version anyway). Are the unique marker characters output by the template, or are they replaced with the odd and even navbox classes? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:00, 7 January 2017 (UTC)

Here is some wikitext:

{{Navbox/sandbox
|title = Container test
|state = uncollapsed
|group1 = Group1
|list1 = List1
|group2 = Group2
|list2 =
 {{Navbox/sandbox|subgroup
 |title = Test title1
 |group1 = Group2.1
 |list1 = List2.1
 |group2 = Group2.2
 |list2 = List2.2
 |group3 = Group2.3
 |list3 = List2.3
 }}
|group3 = Group3
|list3 = List3
|group4 = Group4
|list4 = List4
}}

Following is what it looks like.

Pasting the above wikitext into Special:ExpandTemplates would show a perfectly normal table with no funny markers. However, trying that with the subgroup would show markers including the text _ODDEVEN_. The markers are removed by the outermost navbox.

 {{Navbox/sandbox|subgroup
 |title = Test title1
 |group1 = Group2.1
 |list1 = List2.1
 |group2 = Group2.2
 |list2 = List2.2
 |group3 = Group2.3
 |list3 = List2.3
 }}

See the wikitext at Template:Convert for what makes subst work. That was necessary for convert but I don't know if it would work here. Johnuniq (talk) 09:20, 7 January 2017 (UTC)

I see; I didn't realize Special:ExpandTemplates could handle modules (maybe they changed that sometime last year). @Frietjes and Izno: thoughts? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:32, 7 January 2017 (UTC)

@Johnuniq: Do you think it's ready to be put into the main version? —Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:19, 27 January 2017 (UTC)

@Jc86035: I guess so but off-wiki chaos has distracted me in the last few weeks and I won't be able to put quality thinking time into this for a while. The only issue I am aware of is that if the "subgroup" (or equivalent "child") parameter is used, the output will contain markers. If a subgroup navbox is inside a normal navbox, the markers will be replaced by the outermost navbox, and all will be good. However, if some other template/module embeds a subgroup navbox, the markers would be a big problem. I'm hoping that people familiar with how navbox is used would be able to say whether that problem is likely to occur.

To clarify the potential problem, the following works if sometemplate is "navbox", but fails if it is anything else:

{{sometemplate|...{{navbox|subgroup|...}}...}}

Parameters child and subgroup are equivalent, so the above is a potential problem with child as well.

If no one is sure whether sometemplate is always "navbox", we could just switch over and revert if a problem is found. I was hoping to examine a dump of all articles to see how navbox is used, but I won't have time for that. If we do switch over, please note a couple of pages where the current striping is not correct and see if (after purging) the change fixes the problem. Johnuniq (talk) 01:06, 28 January 2017 (UTC)

@Johnuniq: Maybe two tracking categories could be added listing (1) pages with child/subgroup navboxes and (2) pages with normal navboxes, and then intersected in PetScan? There are definitely some templates, like {{Paris Metro/line 13}}, which would end up broken. Possibly we could add a parameter |parent=yes or something which forces a child navbox to strip the markers inside it. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:18, 3 March 2017 (UTC)

@Jc86035: I wonder why {{Paris Metro/line 13}} has two child navboxes but no parent. Its wikitext might have been correct at one stage, but I think it is currently somewhat broken because {{Navbox|child=yes|border=child|...}} has child=yes which I believe would be ignored (the parameter should just be child). At any rate, having child as the first parameter is exactly the same as having border=child, so the invalid syntax does not matter. I can't work out what's going on at the moment. I tried a preview using navbox/sandbox and it seemed to give identical results—perhaps my attempt at previewing with navbox/sandbox was broken. I'll think about the issue. Please ping me if I seem to have forgotten because things are still hectic in RL. Johnuniq (talk) 10:06, 3 March 2017 (UTC)

@Johnuniq: I added the child navboxes in 2015 when I was going through a bunch of Paris transport-related templates. I think the reason the display doesn't change is because I manually added the background colours in |liststyle=, since I wanted the two adjacent child navboxes to be dark and the rest of the list to have a light background (and probably didn't understand how to use |evenodd=). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:42, 3 March 2017 (UTC)

Should all of the templates in that group be converted to regular navboxes? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:47, 3 March 2017 (UTC)

@Jc86035: I'm starting to think about this (and will contemplate your last comment later). One thing I noticed is that putting {{Paris Metro/line 13}} into Special:ExpandTemplates shows a problem. There is an initial <div...>...</div> which is ok. But then there is an unmatched </div>. Also, at the end there is an unmatched <div>. I guess that ends up in articles? Johnuniq (talk) 07:16, 4 March 2017 (UTC)

@Johnuniq: Probably an artifact of Module:Navbox expecting a parent {{Navbox}} (or another subgroup) rather than a random table. The lack of weird display problems is probably due to both of them being inside a table without any other div tags. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:24, 4 March 2017 (UTC)

Orphan navboxes

@Jc86035: Continuing our discussion from just above, I'm not confident the tracking categories you added to Module:Navbox will be effective. For one thing, that module has code like the following:

if border == 'subgroup' or border == 'child' then ...

whereas your addition tests only for 'subgroup'—I believe 'child' navboxes would not get the subgroups category.

A more fundamental issue concerns what the categories would do. The 2.8 million pages with a navbox may never be updated for the new category unless they are edited. Even in three months from now there will likely be over a million pages without the categories. What if a page contains two navboxes, one with a subgroup and one without? Is the intention to find all pages in Category:Templates containing navbox subgroups which are not also in Category:Templates containing navboxes?

I was playing around with what {{Paris Metro/line 13}} outputs using Module:Navbox/sandbox and it may not be badly broken in appearance despite having the markers. I have been thinking of whether the sandbox module could add a category to a child navbox, and then have the parent navbox remove that category when it is fixing the striping markers. I was thinking of suggesting Category:Navbox orphans to indicate pages with a subgroup and no parent. A new parameter might be included so the orphan navbox could be changed to say "it's ok, this navbox is intentionally a child with no parent—fix the striping markers and do not output the category". That would be needed if we found a valid usage for orphan navboxes. Johnuniq (talk) 03:16, 6 March 2017 (UTC)

@Johnuniq: That seems like a better idea, although the default striping might be broken. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 03:28, 6 March 2017 (UTC)

OK, I'll continue slowly thinking and hopefully will do something real soon now... Johnuniq (talk) 04:05, 6 March 2017 (UTC)

@Jc86035: Module:Navbox outputs a tracking category only on template pages. For example, Category:Navigational boxes without horizontal lists contains Template:Cairo Open tournaments and that template is used in 1975 Cairo Open. The hidden category is on the template page, but not on the article.

What should happen with the proposed Category:Navbox orphans? This category would be added by child navboxes but removed by a parent navbox. Therefore, the category would appear only on pages where a child navbox does not have a parent. Should the category apply to all pages or just templates? My feeling is that it should be all pages because an article might use {{navbox|child|...}} in its wikitext and that should be recorded in the category. The drawback to tracking all pages is that if a template uses an orphan navbox, all articles using the template would be in the hidden category. Thoughts? Johnuniq (talk) 09:39, 6 March 2017 (UTC)

@Johnuniq: I think it's fine to show it in articles if the module can sort the category by namespace. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:21, 6 March 2017 (UTC)

@Jc86035: I updated Module:Navbox/sandbox to add Category:Navbox orphans to all pages with a child navbox that is not contained in a parent navbox. I need to do some testing and thinking to work out if it is ready for release, but I think it is—after carefully checking of tests! I did not initially understand your "sort the category by namespace" but now I see that you probably mean that the category should have a sort key. That's messy. Let's leave it and see if it is needed. There is an API that will list pages in a particular namespace in a category and it can be used if needed. Johnuniq (talk) 04:52, 7 March 2017 (UTC)

I changed the sandbox module to accept parameter |orphan=yes to not add the orphan category and to fix odd/even markers in a child navbox. The other templates in doc need to be considered. Johnuniq (talk) 07:16, 7 March 2017 (UTC)

@Johnuniq: I think it's probably going to work without changes to the other templates, because they all transclude {{Navbox}} anyway. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:09, 9 March 2017 (UTC)

Style question

It seems that I remember this template automatically putting Below-field text in boldface type; however, I don't see that in the most recent renditions of the pre-Lua navbox template. I ask this because my recent feeble attempt to place the Below-field text in boldface type in the {{Science fiction}} navbox (I should have used the |belowstyle=font-weight:bold; parameter, but instead I used Wikimarkup apostrophes) was reverted by editor Robsinden, who seems to do a lot of template work. It would be easy enough to make the boldface type standard in navboxes in the same manner as it is in sidebars just by adding the code :css('font-weight', 'bold') as line 159 at Module:Navbox. After being reverted, I now wonder if that is actually what other editors want. Should the boldface type in the Below field be standard? I would say yes, so I thought I'd raise this style issue here to see what others think.  Paine Ellsworth  ^{put'r there}  07:13, 4 March 2017 (UTC)

I think bolding it gives WP:UNDUE weight on the importance of these links, when actually, these are the least important links on the navbox (especially the category links, which to my mind are superfluous, as you would expect most of the articles in the navbox to already be in the category anyway). --Rob Sinden (talk) 08:51, 6 March 2017 (UTC)

I think you have a valid argument even though I think the Below area should be consistent with the other more heavily shaded areas. The more I look at it though, the more I can appreciate your rationale. To be consistent, we should then consider removing the "css bold" code from the sidebar module, as well?  Paine Ellsworth  ^put'r there  15:18, 10 March 2017 (UTC)

Separate discussion for the sidebar talk page either way. :D --Izno (talk) 16:12, 10 March 2017 (UTC)