Template talk:Navbox

In the dark appearance, every other "group" has a distracting bright line to its left and top. I suspect this is not intentional. 71.70.166.171 (talk) 01:42, 8 July 2025 (UTC) [reply ]

This issue is related to T395828 from last month and before that, T365330 from May 2024, both still open. See also this discussion from May 2025 and before that, this discussion from October 2024. – Jonesey95 (talk) 05:19, 8 July 2025 (UTC) [reply ]

3.49:1 for the navbox's heading and 4.05:1 for its sub-headings. I think we should change them to something from here. Sapphaline (talk) 10:37, 28 July 2025 (UTC) [reply ]

This was last discussed in the context of navbar. You can take a look at the discussion there. Izno (talk) 00:13, 29 July 2025 (UTC) [reply ]

Is it possible to change the link color in this template to Vector's (#0645ad) then? Sapphaline (talk) 09:14, 29 July 2025 (UTC) [reply ]

There seems to be a bug where autocollapse collapses the Navbox, even when (seemingly) no other collapsible elements are present on the page. Examples include: Amphibian, Aldous Huxley, Achilles.

Huwiki uses identical instances of the Navbox module and the autocollapse script. This bug was first noticed in the Algona (Iowa) article, where the removal of the Infobox makes the Navbox open. Is this a known issue? Pinging @TheDJ as the maintainer of the autocollapse script. ~ Boro (talk) 01:07, 6 August 2025 (UTC) [reply ]

Authority control and similar templates are navboxes and have the relevant classes emitted. That even is relevant at hu. Izno (talk) 03:12, 6 August 2025 (UTC) [reply ]

Is this the intended behavior though? With the rise of Authority control and other collapsible elements, even singular Navboxes will close off and can't fulfill their majestic purpose of showing related content to readers at a glance. ~ Boro (talk) 07:48, 6 August 2025 (UTC) [reply ]

My first impression is to agree with Boro. Auth control doesn't *seem* like a navbox, regardless of its actual construction and inclusion (or not) as a navbox that could cause another navbox to autocollapse. Maybe auth should be under a different class? Mathglot (talk) 08:25, 6 August 2025 (UTC) [reply ]

Authority control has been present for as long as navboxes have and probably about as long as we've supported autocollapsing. That people have added it everywhere seems to be more an issue with that behavior (sometimes via bot) and less with the functioning of autocollapse.

I would not support changing either authority control or autocollapse on the point. Izno (talk) 15:17, 6 August 2025 (UTC) [reply ]

This is not the case on huwiki. The local implementation of Authority control was introduced 5 years after the navbox, and to add to that, up until today [1] it hasn't been emitting the collapse classes. I understand that this might be irrelevant for this wiki and that we could easily modify our instance. My goal right now is to understand your (that is, enwiki's) considerations, since the templates are more widely used and tested here, so we can proceed based on that knowledge.

When huwiki introduced the navbox, the reality was that no other elements were using the collapse classes, and autocollapse only activated when there were two or more navboxes adjacent to each other. Even the name "autocollapse" implies that the navbox should normally be expanded and only collapse in certain situations. These should not include situations in which templates distant from the navbox affect its behavior. My main argument is that the autocollapse feature in this template should only consider other collapsible navboxes. It should not account for navboxes in a plain/off state, sidebars, infoboxes, or any other templates having a collapse class.

In short, the expected behavior is this: a lone navbox at the bottom of the page should always remain open.

It's a separate discussion (and should not be the current one) whether 2 navboxes should remain open, as that would expand the current definition of autocollapse. Currently, the clear loser in this situation is Authority control, which I expect is more often paired with another navbox than not. However, whether Authority control should be collapsed or not, is not the point of this thread. I hope this makes it clearer what I meant when I said this is a bug, without getting sidetracked. ~ Boro (talk) 21:05, 6 August 2025 (UTC) [reply ]

Also, I'm curious: what would you say if, in addition to excluding plain/off states, collapsed states were excluded as well?" ~ Boro (talk) 21:16, 6 August 2025 (UTC) [reply ]

The collapsed state is caused by another collapsible list in the infobox. --Bean49 (talk) 11:02, 6 August 2025 (UTC) [reply ]

This is the other common "why does it autocollapse". Izno (talk) 15:16, 6 August 2025 (UTC) [reply ]

@Ahecht: I've found two issues of argHash during make patch for zh:Module:Navbox (sandbox):

1. The lengths of |listN= parameters will not count towards argHash value.
2. The |argHash= parameter which from a navbox template will not pass into module.

These issues above appears on enwiki, but zhwiki (still uses the old version of module previous 2024) not. Dabao qian (talk) 16:47, 1 September 2025 (UTC) [reply ]

