Template talk:Navboxes

Succession boxes: incorrect border

Does anyone know how to fix the formatting at Template:Navboxes#Succession boxes? Once expanded, the horizontal lines are all coloured white instead of grey.--Nevé–selbert 21:14, 4 June 2017 (UTC)

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. Ahecht (TALK
PAGE) 22:02, 4 June 2017 (UTC)

@Ahecht: Neve-selbert means that in the following two examples:

the horizontal border separating the rows is clearly a kind of mid-grey   (actually #a2a9b1) in the first example, whereas in the second it has an unexpected colour, almost (but not quite) white   - being #fdfdfd which is an extremely pale grey (although the border might appear to be absent, it is in fact present). It seems that this CSS rule:

table.wikitable > tr > th,
table.wikitable > tr > td,
table.wikitable > * > tr > th,
table.wikitable > * > tr > td {
  border: 1px solid #a2a9b1;
  padding: 0.2em 0.4em;
}

is being overridden by this rule:

.navbox-spacing-temp.navbox tr + tr > th,
.navbox-spacing-temp.navbox tr + tr > td,
.navbox-spacing-temp.navbox-subgroup tr + tr > th,
.navbox-spacing-temp.navbox-subgroup tr + tr > td {
  border-top: 2px solid #fdfdfd;
}

I am certain that this is a consequence of this proposal, and I have dropped a note there. --Redrose64 🌹 (talk) 08:32, 6 June 2017 (UTC)

Yeah, that's it. The plan was to get rid of .navbox-spacing-temp at some point. That'd be a good time to tighten up the selectors:

.navbox-inner > tbody > tr + tr > th,
.navbox-inner > tbody > tr + tr > td,
.navbox-subgroup > tbody > tr + tr > th,
.navbox-subgroup > tbody > tr + tr > td {
  border-top: 2px solid #fdfdfd;
}

Should stop nested tables from being affected. Matt Fitzpatrick (talk) 03:37, 7 June 2017 (UTC)

Thank you.--Nevé–selbert 15:59, 7 June 2017 (UTC)

I broke it, but I can't take credit for fixing it! User:Ahecht fixed {{S-start}} with an inline style border. I've requested a fix to the site CSS, so with luck that'll go in soon and avoid similar problems in other templates. Matt Fitzpatrick (talk) 23:34, 7 June 2017 (UTC)

Site CSS was updated a few hours ago. It no longer applies the light gray border to tables nested inside navboxes. Should be safe to revert the {{S-start}} fix. Matt Fitzpatrick (talk) 19:13, 16 June 2017 (UTC)

Thanks! I went ahead and reverted the workaround that I put in place on the succession box templates. --Ahecht (TALK
PAGE) 15:25, 8 July 2017 (UTC)

Background color

Proposal withdrawn

I would like to go to a slightly different default background color: #e8ddff (prev. #e8e8ff). Feel free to remark here in this discussion, or, if strongly against, to revert to the previous background.  Paine Ellsworth  ^put'r there  07:47, 19 December 2017 (UTC)

@Paine Ellsworth: The new color is too purple-ly... Can you explain your reasoning behind the change? Right now I'm against the change. Corky ^{Buzz by the Hornet's Nest} 22:59, 19 December 2017 (UTC)

To editor Corky: Thank You, and I do realize the need for general subtlety in the bg color; however, for a long time now, I've been thinking that the present bg color appears a little too faded and pale. So I thought I'd give it just a little more color. It's not a big deal, of course, as I've been thinking about this for a few years now.  Paine Ellsworth  ^put'r there  09:20, 21 December 2017 (UTC)

Thank you for the explanation. I know it's a bit pale, but personally, I would prefer a more neutral color... like a light grayish color. Corky ^{Buzz by the Hornet's Nest} 22:15, 21 December 2017 (UTC)

And please set up a demo showing navboxes with the two colors. Johnuniq (talk) 06:22, 21 December 2017 (UTC)

To editor Johnuniq: Thank You for asking! I've set up the sandbox with the comparison.  Paine Ellsworth  ^put'r there  09:20, 21 December 2017 (UTC)

Any chance of a page somewhere showing two navboxes, one traditional and one proposed? Your link shows a diff which would need quite a lot of confidence to interpret. Johnuniq (talk) 09:40, 21 December 2017 (UTC)

