Template talk:Navbox/Archive 22

Archive 15

←

Archive 20

Archive 21

Archive 22

Archive 23

Archive 24

Not wrapping bullets properly... What happened to {{·wrap}} and other similar templates?

Moved from Wikipedia talk:Line-break handling § Hlist wrapping

Moved from Template talk:Hlist § Hlist wrapping

There was a change made a number of years ago to line-break handling either as part of the Common CSS and / or somewhere else. I'm not sure if it was done intentionally or if it was overlooked, but as a result of these changes wrapping is not currently being handled correctly within many {{navbox}}es when they use {{hlist}}. See these examples of one section of the {{Wikipedia technical help}} template and note how the bullets between each item can sometimes start a newline when changing the width of the page, which is not desired:

Examples

Current (incorrectly wrapping) code: Fixed code by avoiding the use of {{hlist}}: What this code could look like if {{·wrap}} and its alias {{·w}} were never deleted: {{Navbox | title = [[Help:Directory#Technical help|Wikipedia technical help]] | listclass = hlist | state = {{{state<includeonly>|{{{1|autocollapse}}}</includeonly>}}} | basestyle = text-align: center; | name = Wikipedia technical help | bodyclass=hlist | above = '''Get personal technical help at [[Wikipedia:Teahouse|the Teahouse]], [[Wikipedia:Help desk|Help desk]], [[Wikipedia:Village pump (technical)|Village pump (technical)]], [[Help:Introduction to talk pages/1|talk pages]] or [[Wikipedia:IRC|IRC]].''' | group3 = [[Wikitext]] | list3 = {{nowrap begin}}[[Help:Wikitext|Wikitext main page]] ([[Help:Cheatsheet|Cheatsheet]]){{·w}} [[Help:Using colours|Colours use]]{{·w}} [[Help:Columns|Column]]s{{·w}} [[Wikipedia:Line-break handling|Line-break handling]]{{·w}} [[Help:List|Lists]]{{·w}} [[Help:Magic words|Magic words]] ([[Help:Magic words for beginners|For beginners]]{{·w}} [[Help:Conditional expressions|Conditional expressions]]{{·w}} [[Help:Switch parser function|Switch parser function]]{{·w}} [[Help:Time function|Time function]]){{·w}} [[Help:Redirect|Redirects]]{{·w}} [[Help:Section|Sections and TOCs]]{{·w}} [[Help:Table|Tables]] ([[Help:Introduction to tables with Wiki Markup/1|Introduction]]{{·w}} [[Help:Basic table markup|Basics]]{{·w}} [[Help:Conditional tables|Conditional tables]]{{·w}} [[Help:Sorting|Sorting]]{{·w}} [[Help:Collapsing|Collapsing]]{{·w}} [[Wikipedia:Advanced table formatting|Advanced table formatting]]){{nowrap end}} | below = {{nowrap begin}}'''See also: [[:Category:Wikipedia information pages]]'''{{·w}} '''[[:Category:Wikipedia how-to]]'''<br>Further navigation at: [[Template:Wikipedia help pages|Help pages]] ([[Template:Administrators' guide|Administrators]]){{·w}} [[Template:Wikipedia template messages|Templates]]{{·w}} [[Template:Wikipedia referencing|Referencing]] ([[Template:Citation metadata navbox|Citation metadata]]){{·w}} [[Wikipedia:WikiProject Accessibility/Navigation menu|Accessibility]]{{·w}} [[Template:Botnav|Bots]]{{·w}} [[Wikipedia:User scripts/Navbox|User scripts]]{{·w}} [[Template:Wikipedia accounts|Accounts]]{{nowrap end}} }}

My (very limited) understanding of why this was done is that it had something to do with IE not rendering the line breaks properly with the old system. I realize this will need to be a larger discussion and for all I know that discussion could have already happened, but I don't know if or when as I haven't been as active on Wikipedia in the last 10 years or so. I would appreciate it if someone could point me in the right direction to read more about this. If it hasn't been properly discussed, where would be the best place to raise this issue? I see in the deletion discussion for {{·wrap}} that this issue was brought up but then quickly dismissed. Was it working properly back then and then has subsequently regressed?

Thanks so much for pointing me in the right direction. - Paul^T+/_C 21:15, 7 March 2018 (UTC)

@Psantora: hlist originally worked the same way as you expect. However, it was indeed discovered that IE sucks (and even possibly other versions of other browsers), and our then-CSS-guru Edokter (since-retired due to some drama in 2016) threw his hands up and said "no more" after some number of attempts to make that behavior stick in all browsers. This would have taken place in the history of Mediawiki:Common.css, though I cannot see a talk page discussion on the point from brief searching, so that may have occurred elsewhere. From memory, it may also have to do with hlist's increased use in sidebar templates, where space does not necessarily allow for dots, causing really unfortunate rendering (the dots extend out of the browser viewport causing a sideways scrollbar--bad behavior). --Izno (talk) 00:53, 8 March 2018 (UTC)

As for the previous templates (dot-w, and even nbsp-dot), those are entirely deprecated due to accessibility concerns. There is zero chance that those are allowed in the mainspace. --Izno (talk) 00:54, 8 March 2018 (UTC)

@Izno:Now that you mention it, I do remember a period of time a number of years ago where there were a bunch of display problems with horizontal scrolling all over Wikipedia. Given that this isn't going to be fixed in hlist, is there some reason the old templates can't be restored? This is the first I've heard of accessibility concerns with them, unless you mean approachable in terms of editing the MediaWiki code? If you have any idea where that discussion happened I'd like to read it before going to WP:DRV.

What is {{nbsp-dot}}/{{nbsp·}}? — Preceding unsigned comment added by Psantora (talk • contribs)

@Psantora: Yes, they will not be restored because WP:Accessibility is required. The old templates are not accessible to users who have bad vision. What looks to you and I like a list with bullets between them is sounded as "A bullet B bullet C bullet D", and which most bad-eyesight programs do not allow skipping of, whereas the current format would sound something like "list of 8 items. do you want to hear/skip the items?" in those programs. "What is {{nbsp-dot}}/{{nbsp·}}?" Those are how the templates you are talking about are implemented (give or take)--"nonbreaking space, dot" or in some cases "span with nowrap applied, with internal item, space, and dot". Coincidentally, those basically have some of the same issues as the hlist class (regarding the sidebar and squished navbox problem). DRV will not see these templates undeleted, I can say with some great level of certainty. --Izno (talk) 19:20, 9 March 2018 (UTC)

As for whether hlist will be fixed, I do not know if it will be or won't be. Our support for old versions of Internet Explorer has dwindled over the past several years as Microsoft has turned to deprecating or dropping support for old versions as well (only IE11 is actively supported). The compatibility support provided by the WMF in MediaWiki is IE11, with basic "make sure the entire page doesn't explode" support to versions greater than IE6. So, I think there's some opportunity to broach the topic of nowrap bullets on Mediawiki talk:Common.css--you might invite readers of WP:VPT when you open that discussion, because the CSS talk page is rather quiet these days. It doesn't need to be a long post--just a "hey, maybe we should look at this again". --Izno (talk) 19:30, 9 March 2018 (UTC)

Thanks for the information. It was super helpful. I will consider bringing the discussion up there (and pinging a link to VPT). I really appreciate it! - Paul^T+/_C 03:57, 11 March 2018 (UTC)

Image doesn't show up

In the {{{image}}} parameter, I have specified my image the same way I did on another page. And if I put the same image below the Navbox, it also shows up. I also have a {{{list1}}}. Any ideas why the image is not showing? Lithimlin (talk) 19:09, 17 April 2018 (UTC)

In order to trouble-shoot this issue we'll need to see the usage. Where are you testing this? Primefac (talk) 19:27, 17 April 2018 (UTC)

I'm testing this in a wiki I'm helping to put together right now. I'm kind of misusing the {{navbox}} here, but it was the only thing I found so far that can be used as an {{infobox}} that spans across the top of a page instead of being on the top right of it. Lithimlin (talk) 19:40, 17 April 2018 (UTC)

Navboxes and Sidebars usage guidance

Hello there. I have been editing and creating Navboxes and Sidebars for a while, and I have a sense for when is better to use each. However, I was wondering if more spelled-out guidelines, or essays on the topic exist. If no guidance exists, I am not suggesting that it should; not everything needs to be spelled out. However, if it does exist, I would be interested to know and read it. One final note: THANK YOU to whoever established and developed them in Wikipedia. They are invaluable in finding articles and bringing order and structure to Wikipedia. Thank you!(talk) user:Al83tito 16:20, 6 July 2018 (UTC)

user:Al83tito, you may wish to start by reviewing WP:NAVBOX and the various links at the top of that section. Frietjes (talk) 18:32, 6 July 2018 (UTC)

Adding a "style links" parameter

Module:Team roster navbox is a wrapper for Module:Navbox that does two extra things (1) adds |nowraplinks=yes and (2) automatically applies background/color styling to the title, above, group, and below fields. the first feature is trivial, but the second feature is rather useful. for example, compare

{{team roster navbox
| name = Template talk:Navbox
| title = [[Template:Navbox]]
| titlestyle = background-color:black; color:white;
}}

and

{{navbox
| name = Template talk:Navbox
| title = [[Template:Navbox]]
| titlestyle = background-color:black; color:white;
}}

if there are no objections, I would like to add this link coloring feature to Module:Navbox directly. it would be turned on using |stylelinks=yes parameter, which means "apply the parent element background and color style parameter to the text inside the links". comments? suggestions? Frietjes (talk) 19:11, 9 July 2018 (UTC)

you can see some proposed code here. Frietjes (talk) 19:40, 9 July 2018 (UTC)

@Frietjes: What about WP:COLOUR? Should the navbox only do this for titles / other fields which consist solely of links and whitespace? Jc86035 (talk) 22:16, 9 July 2018 (UTC)

Jc86035, I believe the key here is that it would be optional and could be tracked. the alternative see this search is what you see in Template:Miami Dolphins roster navbox which is to color the links manually. I don't see how we are going to stop users from overriding the link coloring. Frietjes (talk) 22:23, 9 July 2018 (UTC)

TemplateStyles in meta templates

Followers of this page may be interested in WT:TemplateStyles#In the context of meta templates. Please take a moment to comment there. --Izno (talk) 01:38, 27 July 2018 (UTC)

Module:Navbox

Not sure if this is a flaw... I noted that Module:Navbox places some navbars into at least one category incorrectly. An example is at {{Dynamics (music)}}, where the navbar does not style any other than the default bg, and yet because {{Aspects of music}}, which does style a non-default bg, is installed on "Template Dynamics (music)'s" /doc page, that template populates Category:Navboxes using background colours incorrectly. Tried using |nocat=true and |nocat=yes in the "Aspects of music" template on the /doc page, but that doesn't work (each time I tried a purge and a null edit). Since I have not yet mastered Lua, I'm at a loss as to how to fix this. Can anyone help?  Paine Ellsworth  ^put'r there  19:43, 20 August 2018 (UTC)

Also, I did remove the "Aspects of music" navbar from the /doc page, which did remove the "Dynamics (music)" navbar from the category.  Paine Ellsworth  ^put'r there  19:47, 20 August 2018 (UTC)

Module:Navbox has no method of disabling categories (there is no nocat). It uses mw.title.getCurrentTitle() to get the title of the page being rendered. That page is Template:Dynamics (music). The module then tests if the page is in the Template namespace and, if so, whether it should be ignored (doc/sandbox/testcases). If it is a not-ignored template page, it gets a tracking category if needed. That is why the tracking category is added to Template:Dynamics (music) but not its /doc subpage (the latter is ignored as a doc page). I think I once tweaked the code which generates the tracking categories but I did not change the logic. As you point out, that logic is somewhat broken, because the aim apparently is to flag templates which use a navbox in certain dubious ways, whereas in this case the dubious usage is in the doc subpage. I can't see a quick fix. I could look at adding nocat if others agree that would be desirable, however, {{Aspects of music}} would also need an edit to pass the nocat parameter to {{Navbox}}. Johnuniq (talk) 05:45, 21 August 2018 (UTC)

There might be good reason to include a fix for this. The category is populated by over 56,000 templates, and I wonder how many of those are like {{Dynamics (music)}} and shouldn't be in there. It would be best if the fix would not include default bg templates in the category without having to use a nocat param at the /doc pages. A "seamless" fix. I don't think there was a way to do that even before Lua came along. So a nocat param appears to be the only way to fix this. Then each entry in that category will have to be checked and the nocat param added to the templates that shouldn't be there.  Paine Ellsworth  ^put'r there  17:26, 21 August 2018 (UTC)

I implemented nocat using the guideline at WP:NOCAT. I got thoroughly confused about the logic for a while, but I think it's correct now. One source of confusion was that Module:Navbox uses Module:Arguments with a default which means |nocat= is removed from the arguments whereas WP:NOCAT recommends that should be the same as |nocat=true. Currently (and saner IMHO), if |nocat= is used, a tracking category will be added if warranted. I added |nocat=true to Template:Aspects of music with the result that Template:Dynamics (music) is no longer showing the tracking category. Johnuniq (talk) 05:11, 22 August 2018 (UTC)

Thank you for that. One thing though... your edit removed {{Aspects of music}} from the category, and that template should be in the category. So I altered it to |nocat = {{{nocat|}}}, which allows "nocat" to be passed on to the instances of the template on /doc pages, and keeps those templates out of the category when they have only the default background color.  Paine Ellsworth  ^put'r there  05:42, 22 August 2018 (UTC)

Thanks, I was really confused and wondered about that. Please test some more! Johnuniq (talk) 06:04, 22 August 2018 (UTC)

Also found that if I pass |nocat=true to /doc pages of other non-default bg navbars, those navbars will still populate the category as they should. And if for any reason they are changed back to the default bg in the future, the nocat will kick in and withdraw them from the category. I will start checking the category for other similar instances – I'll see if I can find a way to quickly AWB- check 'em. Thanks again, Johnuniq for your help on this!  Paine Ellsworth  ^put'r there  11:21, 22 August 2018 (UTC)

To editor Johnuniq: found a way to use AWB to sample more than 5,000 of the category entries and found none that were not supposed to be there. So the problem doesn't seem to be a very large one at all, seemingly limited to the few templates already found and fixed. Thank you again for your great help with this!  Paine Ellsworth  ^put'r there  14:32, 22 August 2018 (UTC)

Navbox not displaying on mobile sites

I've noticed that Navbox does not display on mobile sites, unless the desktop site is requested and the ".m" is removed from the URL.

Example: moblie ".m" site vs. desktop site using Irish mythology (Ulster) template.

I've tried with multiple mobile browsers Chrome, Firefox, Puffin; on Android, but also on a Windows desktop with ".m" in the URL.

Any help would be appreciated.

Marcas.oduinn (talk) 19:04, 13 September 2018 (UTC)

The documentation answers this question. (Short answer: This is expected/by design, if not ideal.) --Izno (talk) 19:08, 13 September 2018 (UTC)

Ah, right, thanks, I see the big desktop only sign now... however, I can't find the explanation in the documentation page, can you point me to it? — Preceding unsigned comment added by Marcas.oduinn (talk • contribs) 19:16, 13 September 2018 (UTC)

Yes, I see there aren't details. :) Those are mostly floating around phab:T124168. The gist is that navboxes are very heavy for transmission from Wikimedia's page servers to your mobile device. The developers decided not to add them to mobile for this reason. They are also difficult to 'design right' for mobile devices. --Izno (talk) 19:20, 13 September 2018 (UTC)

Proposal to add tracking category.

I wanted to propose adding some code to the Module that would track when a template has been created with a {{{name}}} that doesn't match the templates name. I implemented this a while ago on Module:Sidebar games events and it has been super helpful, so I wanted to give it a try here. My addition would look something like this (would need to test it out in the sandbox a bit):

if mw.title.getCurrentTitle().namespace == 10 and (args.name ~= mw.title.getCurrentTitle().text) then
    root:wikitext("[[Category:Navbox templates with incorrect name]]")
end

I can implement it myself but wanted to check before I made such a BOLD edit... --Zackmann (^{Talk to me}/_{What I been doing}) 22:58, 14 November 2018 (UTC)

we have Wikipedia:Database reports/Invalid Navbar links, which has less overhead, and doesn't have the massive number of false positives you will get with the proposed approach. Frietjes (talk) 23:22, 14 November 2018 (UTC)

currently, Redrose64 is doing a great job fixing them. now, if we could get The Transhumanist to stop moving navboxes without changing the |name= we would be halfway there :) Frietjes (talk) 23:25, 14 November 2018 (UTC)

   — The Transhumanist   03:47, 15 November 2018 (UTC)

@Frietjes: I'm curious what you mean by overhead? I don't see this as causing much additional work. Unlike the report it will update more often. Let me ask this, what would be the downside to having both implementations? I can appreciate that some users like the database reports approach. Is there a downside I'm not seeing to also having a category? Looking to learn.... --Zackmann (^{Talk to me}/_{What I been doing}) 17:59, 15 November 2018 (UTC)

Zackmann08 have you tested what will happen for templates like Template:Film- and television-related infobox templates which are used in namespace 10 on a page where the name does not match the pagename? Frietjes (talk) 18:21, 15 November 2018 (UTC)

Bamyers99 may be able to help with a "real time" solution. Frietjes (talk) 18:23, 15 November 2018 (UTC)

@Frietjes: That is a good point. No I have not. I was only considering templates that would be used in the main namespace. You make an excellent point. --Zackmann (^{Talk to me}/_{What I been doing}) 18:44, 15 November 2018 (UTC)

Navbox question

I'm not sure this is the right place to ask, apologies. I've come across this template, which links to pages in other languages, where an english page isn't available. It seems to me non-standard, to say the least, but as navboxes aren't my expertise, I would like some informed opinion. Thank you! --Ben Stone 03:39, 21 November 2018 (UTC)

WP:NAV says not to do this. The purpose of navboxes is to link to English Wikipedia articles. --Izno (talk) 03:54, 21 November 2018 (UTC)

That said, this is also not that great a template because it includes links to articles which do not use the template. Either the template should be added to those pages or the links should be removed. In this particular case, it's probably better to remove the links. --Izno (talk) 03:58, 21 November 2018 (UTC)

Style of current page link with anchor

If the link in navbox is the current page, the link would be disabled and bold. However, if the link contains anchor, the link would be shown like any other. For example, at bottom of PeaZip, the link PEA in template {{Archive formats}} is shown as normal link, which actually links to the same page. Any way to fix this? --Franklin Yu (talk) 06:10, 28 November 2018 (UTC)

@Franklin Yu: In the link [[PeaZip#Native archive format|PEA]], #Native archive format isn't an anchor, it's called the fragment. The anchor is in the PeaZip page itself, being an id="Native_archive_format" attribute that is generated by the level 3 subheading ===Native archive format===.

Back to the original q. When a page contains a link to itself as a whole, that is, the link has no fragment, the MediaWiki software does not generate a clickable link but instead emits boldface text:

[[Template talk:Navbox]] → Template talk:Navbox

However, when a page contains a link within itself, that is, the link does have a fragment, the link is clickable and blue:

[[Template talk:Navbox#Style of current page link with anchor]] → Template talk:Navbox#Style of current page link with anchor

It does not matter if such a link is in the page itself, or in a template - the effect is the same. This cannot be altered, since the conversion of links happens after the expansion of templates. Section links always being clickable and blue is intentional, this is mainly for use when you want to make a link from one paragraph to another. See for example Promotion (chess) - in this article is a section named Promotion to various pieces, which contains this parenthesis:

(See Underpromotion: Promotion to rook or bishop for examples of underpromotions to rook and bishop made in order to avoid stalemate.)

This link is both clickable and blue, not only here but also in the article. If we were to change the behaviour as you request, that link in Promotion (chess) would no longer be a link - it would be boldfaced (i.e. See Underpromotion: Promotion to rook or bishop for examples ...)

In short: even if you file a change request at phab:, nothing will be done to alter this. --Redrose64 🌹 (talk) 10:45, 28 November 2018 (UTC)

Thank you. --Franklin Yu (talk) 14:48, 28 November 2018 (UTC)

Adding ability to have a class for the navbox as a whole

Hello, on Template talk:Authority control#HTML_class I proposed for that template to have an individual class added to it (like class="authority-control") and the discussion tended towards first adding support for navboxes to have their own classes in this module. A user mentioned that there is a |bodyclass= parameter, but it's not for the outermost div, but an inner table (alternative solutions like having an outer div just for that template were considered hacky and a centralized method would be better for every other template that relies on this one). Having an HTML class would be good to have so people who write userscripts, themes, parsing, etc, can specifically target navboxes such as Authority Control. Please consider adding the capability for navboxes to have their own classes, thank you. Opencooper (talk) 20:31, 7 December 2018 (UTC)

This is something we will need/want I think for TemplateStyles anyway. If and when someone gets along to modifying the module to my suggestion (somewhere in the recent archives now). --Izno (talk) 21:57, 7 December 2018 (UTC)

The template is broken!

It displays "A (B, C ·" instead of "A (B, C)" on 26 million pages. Have no idea how to fix it. Help! 188.255.85.195 (talk) 23:22, 24 January 2019 (UTC)

Presumably this is related to Wikipedia talk:WikiProject Templates#Template:Film- and television-related infobox templates. Please also observe WP:MULTI, since you posted a very similar message at Wikipedia talk:WikiProject Lists#List navbox template is broken!. --Redrose64 🌹 (talk) 10:13, 25 January 2019 (UTC)

Absence of line break between navboxes apparently causes misbehavior in lists

I am seeing something that I have never noticed before, and I do not see it documented anywhere. When two navbox templates are placed on the same line, and both of them have numbered lists in them, the second navbox is rendered with a bulleted list instead of a numbered list. If the navboxes are placed on separate lines, the second navbox renders with a numbered list, as intended. This happens whether the navboxes are placed directly in an article or listed inside of {{Navboxes}}.

Please see examples of navboxes with and without line breaks between them in my sandbox. In the middle section of that page, I have pasted the wikicode output from Special:ExpandTemplates to show that the only difference is that the <div> tag that opens the second navbox is on either the same line as the previous navbox's closing div tag, or on a new line. I don't see how that would cause the list inside the second navbox to render as bullets instead of numbers. – Jonesey95 (talk) 06:41, 23 May 2019 (UTC)

Interesting. I put a simplified example in my sandbox (permalink). Johnuniq (talk) 07:36, 23 May 2019 (UTC)

It's nothing to do with navboxes. The {{Div col}} template should have the closing div on a separate line to fix this. -- WOSlinker (talk) 08:06, 23 May 2019 (UTC)

1. a
2. b
3. c
4. d
5. e
6. f
7. g

a

b

c

d

e

f

g

Let's try that in {{div col/sandbox}}:

div col:

1. a
2. b
3. c
4. d
5. e
6. f
7. g

a

b

c

d

e

f

g

div col/sandbox:

1. a
2. b
3. c
4. d
5. e
6. f
7. g

a

b

c

d

e

f

g

Well I'll be hornswoggled. <whiny voice>But why?????</whiny voice> Seriously, putting the second navbox on a new line did not move the closing div to a new line; it moved the next opening div to a new line. Why should the placement of the div tag, which is, after all, wrapping an entire set of table tags when it is used in a navbox, make a difference? Is this an HTML thing, or is this a wikicode parser quirk? – Jonesey95 (talk) 08:31, 23 May 2019 (UTC)

Inspecting the HTML source of the output shows ol tags around the first list (a to g), but not around the second. Inserting a newline before the second div col template results in ol tags around both lists. I guess it's MediaWiki, possibly its HTML cleaner? Johnuniq (talk) 09:32, 23 May 2019 (UTC)

Nasty. Well, I have modified div col, inserting a line break after the content. We'll see what the collateral damage looks like. – Jonesey95 (talk) 10:44, 23 May 2019 (UTC)

This is probably phab:T11996. --Izno (talk) 15:03, 23 May 2019 (UTC)

Or if not that one, close enough. Basically what we're instructing the parser to do is to end the div before the end of the line, which it still thinks is a list item. The parser does not know to close the unordered list before hand. Funky stuff occurs as a result. Tidy may used to have closed that based on heuristics, but Remex has a definite algorithm, and in that algorithm Bad Stuff gets through for us to fix. --Izno (talk) 15:40, 23 May 2019 (UTC)

It's been the case for several years that certain templates that generate boxes must be placed at the start of a line. This includes some templates that exist as a start/end pair, both must be hard left. --Redrose64 🌹 (talk) 16:14, 23 May 2019 (UTC)

I believe some of it is due to the switch away from HTML tidy. we had to start injecting some newlines in the infobox module. Frietjes (talk) 18:30, 23 May 2019 (UTC)

Collapsing / expanding

Is there a policy on whether navboxes should default to oollapsed / expanded? I collapsed Template:Brexit Party but it was restored without explanation so I collapsed it again and then had this diff: No justification to force this to be collapsed. Should be dealt with on a page by page basis. There are a number of new stub bios of Members of the European Parliament such as James Wells where it is in effect advertising the party and it would mean going around collapsing them one at a time. Pinging @Redrose64: and @Izno: since they answer a lot on here. --The Vintage Feminist (talk) 17:39, 3 June 2019 (UTC)

It seems that the consensus default is "autocollapse", which is described at this page. I don't see a guideline about it, but the consensus based on common practice is pretty strong. This template appears to be using the default; at the aptly named Mark Reckless article, for example, the navbox is expanded, since it is the only collapsible element on the page, while at Paul Nuttall, the navbox is collapsed, since there are two navboxes on the page. – Jonesey95 (talk) 07:35, 4 June 2019 (UTC)

@Jonesey95: Thanks. --The Vintage Feminist (talk) 18:45, 6 June 2019 (UTC)

I agree with Jonesey and I happen to agree with the current default.

If you're really concerned about such things as advertising of a party, you might consider whether it's a good idea to add people to a party navbox. In some cases it might be a good idea--say, the founders. In many or most others, I am a bit more skeptical. --Izno (talk) 01:51, 7 June 2019 (UTC)

Proposed changes to {{refideas}}

There is a proposal to change the behavior of {{refideas}} to make the content collapsible. Interested editors are invited to give feedback on the talk page. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 18:00, 7 June 2019 (UTC)

Set class for navbox wrapper div

On English Wikisource we have some project-specific concerns that necessitate being able to address the entire generated navbox from CSS and JS. We do this with a custom extra parameter (somewhat awkwardly named |wrapclass=) that allows the template calling _navbox to pass in a custom CSS class that gets applied to the navbox's wrapping div. The code for this custom param is a bit of a pain to keep patching in every time we resync from enwp, and it is functionallity that is both cheap and potentially useful elsewhere, so I figured I'd test the waters for adding this functionality (with a better param name) to the upstream module (i.e. here).

The only code change is to the module like so:

		local nav = res:tag('div')
			:attr('role', 'navigation')
			:addClass('navbox')
            :addClass(args.wrapclass) -- <== NEW: add class passed in wrapclass param
			:cssText(args.bodystyle)
			:cssText(args.style)
			:css('padding', '3px')
			:node(tbl)

I would suggest something like |navbox-class= for the parameter name. Thoughts? --Xover (talk) 10:33, 10 August 2019 (UTC)

This was discussed quite recently. It is also generally necessary for deployment of TemplateStyles.

Feel free to implement this in the module sandbox and then set up tests in the test case pages. I don't know about en.ws, but en.wp has many edge cases. --Izno (talk) 13:47, 10 August 2019 (UTC)

@Izno: done. There are no testcases for the module, only for the wrapper template, and this change only affects the module. The new argument is named navboxclass and can be added to the invocation of _navbox in Module:Authority control to set the given class on the navbox's wrapper div (that's actually the exact use case at enWS that prompted this). @Tom.Reding: Can you sync this over from the sandbox to the live module, or should I throw out a {{TPER}}? --Xover (talk) 15:39, 10 August 2019 (UTC)

Xover, done, although |outerclass= may have been more accurate, this works as well. Frietjes (talk) 17:26, 10 August 2019 (UTC)

Template-protected edit request on 14 August 2019

To improve the performance of the collapsible code, I request to make [1]. This will cause the parser to preload the collapsible code, avoiding an additional resourceloader lazyloading call to be made, which makes pages containing navboxes a little more efficient. —TheDJ (talk • contribs) 12:33, 14 August 2019 (UTC)

@TheDJ: Have you done any testing to indicate that this should have no visible impact? --Izno (talk) 03:10, 15 August 2019 (UTC)

Izno, {{Navbox/testcases}}. It basically just skips the JS transform inside MediaWiki:Common.js that would otherwise happen to collapsible, but by using mw-collapsible, the JS will be predelivered by the MW parser, which makes it faster. —TheDJ (talk • contribs) 07:00, 15 August 2019 (UTC)

@TheDJ: One of the reasons I ask is that the translation in Common.js also handles the states that mw-collapsible did not for a portion of time (autocollapse I think was one?). Does mw-collapsible also handle those now? --Izno (talk) 11:35, 15 August 2019 (UTC)

Izno, yes it does. The mwCollapsibleSetup hook in our Common.js does that for all mw-collapsibles and all collapsibles are already converted to mw-collapsible on the fly right now (this just makes it faster) —TheDJ (talk • contribs) 15:41, 15 August 2019 (UTC)

 Done Izno (talk) 17:49, 18 August 2019 (UTC)

colspan causes unnecessary wrapping in groupless navboxes with 'width:auto'

In navboxes with no groupN, no image, and with width:auto applied, the default colspan="2" that gets added to each of the rows causes the navbox to adopt the width of the content in the final row/cell, even when this causes content in earlier rows to wrap. See for example Template:Set navigation on Yugipedia. Simply removing the unnecessary colspans is enough to fix this (interestingly, at least in Chrome, it seems that just removing the colspan in the header is enough to fix it). I would take a crack at this myself, but I have no idea how to check for the existence of any groupN without just looping through all the possible names. 「ディノ奴千？！」^{☎ Dinoguy1000} 21:21, 14 July 2019 (UTC)

I guess the way to check for any groupN parameters would be something like the getArgNums() function in Module:Infobox, actually. 「ディノ奴千？！」^{☎ Dinoguy1000} 21:30, 14 July 2019 (UTC)

*poke* 「ディノ奴千？！」^{☎ Dinoguy1000} 18:28, 1 December 2019 (UTC)

Spacing for ungrouped item after subgroups

Template:Ainur Group1 (Valar) comprises 2 subgroups and then an ungrouped item, Morgoth. There is no space before the entry "Morgoth".

In contrast, Group 2 (Maiar) starts with some ungrouped items, then two subgroups. The ungrouped entries (Eonwe…) have an appropriate space before the first one.

Is this a weakness in the coding for {{Navbox}}, or can Template:Ainur be formatted better, to align the spacing of all ungrouped items? – Fayenatic London 14:59, 24 January 2020 (UTC)

Morgoth (Melkor) is an entry in a valid list with <ul>...</ul> tags, albeit a list with just one item. The list is enclosed in a <div>...</div> with no styling. Eönwë, Sauron and Melian are also list items, but they do not have enclosing <ul>...</ul> tags - instead they have an enclosing <div style="padding:0em 0.25em">...</div> - that 0.25em padding on right and left is what causes the gap. I think that the problem is with {{navbox}}, and may be a WP:VPT matter. --Redrose64 🌹 (talk) 23:39, 24 January 2020 (UTC)

Fixed, I believe. – Jonesey95 (talk) 23:50, 24 January 2020 (UTC)

Template-protected edit request on 11 March 2020

line 68: content:match('^<span class="nowrap">') then change as content:match('^') then. This change will affect on Special:LintErrors for Misnested tag with different rendering in HTML5 and HTML4 and it will reduce many errors. Warm Regards, ZI Jony ^(Talk) 07:42, 11 March 2020 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Izno (talk) 12:06, 11 March 2020 (UTC)

As with the proposed change to Module:Infobox, I do not think that this change would fix any templates. Please link to a specific page that would be fixed by this change. – Jonesey95 (talk) 12:59, 11 March 2020 (UTC)

Template:Navbox subgroup

@Randomtransmans: Why did you create Template:Navbox subgroup? When doing that, you should have seen a notice that the page was deleted on 16 March 2019 per this TfD. It is used in Template:Touch! Generations which you also created. I can hardly remember, but I believe the subgroup template is redundant and should be replaced with plain navbox. Perhaps others with better recollection can confirm. The template is eligible for speedy deletion but no harm in asking first. Johnuniq (talk) 23:49, 5 June 2020 (UTC)

Are you deleting it? Randomtransmans (talk) 01:52, 6 June 2020 (UTC)

I only asked a question. Someone else deleted it after my comment here. I see that someone with a better grasp than me of how it works has already fixed Template:Touch! Generations so there appears to be nothing more to do. Please review WP:INDENT for how to use a colon when replying. Johnuniq (talk) 02:30, 6 June 2020 (UTC)

Adding "History" next to "Edit"

Hey I want to add that, I want people to view the history of the Navbox, the abbreviation should be "H" and when putting the pointer on it, it would say "View the history for this template" can you add that? — Preceding unsigned comment added by Gamerknowitall (talk • contribs) 02:32, 7 June 2020 (UTC)

This is a perennial proposal. See suggestions/discussions from 2008 and 2010 from Template:Navbox's archives, and similar from 2009, 2012, and 2016 from Template:Navbar's archives. According to this 2006 discussion, T:Navbar had a history link added and subsequently removed many years ago. There are probably other similar discussions scattered elsewhere on the project, though I didn't feel like trying to hunt any down. The obvious objection is that this is adding more interface clutter for no real benefit (i.e. how many readers even know what the current VTE links are for, or use any of them other than by accident or out of curiosity?). A navbox's history is already trivially accessible by just clicking through to view that navbox and clicking the "History" tab on it; is saving a single click really worth the addition of another link on every single transclusion of almost every navbox on the site? If anything, there are stronger arguments for removing at least one link from the navigation (I would not miss the edit links at all, to be honest) than for adding any more. 「ディノ奴千？！」^{☎ Dinoguy1000} 11:07, 14 June 2020 (UTC)

Help with striping

Hello! Maybe someone here has a better understanding of how the odd/even striping in this template functions, I am a bit lost right now. I am trying to properly export the template to dewiki, in order to replace the current de:Template:Erweiterte Navigationsleiste (there are lots of compatibility changes I will have to make, of course). As can be seen on my testing page, a lot is working well already, but in the child and collapsible examples the striping does not work as intended. I am not aware of any changes I made to the code (module, styles) with regards to the striping. Any ideas? Thanks, XanonymusX (talk) 10:38, 25 July 2020 (UTC)

That is a strange test site. Why not put the template and module in a sandbox at dewiki and try it there? Also, make a test page with just one example of a problem—that makes it easier to focus on the issue. Apart from the extensive renaming you have done, and ignoring the irrelevant function isIllegible, the only difference between Module:Navbox and what you're using is that you have some extra code (which I haven't tried to understand):

if not item:match ("{\|") then
    item = item:gsub ("\n([^\*])", " %1") -- listed items without table/ul/ol
end

What happens if you comment that out? Johnuniq (talk) 11:30, 25 July 2020 (UTC)

The whole sandbox concept of enwiki does not exist on dewiki; and over the years we have moved most Lua-related testing to the Beta cluster (I guess your “strange” refers to the new Vector, but that has no influence on the contents, obviously).

You are right to point out that one change I made, which is for compatibility with the currently used templates on dewiki. However, the striping problem was there already before I changed that (to be sure I have just tested it without the code in the preview, and it stayed the same). Very strange. The other major difference is that the styles are coming from TemplateStyles instead of the common.css, but I have not touched the odd/even part and I can see the classes in the HTML source, so there must be some issue with replacing the placeholders.—XanonymusX (talk) 13:43, 25 July 2020 (UTC)

@XanonymusX: If there is still a problem, consider making a sandbox here: Module:Sandbox/XanonymusX/Navbox and put the test (just one simple example showing a problem) on the talk page. You would need to change "Modul" to "Module" (the latter works on all sites) and maybe some other stuff. Then you would see if it works at enwiki. If it does, the problem is in one of the related pages (the style sheet??) and not the module. If it doesn't, I can have a look although you might have to remind me. Johnuniq (talk) 03:21, 30 July 2020 (UTC)

@Johnuniq: Thanks for the advice. Well, I have created the sandbox and Module talk:Sandbox/XanonymusX/Navbox works just fine. But outside enwiki it still does not, even after newly copying all the relevant styles from MediaWiki:Common.css. I have really no explanation for this difference. The class names are the same, and so are the markers. Is there any JS involved in the striping? That would be the only thing I can think of now. --XanonymusX (talk) 10:10, 30 July 2020 (UTC)

No, there is no JavaScript involved. I can have a look at the test site but not for a day or two, and I would need a reminder. The first step would be to edit each test page (that's Module talk:Sandbox/XanonymusX/Navbox here) and examine "Pages transcluded onto the current version of this page" at the bottom. Here, that is showing:

Module:Arguments

Module:Navbar

Module:Sandbox/XanonymusX/Navbox

Then compare the versions of each transcluded module with what is on the other site. For simplicity, the other site should have a test page with exactly the same wikitext. The test looks like "Multiple Subgroup Test" from Template:Navbox/testcases. That uses {{navbox}} whereas your test uses {{#invoke:...}}. That raises the question of whether the module gets all the arguments correctly. If you're really keen, you could include some mw.log code to see what arguments arrive in the module. Perhaps Module:Arguments is obsolete at the test site? Johnuniq (talk) 10:29, 30 July 2020 (UTC)

@Johnuniq: That worked, invoking the module directly does the thing! That means that the problem is the templatestyles tag, which I had put in the template rather than in the module. Not sure why this changes anything, but alright. I just have to find out where exactly to insert the templatestyles then…--XanonymusX (talk) 11:06, 30 July 2020 (UTC)

For navboxes with custom styling, VTE link underlines don't color properly

Template:University of Michigan uses a dark blue background with white text (including for links). I just made this fix so that, when a reader hovers a cursor over a link, the underline appears white, rather than the normal blue (which is nearly invisible). The template's show and hide buttons have a white underline somehow too. However, the VTE buttons have the blue underline. Could we make a fix so that they will be white as well? I'm not sure exactly where the code is that's leading to the current display, but since the show/hide renders correctly, I assume the issue is more likely here than there. (please  mention me on reply) {{u|Sdkb}} ^talk 06:38, 3 August 2020 (UTC)

Obsolete template

In line 453 args = getArgs(frame, {wrappers = {'Template:Navbox', 'Template:Navbox subgroup'}}), the obsolete Template:Navbox subgroup should probably be deleted. –XanonymusX (talk) 15:17, 3 August 2020 (UTC)

Seems reasonable. Anyone else? --Izno (talk) 20:02, 4 August 2020 (UTC)

Do not forget to remove the rest of the support for the deprecated and deleted {{Navbox subgroup}}. I have made the change to the sandbox. See Special:Diff/948473914/976558840. 50.53.22.81 (talk) 16:54, 3 September 2020 (UTC)

 Done Primefac (talk) 16:59, 3 September 2020 (UTC)

Thank you. 50.53.22.81 (talk) 17:02, 3 September 2020 (UTC)

Undocumented state value

Why does {{MSC Malaysia|state=open}} {{MSC Malaysia}} show the first instance expanded?

It seems that any value for |state=, other than the canonical values, will expand the navbox. -- Michael Bednarek (talk) 03:10, 5 September 2020 (UTC)

You should only use the documented values (autocollapse, collapsed, expanded, plain, off). Why would you want to use another? --Redrose64 🌹 (talk) 08:26, 5 September 2020 (UTC)

I don't want to at all; I just observed that |state=open was inserted into an article, and I was about to correct it when I noticed this behaviour. It seems quite common: insource:/state=open/. -- Michael Bednarek (talk) 10:08, 5 September 2020 (UTC)

The documentation says A navbox with [state=]autocollapse will start out collapsed if there are two or more tables on the same page that use other collapsible tables. Otherwise, the navbox will be expanded. That appears to be consistent with the behavior that is observed here. – Jonesey95 (talk) 13:27, 5 September 2020 (UTC)

The documentation also lists 5 permissible values for |state=, and goes on: If set to expanded, the navbox will always start out in an expanded state. My point is that an infinite number of other values will also expand the box. -- Michael Bednarek (talk) 02:09, 6 September 2020 (UTC)

We should not need to explicitly state that if you don't use one of the five listed parameters things won't go as planned. Primefac (talk) 16:27, 6 September 2020 (UTC)

It's standard for computer-related documentation and behavior to work like this. Consider the alternatives. First, some quite ugly code could be added to the module to display a large error message if a parameter uses an undefined value (I quite like that idea to achieve consistency, but it's hard to retrofit). Second, the documentation could declare that any other value will do X where X is a defined outcome. The problem with that is that if you ever introduce a new value with some different behavior, people will complain that documented behavior has changed. Another problem is the documentation bloat: it's best to say if you enter A then X will occur, if B then Y, etc. People should do what the documentation says. Johnuniq (talk) 23:39, 6 September 2020 (UTC)

Template-protected edit request on 22 September 2020

Decorative images are often not connected directly to the topic of the article, and as such can be confusing when stumbled upon when flipping through images in a Media Viewer interface. See Wikipedia:Village pump (technical) § Invisible Pictures (permalink). Please apply Special:Diff/976559973/979741741 to Module:Navbox to remove such decorative images from Media Viewer. —⁠andrybak (talk) 16:44, 22 September 2020 (UTC)

 Done Nardog (talk) 16:46, 22 September 2020 (UTC)

References in navboxes?

{{Neolithic Chronology}} includes a number of references in the template. When it's transcluded after the {{Reflist}} template (as it should be), the references end up floating awkwardly at the bottom of the page. Is there a standard way to handle footnotes/references in navboxes? Can you display them somewhere in the template itself? Do citations even belong in navboxes? I found one discussion about this from 2012 (Template_talk:Navbox/Archive_16#hlist and footnote groups) but it didn't reach a firm conclusion. – Joe (talk) 14:50, 27 October 2020 (UTC)

Joe Roe, if (general) you have put references in a navbox, you've probably missed the point. Navboxes are generally for links to English Wikipedia articles about and related to the topic of the navbox.

The general correct fix is to remove the reference in question. If there really is some question over whether a specific link should be in a box, or general layout question (I can remember a few in this category in my navbox travels), that reference or inclusion note can be provided as part of the template documentation, perhaps with a source hidden comment next to the link pointing to the doc. And if you really want to keep the refs in the navbox, they should be <noinclude>d. --Izno (talk) 16:45, 27 October 2020 (UTC)

I tend to agree. My first thought was that if you feel the need to put in references, you're probably deep into WP:SYNTH territory. But thought I'd get a second opinion before removing them. Thanks! – Joe (talk) 18:00, 27 October 2020 (UTC)

Just to add in a third voice, I would also agree that a navbox should NOT have references. Primefac (talk) 19:00, 27 October 2020 (UTC)

Navboxes must not have references. If the ref is being used to justify the inclusion of a particular link, then the link itself does not belong either. --Redrose64 🌹 (talk) 21:39, 28 October 2020 (UTC)

The problem goes away if {{Neolithic Chronology}} is regarded and treated as a transcluded section of an article, not as a navigation box. This is how it's used at Çatalhöyük. -- Michael Bednarek (talk) 03:52, 29 October 2020 (UTC)

If it is a part of the article then it should not be in a navbox per WP:MOSCOLLAPSE. Some 65% of readers cannot see it as navboxes are not displayed on mobile. Of the remaining 35%, the reasons therein should be sufficient to ditch the navbox. --Izno (talk) 04:58, 29 October 2020 (UTC)