@Dabao qian For number 1, I don't see any reason why |listN= parameters shouldn't be counted as long as they have a string value, but I'll look into it sooner. As for #2, argHash is always automatically calculated, so it's not supposed to be passed from the template to the module (unless I'm misunderstanding what you mean). --Ahecht (TALK
PAGE) 03:55, 2 September 2025 (UTC) [reply ]

@Dabao qian Actually, looking into it further, the entire first try at calculating argHash in p.navbox is now unnecessary given that code was later added to calculate it in p._navbox. There's a version in the sandbox that eliminates that redundancy, which also means that |listN= is now counted correctly. Try it out, and I can sync the changes over to the main module at some point. --Ahecht (TALK
PAGE) 04:26, 2 September 2025 (UTC) [reply ]

Now the issus has been resolved and |listN=is counted correctly. Dabao qian (talk) 04:42, 2 September 2025 (UTC) [reply ]

Offtopic: ... I was there for when this hash got added and somehow didn't remember it. Good to know at least one thing is off the list. It does appear to be working; Template:Warcraft universe's accessibility properties identify the navigation region as "Warcraft", which is the title of the navbox. Izno (talk) 16:32, 2 September 2025 (UTC) [reply ]

To be honest, I'm kind of on the fence as to what the ARIA role should've been here @Izno. I was onboard with navigation, but I've been reading ARIA more and more, and from what I saw at Robert_Redford#Citations as an example, was waaay too many navigation elements. The banner/toolbar from Wikipedia has three already I think, if not more. The article has over 20 navboxes, which leads to so many high-level DOM navigation elements that clutter the heading lists made by Voiceover for example. I've looked at the other roles available [2], [3] as it's sufficiently important that with an ARIA label pointing to the heading as a baseline, which should be possible to be overriden by the user, but the heading should be wrapped in a span+ID, and the ID referred to by the element given role=navigation aria-labelledby=ID waddie96 ★ (talk) 13:52, 19 September 2025 (UTC) [reply ]

I'm unsure if it possibly matches this 'Disclosure' example from the newest ARIA Authoring Practices Guide draft, if it's enough "high-level top domain links" because it really isn't for the most part... or if it's something else like role=region being a bit plainer waddie96 ★ (talk) 13:55, 19 September 2025 (UTC) [reply ]

The image and imageleft parameters to be deprecated --2600:1700:6180:6290:B0E2:DAA1:CCE8:7D41 (talk) 16:53, 21 September 2025 (UTC) [reply ]

When looking at many navboxes such as Template:Donald Trump, these images violate WP:DECOR, and the image and imageleft parameters should be deprecated and not to be used for new work. This is a statement from Wikipedia:Manual of Style/Icons § Encyclopedic purpose on when and when not to use images in articles:

Icons should serve an encyclopedic purpose and not merely be decorative. They should provide additional useful information on the article subject, serve as visual cues that aid the reader's comprehension, or improve navigation. Icons should not be added only because they look good: one reader's harmless decoration may be another reader's distraction. An icon is purely decorative if it does not improve comprehension of the article subject and serves no navigational function. Where icons are used for layout purposes only, consider using bullet points as an alternative.

In order to comply with the WP:DECOR guideline, I think deprecating the image and imageleft parameters would make more sense than having to create a guideline inside Wikipedia:Navigation template § Navigation templates are not arbitrarily decorative. --2600:1700:6180:6290:B0E2:DAA1:CCE8:7D41 (talk) 16:53, 21 September 2025 (UTC) [reply ]

• Oppose as written. The images at Template:Donald Trump are not icons. The OP appears to misunderstand what an Icon (computing) is. – Jonesey95 (talk) 22:46, 21 September 2025 (UTC) [reply ]
• Oppose - Per Jonesey95 - FlightTime (open channel) 22:58, 21 September 2025 (UTC) [reply ]
• Oppose, nothing about images in the language, only icons. Apples and baked potatoes. Randy Kryn (talk) 01:24, 22 September 2025 (UTC) [reply ]
• Oppose, been here, discussed this. Cambalachero (talk) 02:42, 22 September 2025 (UTC) [reply ]
• Oppose that prohibition on icons only applies to the article body. Otherwise, templates such as {{refimprove }} and {{Footy-stub }} would also be in violation. --Ahecht (TALK
  PAGE) 16:32, 24 September 2025 (UTC) [reply ]

• Documenting what, if any, WP:RFCBEFORE has taken place, would be appreciated. Also, this discussion though named an RFC does not have a {{rfc }} and I do not know if that is intentional. Izno (talk) 23:44, 21 September 2025 (UTC) [reply ]
• This proposal has already been formulated at Wikipedia talk:Categories, lists, and navigation templates/Archive 16#Images in navboxes (again). For starters, the quoted page is about icons and does not apply here. Cambalachero (talk) 02:41, 22 September 2025 (UTC) [reply ]