I'm just not sure what is needed beyond the comparison in the sandbox. The only reason I used the diff template was in case another editor were to edit the sandbox. The diff provides a permanent record of the comparison, and the comparison shows both the traditional navbox bg color and then my proposed bg color just below the traditional one. The two navbars are also seen in the "Sandbox" section of "Test 1" on the test cases page. Please explain in detail exactly what more you need.  Paine Ellsworth  ^put'r there  10:17, 21 December 2017 (UTC)

Oh. Sorry, that's my banner blindness. I skipped over the diff and stopped skipping at the first navbox I noticed, which is in the documentation. I'm watching this page due to having done a major refactor of the module and I hope some others will check the rationale for the color. Johnuniq (talk) 10:30, 21 December 2017 (UTC)

No worries, I've altered the sandbox to place the comparisons closer together and erased the /doc page. Hope that helps.  Paine Ellsworth  ^put'r there  11:09, 21 December 2017 (UTC)

@Paine Ellsworth: Please confine Template:Navboxes/sandbox to the proposed version, it should not contain the current version as well. Side-by-side (or one-above-the-other) comparisons may be done at Template:Navboxes/testcases; more at WP:TESTCASES. A benefit of this approach is that you can see what it looks like in articles by going to an article and altering {{Navboxes}} to {{Navboxes/sandbox}} and previewing. Then there are all the links at the bottom of the green documentation box which only work as expected if the sandbox and testcases are set up in the normal manner. --Redrose64 🌹 (talk) 20:51, 21 December 2017 (UTC)

The change in the sandbox has been made.  Paine Ellsworth  ^put'r there  01:52, 22 December 2017 (UTC)

@Paine Ellsworth: As you know, {{Navboxes}} is template protected, and you used your template editor permissions to make this change. Per Wikipedia:Template editor, "slightly tweaking something's color" is listed under "Changes that require at least some discussion, or at least several days passing with no one commenting on your proposal". The opportunity for discussion should've happened before you made the change. Personally, I oppose the change and agree with Corky — it's too purple-ly. If anything, I think the navboxes should be less saturated (something like #EAECF0) --Ahecht (TALK
PAGE) 21:51, 21 December 2017 (UTC)

Apologies if I broke with protocol, Ahecht; however, I just don't see in that quote where the proposal must wait until after discussion. Just didn't think it was that big a deal – an obvious error on my part. Happy Holidays to All!  Paine Ellsworth  ^put'r there  01:52, 22 December 2017 (UTC)

V·T·E links?

Any idea if there is a way to add the View/Talk/Edit links to the top left like a normal {{navbox}}? I don't see any option for this in the documentation, but maybe I'm missing something? - Paul^T+/_C 03:00, 2 April 2018 (UTC)

Psantora, at the moment, there is no option. Generally, this template is used directly in articles, so V-T-E links are not needed. If you want to use this as part of a template, there are usually better options. Thanks! Plastikspork _―Œ^(talk) 16:17, 2 April 2018 (UTC)

Hi Plastikspork, thanks for the response. I understand that usually this template is used directly in articles, but I know of at least one example (and I bet there are more) where it is used in a template to include multiple related templates with just one transclusion. In the case of Template:ARM-based chips, it could make sense to have separate V-T-E links since it is a standalone template that includes 3 other templates. In theory this should be possible to do, right? - Paul^T+/_C 17:00, 2 April 2018 (UTC)

Psantora, yes it's possible to modify this template to add V-T-E links to the wrapper template. However, since the content is in the other 3 templates, it's probably better to just have edit links to the other 3 templates. Also, it looks to me that Template:ARM-based chips is being overused, since in most cases only one of the three subtemplates is needed at the foot of the article. Thanks! Plastikspork _―Œ^(talk) 17:50, 2 April 2018 (UTC)

By the way, this tool is a great way to analyze this "lack of bidirectionality" by showing places where the navbox is transcluded, but there is no link to that article in the navbox. Thanks! Plastikspork _―Œ^(talk) 17:53, 2 April 2018 (UTC)

Why is there a closing span tag in list1= ?

Does anyone here know why editors would have put a </span> tag at the beginning of |list1=, as in Victoria's Secret#External links? There are a few hundred instances of this tag, which are causing a "Stripped tag" (closing tag without an opening tag) Linter error. – Jonesey95 (talk) 03:35, 13 December 2018 (UTC)

Warning

This template should come with a health warning because if you have so many Navboxes that you need to subgroup and hide them that you almost certainly have too many Navboxes.

Navboxes seems to get away with being included indiscriminately, held to none of the standards we would require of a single link if it was in in WP:SEEALSO or WP:EL -- 109.79.86.113 (talk) 12:30, 13 September 2019 (UTC)

I'm serious, ordinary Navboxes are junk and these Navboxes to contain other Navboxes are another layer of awful and should come with warnings against their usage. We have guidelines against unnecessary links, we warn editors against indiscriminately every genre or category they can think of and we have MOS:DONTHIDE. Yet somehow we have this template which not only encourages editors to add even more unnecessary barely relevant Navboxes it makes it worse by hiding the linkdumpster under another layer of templates and ignores all the principles that seem to apply elsewhere. (The fact that mobile wikipedia doesn't bother with them at all is further evidence of how entirely non-essential they actually are.)

This template should come with a warning discouraging editors from using it, at least gently suggest to editors that maybe if they're hiding and subgrouping Navboxes the answer might be less Navboxes. Please improve the documentation to encourage editors to show some small amount of restraint when using this Navbox subbox in particular. It is bizarre when an article has more content hidden in Navboxes (and sub Navboxes) than it does in the article itself, and maybe there are exceptional articles that really do need more than 10 Navboxes but they should not be added indiscriminately then hidden away. -- 109.79.168.251 (talk) 14:57, 14 September 2019 (UTC)

Even something as simple as improving the examples or suggesting that maybe it is a good idea to avoid deep sub sub layers, (great that it is possible, not such a good idea to actually do it) but as it stands now this article tacitly encourages the behavior. (Look for yourself, open the examples all the way, and tell me you really think having a sub sub layer about political "Alliances" is really a good way to arrange anything.) -- 109.79.168.251 (talk) 15:06, 14 September 2019 (UTC)

Stop deleting Talk page comments. I'm not merely expressing my opinion about Navboxes in general but in this template in particular making the problem worse because it implicitly encourages too many Navboxes, and hidding Navboxes. -- 109.79.169.24 (talk) 11:29, 15 September 2019 (UTC)

This is not the right page to discuss whether this template should exist. If you would like to nominate it for deletion, please follow the instructions at Wikipedia:Templates_for_discussion. – Jonesey95 (talk) 18:27, 15 September 2019 (UTC)

I didn't say it shouldn't exist (maybe it shouldn't) but that it should include documentation or warnings to editors to consider not including so many Navboxes before using this template. I'm skeptical but I suspect there are some cases where this template might actually be necessary. -- 109.79.169.24 (talk) 20:53, 15 September 2019 (UTC)

This is a wiki. Documentation pages for templates are almost never protected. If you make an edit and nobody objects, your edit will remain. If you make an edit and someone objects to it and reverts it, you can discuss it further here. So far, what I see is a lot of words, but no concrete proposal for changing this template's documentation. If you want to propose a change, one good way to do it is in the form "I believe that we should insert the following text after the sentence that ends 'foo bar': 'Blah blah blah etc.'" – Jonesey95 (talk) 03:56, 16 September 2019 (UTC)

I'll need to give it more thought to come up with a specific wording. I thought people with an interest in this template might have insight about the particular cases and maybe respond and say why this template was actually good or necessary, or why it really was reasonable for articles to have more than ten Navboxes or any number of Navboxes large enough that this kind of repeated subgrouping and hiding was a good idea. The indiscriminate proliferation of Navboxes seems very much in contrast to other cases where editors make efforts to be more selective, such as genres, categories, WP:SEEALSO, or WP:EL. (Oh and MOS:DONTHIDE)

So far what roughly what I would propose is

“ Less is more. Before using this template to group navigation boxes together, consider carefully if a page needs to include more than a few Navboxes that are most relevant to the primary topic of the article. ”

That's a rough first pass. I'm not as optimistic about adding to articles and not expecting to be reverted if things haven't been discussed. WP:NAVBOX says "All articles within a template relate to a single, coherent subject." but some editors have a very expansive interpretation of words like "single subject" and "coherent" mean (example: Teen Titans Go! To the Movies has more than ten hidden at the end of the page, but only the one that isn't subgrouped using {{Navboxes}} seems like it is of primary relevance.) I think I will need time to dig deeper and read more of the guidelines (and talk page archives), because if it was me reading the documentation and trying to decide what "relevant" means I would want the documentation link back to something like WP:NAVBOX or elsewhere to help make it clearer, make decisions easier, and disputes easier to avoid or resolve.

At this point it would also be instructive to see examples of articles where {{Navboxes}} really was needed to organize and structure large numbers of Navboxes into groups, and weren't just being used to hide excessive Navboxes, and sweep the mess under the rug. -- 109.79.84.100 (talk) 23:00, 16 September 2019 (UTC)

Thanks Jonesey95 for directly addressing my suggestion. Wikipedia often changes small pieces at a time, and I dont think it is unreasonable to try urge a little caution against the worst cases of too many Navboxes (sub sub Navboxes) and not be expected to take on the whole policies of Navboxes in general. The short bit of quoted text above says pretty much what I think, and a small extra bit of text like that is all I'm looking for, not a large banner or a huge policy debate. Rejecting discussion and saying I have to take on much larger Navbox policies in general seems like a very indirect way of saying no a small incremental change that I believe is in keeping with existing principles and guidelines. If people think the suggestion is so bad then say so, or if think it is acceptable then say so. -- 109.78.197.121 (talk) 23:44, 18 September 2019 (UTC)

• Warning: Template talk pages, like article talk pages are WP:NOTAFIRUM for general discussion about the subject matter, they are solely for discussing potential improvements in the template. FORUM-like discussion are subject to deletion at anytime, per WP:TPO. Beyond My Ken (talk) 04:37, 16 September 2019 (UTC)

It is exactly because of the Wikipedia:Talk page guidelines that warn editors against deleting other peoples talk page comments, that I was so surprised to have my comments deleted. My complaints are about Navboxes in general but also about usage of this template in particular as exemplifying and encouraging the worst cases of excessive Navboxes, I don't think WP:NOTAFORUM applies. Disagree with me, ignore me, but my comments are on topic and I don't think deleting was an appropriate reaction in line with the Wikipedia:Talk page guidelines or WP:GOODFAITH. -- 109.79.84.100 (talk) 23:00, 16 September 2019 (UTC)

You are not discussing the improvement of this template, you are attempting to discuss how this template is used. That is not a matter for this talk page. Please go to WP:VP and open a discussion there. Beyond My Ken (talk) 23:22, 16 September 2019 (UTC)

I'm talking about making a small change to the documentation on this page, to include a short cautionary warning. If people can agree to a small change similar to what I am suggesting above, then I don't need (or particularly want) to get into larger general discussion at this time. -- 109.79.84.100 (talk) 23:47, 16 September 2019 (UTC)

That still needs to be discussed elsewhere, not here. You first have to establish the need, which you have not done (you personal opinion not being relevant), and then get a broad consensus for it. You don;t get that here, you get that at VP. Beyond My Ken (talk) 23:55, 16 September 2019 (UTC)

If we are to provide some such warning, it ought to be shown at WP:NAV and also WP:NAVBOX. So a discussion in a central place - like WP:VPR - is far better than this template talk page. --Redrose64 🌹 (talk) 09:19, 17 September 2019 (UTC)

Maybe "warning" was too strong a word, that implies more than I intended, which I suppose you could call a minor edit to the documentation. To show exactly what I mean I decided the most practical thing was to make an edit, I don't think it is a bold change to suggest that editors keep the Navboxes relevant. -- 109.78.197.121 (talk) 23:50, 18 September 2019 (UTC)

I've reverted your edit to the template doc; That something like that needs to be added is only your opinion, you have not established any consensus for it. In fact, I can't see that anyone has agreed with you yet. Please do not re-add it without a consensus, such behavior is WP:DISRUPTIVE and can lead to being blocked from editing. See WP:BRD. Beyond My Ken (talk) 00:00, 19 September 2019 (UTC)

Embedding tables into Navbox

Neither the hlist nor the column format are useful for what I am attempting, which is to incorporate a conventional wikitable into a Navbox, but all I get to show is a {, and no mention of someone doing the same anywhere has come up in searches - so, is there a workaround, or is there an alternative that I can convert the basic wikitable into without having all the data in the utterly impossible to follow (and therefore maintain) order mandated by the navbox with columns? Cheers. - NiD.29 (talk) 06:22, 26 May 2020 (UTC)

If you link to a sandbox page where you are trying to do this, we may be able to help you. – Jonesey95 (talk) 06:46, 26 May 2020 (UTC)

Thanks, it is here - was initially attempting to do both a colspan and a rowspan in the headers but that doesn't appear to have been implemented on the column naxbox - which also has the data entered in the least editor-friendly manner possible for future maintenance. - NiD.29 (talk) 07:18, 26 May 2020 (UTC)

Without even following the links, I can tell you what the problem is: pipes. A navbox is a template, and templates use pipes to separate parameters. In a line like

|list1={|class=wikitable

the Wikitext template parser sees this as two independent parameters: |list1={ and |class=wikitable, so it assumes that list1 is merely a left brace. Wikitables using the normal {| markup use the pipe character heavily: in the markers to start and end the table, to indicate the start of a caption, new row, or data cell; and to separate a cell's value from its attributes. These must be entered as {{!}} throughout, as in

|list1={{{!}}class=wikitable

See the Wikitext below the example at Help:Table#Nested tables. --Redrose64 🌹 (talk) 09:58, 26 May 2020 (UTC)

Thanks! that fixed one problem, now to figure out the formatting, but that will be for tomorrow, much appreciated. - NiD.29 (talk) 10:12, 26 May 2020 (UTC)

Recent change

Hi! I have re-ordered the #if: check so that it now suppresses all output if there is no content. It shouldn't increase the code complexity since we already had this check before my change. You can find the list of the ca. 50 pages with empty navboxes in Category:Navboxes template with no content. I was thinking we might add a "preview" message to warn the user that the code is not valid, much like we warn when there are invalid parameters. What does everyone else think? Thanks! Plastikspork _―Œ^(talk) 14:53, 31 May 2020 (UTC)

I think that a normal-sized-text red error message in preview would be appropriate. – Jonesey95 (talk) 15:37, 31 May 2020 (UTC)

Common practice minimum

So I couldn't find it in this guide, so I was wondering what's the minimum amount of navigation boxes usually listed to use this template. I always used it after at least 3, but when I used it on a page with 4 it got reverted and the person questioned on where it says that amount is enough. So is there a commonly used minimum? IAmNMFlores (talk) 21:20, 11 April 2023 (UTC)

@IAmNMFlores: See WP:NENAN, there is a "rule of five". --Redrose64 🌹 (talk) 23:00, 11 April 2023 (UTC)

Why impose nowrap?

I have built a series of navboxes using the metatemplate {{Constituency Teachtaí Dála navbox}}}. These navboxes display their data as a table rather than as te usual horizontal list, because a list very poor way to describe a multi-seat parliamentary constituency.

This mostly works very well, but there was in a glitch tables with higher numbers of columns, e.g. in {{Dublin County (Dáil constituency)/TDs}}, where are there a 9 columns. {{navbox}} was applying the -CSS class "nowraplinks", which caused the 9-column tables to spill out to the right of the article body on smaller screes such as my full-HD laptop. After my request for help at WP:Village pump (technical), @PrimeHunter kindly devised this hack[1] to remove "nowraplinks" from the output of {{navbox}}.

However, @Spleodrach spotted[2] that when {{Dublin County (Dáil constituency)/TDs}} is used inside the wrapper {{navboxes}}, e.g, on Liam Cosgrave, the nowrap problem returns and the table again spills out to the right.

Why is {{navboxes}} doing this, when nowraplinks is already part of {{navbox}}? And how can this part of {{navboxes}}'s behavior be disabled? BrownHairedGirl (talk) • (contribs) 03:48, 16 July 2023 (UTC)

@BrownHairedGirl: {{Navboxes}} is itself a navbox using Module:Navbox so it's still a nowraplinks coming from there. I have made a better fix for your case by adding listclass = wraplinks to override nowraplinks instead of removing it.[3] This also works when nowraplinks is added a second time via {{Navboxes}}. PrimeHunter (talk) 10:16, 16 July 2023 (UTC)

Bless you again, @PrimeHunter. That has indeed fixed it, and more elegantly too.

I was going to say that Liam Cosgrave would be pleased, but he was not a man to be pleased about anything. BrownHairedGirl (talk) • (contribs) 11:20, 16 July 2023 (UTC)