Template talk:Navbox Archive 24

This is an archive of past discussions about Template:Navbox. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 20

←

Archive 22

Archive 23

Archive 24

Doesn't properly handle linebreaks at the start of a sublist

{{navbox
|group1=Foo
|list1=
* Lots of items...
* Numbers
** 1
** 2
}}

has (at least) 5 possible places to create a linebreak:

Between
Lots of items...
and
• Numbers (1 • 2)
Y
Between
Lots of items... •
and
Numbers (1 • 2)
Y
Between
Lots of items... • Numbers (1
and
• 2)
Y
Between
Lots of items... • Numbers (1 •
and
2)
Y
Between
Lots of items... • Numbers
and
(1 • 2)
N

The last version is bad, because the context for the sublist is lost by the time the reader drags their eyes over to it. Nevertheless, navbox lines can (and do) break there.

{{hlist}} may suffer from the same problem (or even originate it). I think some clever CSS hackery can prevent a linebreak before the sublist, but I know neither how to do it, nor how to read/write Lua.

Thanks, Bernanke's Crossbow (talk) 15:22, 24 September 2023 (UTC)

Can you give an example of #5? -- Michael Bednarek (talk) 04:30, 25 September 2023 (UTC)

@Michael Bednarek: Groupings "Phosphorus" and "halo" in {{Functional groups}} (default skin, Firefox 117.0.1/Windows 11 build 22621.2283 on a 1920x1080 screen at 125% scale). Bernanke's Crossbow (talk) 03:08, 27 September 2023 (UTC)

That happens at any screen resolution and is how hlists are intended to work. I suspect the reason is to avoid unsolvable problems if the sublist itself is wider than the display window, which can easily happen in your example for Haloalkalenes. If you want to force, say, Phosphine and Phosphonium to stay together, you could avoid that behaviour of hlist and bind those two with *[[Organophosphine|Phosphine]] ([[Phosphonium]]). Other editors of that template might later be puzzled by that construct and restore standard syntax. Good luck. -- Michael Bednarek (talk) 04:59, 27 September 2023 (UTC)

#invoke:Navbox

The two navboxes at Family tree of Japanese monarchs are not displaying correctly, and are just showing up as anchor links to #invoke:Navbox --Yodin^T 13:32, 13 October 2023 (UTC)

That is because of WP:PEIS. Note that Category:Pages where post-expand include size is exceeded appears in the category list. – Jonesey95 (talk) 15:32, 13 October 2023 (UTC)

Thanks 👍 --Yodin^T 18:47, 13 October 2023 (UTC)

Can you patch line 452? gfind is obseleted in Lua 5.1

Would it be possible to request an edit to line 452, to change local gfind = string.gfind to local gfind = string.gmatch?

It seems that string.gfind is obsoleted in Lua 5.1 (though obviously still available functioning 5.1.5 that the wiki farm is running) and has been renamed to string.gmatch.

While the code works under Lua 5.1.5, it fails under luajit (which a number of large MW installations use), which is (I believe) 100% compatible with Lua 5.1, though I guess the "obsoleted" features aren't considered in that context? Mahmoud (talk) 20:43, 27 November 2023 (UTC)

@Mqudsi: Line 452 where? This template doesn't have that many lines - it has just three. --Redrose64 🌹 (talk) 09:50, 28 November 2023 (UTC)

I suppose the poster meant Module:Navbox#L-452. (No opinion here on the merit.) -- Michael Bednarek (talk) 09:59, 28 November 2023 (UTC)

Yes, I did. I don’t know how I ended up making the comment on the Template page instead! Mahmoud (talk) 20:00, 28 November 2023 (UTC)

Oh, if you go to the talk page on the module you get redirected to the talk page for the template. Mahmoud (talk) 20:01, 28 November 2023 (UTC)

WCAG Compliance - Contrast

Hello, It would be Good if the Colors used in the Navboxes are following Web Content Accessibility Guidelines Compliance. J.Stalin S ^Talk 04:21, 30 November 2023 (UTC)

I might be mistaken, but I do not think that is anything that the navbox itself can handle - problematic navboxes are (as far as I am aware) dealt with on a case-by-case basis. Primefac (talk) 07:23, 30 November 2023 (UTC)

Multiple languages of parameters

Helloo! I want to ask one question about parameters which appear in Navbox and written in Module:Navbox/configuration. I wanted to localise it to KazWiki, and I did it, it's work with kazakh parameters, but i want to add English parameters too, because we have templates which use english parameters also. I tried do, but it's not work, you can watch it here. --Amangeldi Mukhamejan (talk) 09:52, 8 October 2023 (UTC)

@Amangeldi Mukhamejan: What I did on norwegian wikipedia was to just use the module directly in no:Template:Navbox, but create a new translated template no:Template:Navboks where I used both english and norwegian parameters. This way you can use no:Template:Navboks with both norwegian and english parameters, and it will also be very easy when you need to update the module. If you do the same with kk:Template:Шолғы you can use english and kazakh parameters. Tholme (talk) 17:51, 5 December 2023 (UTC)

evenodd?

Is the evenodd parameter actually still needed for anything after this edit to the module in 2017 (relevant discussion)? 「ディノ奴千？！」^{☎ Dinoguy1000} 11:29, 15 December 2023 (UTC)

I don't remember but evenodd is still supported and has an effect. I don't think it is needed. Johnuniq (talk) 23:10, 15 December 2023 (UTC)

autocollapse vs. mw-collapsed

It seems this module adds the autocollapse class. autocollapse is defined in MediaWiki:Common.js. It's unclear to me why it doesn't add mw-collapsed instead which is part of MediaWiki?
Edit: just noticed this note in Common.js: "deprecated Since MediaWiki 1.20: Use class="mw-collapsible" instead which is supported in MediaWiki core. Shimmable since MediaWiki 1.32"
Edit2: I'm not reading right and I get it now. For reference: collapsible is deprecated in favor of mw-collapsible and collapsed is deprecated in favor of mw-collapsed. The function of autocollapse in common.js is specifically to collapse the element only if more than one collapse element exists on the page. So if a page has only one navbox and no other collapsible elements, the navbox will be uncollapsed by default. But if another navbox is added, both will be collapsed by default.
While I see why this can be desired, I think it's also rather confusing, making navboxes act differently depending on the presence of other elements on the page. — Alexis Jazz (talk or ping me) 20:27, 4 September 2023 (UTC)

FWIW, it's how they have worked for a long time. I'm not saying it's good or bad. – Jonesey95 (talk) 22:36, 4 September 2023 (UTC)

Jonesey95, I was testing some stuff and found a navbox to not collapse by default on one article, but collapse by default on another. I thought it was a bug or oversight in something I wrote, only to finally figure out what "autocollapse" actually does.
I suppose we could discuss whether navbox should use autocollapse or not. From what I understand, if an article has one navbox and one collapsible list is added somewhere in the infobox with the autocollapse class that'll also cause the navbox to autocollapse.
Having the navbox as the only collapsible item uncollapsed by default would sometimes make sense. But on a short stub it would look a bit silly. My thought is that editors would be best suited to decide on a per-article basis which (if any) navboxes should be uncollapsed by default. — Alexis Jazz (talk or ping me) 00:57, 5 September 2023 (UTC)

IMO the autocollapsing is a generally a good thing if more than one navbox is present. I wasn't aware that this behaviour is also influenced by other collapsible elements in the body, which are discouraged. I suppose we have to leave it to editors to decide whether overriding |state= is appropriate sometimes (e.g. having one navbox closely related to the the article's subject and several others only loosely related). -- Michael Bednarek (talk) 01:35, 5 September 2023 (UTC)

Alexis Jazz, if I understand your desire correctly: any navbox can be expanded in a given article by adding |state=expanded to its transclusion. You can see this in action at Wikidata#External links or U.S. state#External links. If it doesn't work for a given navbox template, the template's code might need a bit of adjustment; sometimes people delete the standard collapsing code. If you want or need a demo, link to an article and suggest a navbox to be expanded. – Jonesey95 (talk) 03:22, 5 September 2023 (UTC)

Jonesey95, thanks, I think I understand how it works. What mostly bothers me is that this template is essentially depending on the code in Common.js, which is kinda odd and makes it more confusing for any other project to import this template/module. It also confused me when I was testing navboxes on the mobile site where Common.js doesn't get loaded. I've resolved that issue though.
I think I'd personally support changing the default from "autocollapse" to "collapsed", but unless others feel the same I don't expect it to happen. — Alexis Jazz (talk or ping me) 03:47, 5 September 2023 (UTC)

We could of course just change this to be something like. If this is the main namespace, then if there is one navbox have it open, but if there is more than one navbox, collapse them all. and get rid of the entire old auto collapse behaviour. The one problem I see is that I'm not entirely sure where else auto collapse is used. —TheDJ (talk • contribs) 08:26, 27 September 2023 (UTC)

TheDJ, I'm guessing many editors use autocollapse because they confuse it with mw-collapsed, thinking it just means "always automatically collapse this". I only figured out what autocollapse means after analyzing Common.js. If I had no idea it's pretty much guaranteed a new editor has no clue either. (sure it's in the template documentation, but editors often learn by copying existing wikicode) Take a look at Geographic coordinate system: the navbox has the autocollapse state specifically set as a parameter and the navbox gets collapsed due to the presence of {{Geodesy}}. No way that was the intention of any editor. It was added by an IP editor in Geographic coordinate system (Diff ~675689024) btw. This is largely a running theme when looking at Special:Search/insource:autocollapse. My personal opinion is still that it would be clearer if state=collapsed was the default for navboxes and editors would have to set the parameter state=expanded where appropriate. But that's merely my 2 cents.
That being said, changing autocollapse to only react to navboxes would make its behavior a bit easier to understand, more logical and less likely to be triggered accidentally as it is on Geographic coordinate system. The end result on that article may or may not be desirable, but the presence of {{Geodesy}} has no bearing on that. — Alexis Jazz (talk or ping me) 15:47, 27 September 2023 (UTC)

@TheDJ the other notable location for autocollapse is Template:Sidebar with collapsible lists and probably that one's mother-template-by-time of Template:Collapsible list (which ends up in infoboxes). Izno (talk) 18:17, 7 October 2023 (UTC)

Rather late to the party, but I've added an anchor to the state documentation, with the appropriate redirect shortcut WP:AUTOCOLLAPSE, to hopefully help with future confusion. 「ディノ奴千？！」^{☎ Dinoguy1000} 01:09, 16 December 2023 (UTC)

Extraneous bullets in lists

(For background, see Wikipedia:Help desk#Removing a bullet from a template)

In the example above, a bullet is (incorrectly?) rendered after list 2.1a but not after list 1.1a. This may be a MediaWiki bug; viewing this with Parsoid shows no bullet after either. LittlePuppers (talk) 23:46, 19 February 2024 (UTC)

I don't know if it's the actual cause, but removing the blank line between the list items makes the two appear the same for me in edit preview. List items belonging to the same list shouldn't have a blank line between them, or else the MediaWiki parser will treat them as two separate lists. isaacl (talk) 23:57, 19 February 2024 (UTC)

Indeed, that causes them to appear the same, but the intention appears to be subdividing the list: see {{Men's college basketball award navbox}} for one place this is used (and where this question comes from). LittlePuppers (talk) 00:11, 20 February 2024 (UTC)

I see; your naming convention made it seem like the two items belonged to the same list. ~~I don't know which specific section in the navbox you are referring to; could you create a smaller example with real data, or point to the appropriate location to examine?~~ found where to look isaacl (talk) 00:23, 20 February 2024 (UTC)

Using the browser HTML debugging tools, I can see that list item 2.1a isn't being surrounded by <ul>...</ul>, so the CSS style rule that suppresses adding the trailing bullet isn't getting applied. I don't know why this isn't being parsed as a list, though. isaacl (talk) 00:50, 20 February 2024 (UTC)

Also see WP:LISTGAP. It looks like that navbox starts a new list inside of a list where it says "Discontinued". I think that's just GIGO, invalid list markup, so you should not expect good behavior. The fix is to use proper list markup, I think, maybe by nesting more subgroup navboxes. – Jonesey95 (talk) 01:04, 20 February 2024 (UTC)

Discussion on making navboxes compatible with night mode

You are invited to join the discussion at Template talk:Southern California Intercollegiate Athletic Conference navbox § Night mode compatibility?. Sdkb ^talk 19:43, 14 May 2024 (UTC)

Inaccessible links in navbar

This edit request to Module:Navbox/styles.css has been answered. Set the |answered= parameter to no to reactivate your request.

The navbox styled in Module:Navbar/styles.css uses a color contrast for links that doesn't pass AA guidelines for small text.

Please consider adding the following rule or similar:

.navbar a { color: #1C376D; }
.navbar  a:visited { color: #423168; }

? Jdlrobson (talk) 04:37, 2 February 2024 (UTC)

Wouldn't it be better to update the colors for all links in commons.js rather than just these as there are going to be others of a similar size defined elsewhere? -- WOSlinker (talk) 08:37, 2 February 2024 (UTC)

Deactivating request per WOSlinker. * Pppery * _{it has begun...} 04:25, 4 February 2024 (UTC)

The issue is specifically with the Navbar. It is changing the background color but not the link color, so it is creating a color contrast issue. The issue doesn't exist on normal links outside the Navbox so must be made here. Jdlrobson (talk) 22:49, 7 February 2024 (UTC)

You can see the issue on Portal:Current_events in "Current events by month". The background color is set on .navbox-title but the links inside this remain the default #3366cc which creates a color contrast issue (you can run Lighthouse in Chrome dev tools to flag this under "Background and foreground colors do not have a sufficient contrast ratio.")

Another approach would be to drop this rule or change the color to something more compatible with link colors:

.navbox-title {
	background-color: #ccf; /* Level 1 color */
}

Let me know if this request is still not clear. Jdlrobson (talk) 22:55, 7 February 2024 (UTC)

The navbox title color is set in Module:Navbox/styles.css. If the title background color is to be changed then it would probably need the other colors in the navbox reviewing as well so that there is still some differences between the different sections of the navbox. There have been discussions in the past about the set of navbox colors (for example at Template talk:Navbox/Archive 19) and while going for paler colours helps the text to be more visible on the backgrounds, it makes it more difficult to distinguish between different areas of background. Could you make your original css rules more specific so that they only applied to navbars within navboxes? -- WOSlinker (talk) 10:59, 8 February 2024 (UTC)

I think either the background color or the links color should be changed. I assumed the links color would make more sense here and is already scoped to navbars.

If we want navbars inside navboxes the following seems appropriate, no?:

.navbox .navbar a { color: #1C376D; }

.navbox .navbar a:visited { color: #423168; } Jdlrobson (talk) 17:57, 16 February 2024 (UTC)

I've moved this discussion (@Jdlrobson@Pppery@WOSlinker) because I'm fairly certain it concerns only navbars in navboxes.

Regarding which, we have a consensus from 2015 about changing the background colors instead to support AAA which never got implemented. With the adjustments in link colors since due to style guideline adjustments and etc., I think it would be more prudent in the meanwhile to adjust the group/title background colors since those are what are being set to at least support AA (though I anticipate some yowling) with the default colors in Vector22. I would appreciate someone throwing some colors at the wall that are in the generally same palette as today. Izno (talk) 02:14, 23 February 2024 (UTC)

Not doneing the request for now since it is not ready to implement. Izno (talk) 02:15, 23 February 2024 (UTC)

(We can also remove Module:Navbox/styles.css#L-17 when we have the colors ready since there are no navboxes directly next to other navboxes these days.) Izno (talk) 02:31, 23 February 2024 (UTC)

Current blocks of colors that need adjustment:

.navbox-title {
	background-color: #ccf; /* Level 1 color */
}

.navbox-abovebelow,
.navbox-group,
.navbox-subgroup .navbox-title {
	background-color: #ddf; /* Level 2 color */
}

.navbox-subgroup .navbox-group,
.navbox-subgroup .navbox-abovebelow {
	background-color: #e6e6ff; /* Level 3 color */
}

Izno (talk) 02:35, 23 February 2024 (UTC)

And the current link colors in Vector 22 are:

unvisited, hover, focus(visible/within), target: #36c.
visited: #795cb2
and for completeness, active (probably not a big issue since it's orange; nb I'd expect focus color to be similar to active): #faa700

Izno (talk) 02:46, 23 February 2024 (UTC)

AA comparison
Navbox	Unvisited (#36c)	Visited (#795cb2)
Level 1 (#ccf)	3.49	3.42
Level 2 (#ddf)	4.05	3.98
Level 3 (#e6e6ff)	4.38	4.3

Not inspiring! :) Izno (talk) 01:04, 24 February 2024 (UTC)

Well, WMF basically made it impossible to keep colors in navboxes without relying on the "if it's bold, it can have a lower contrast" exception that is in the WCAG AA for contrast, using the Vector 22 link colors. We have to go basically to white and various shades of light grey to meet AA 4.5 for normal text (which I wouldn't hate TBF, and I think I recall someone having a go at that before). All of the levels are in bold text though, so perhaps we just decide to ignore it. Izno (talk) 21:52, 25 February 2024 (UTC)

"WMF basically made it impossible to keep colors in navboxes". How so? What would you have done instead?

It seems like you have several options here:

Use a different link color e.g. black or white (consider underlining the link or adding an icon to make it more obvious it's clickable)
Move the link out of the box.
Put the link itself in a box with a white background

Jdlrobson (talk) 21:45, 28 February 2024 (UTC)

How so? You changed the link colors in Vector in phab:T213778. We probably weren't hitting the requirement specifically for the navbar links before anyway because we couldn't claim to be meeting the exception for bold text that WCAG allows (unlike the rest of the links in these locations), but changing the colors in the way that you did made it much harder to thread any needle whatsoever (my options really are light grey and no other colors and even now the darkest grey I've suggested below misses 4.5 by half a point [that was a number picked out of hat]). (Incidentally, there appear to be remaining issues as discussed on that task that WMF appears to have moved on from without any response.)

Use a different link color e.g. black or white (consider underlining the link or adding an icon to make it more obvious it's clickable) Adding an icon is not feasible with space requirements. Changing the colors is feasible but fails to meet other expectations of links that also pertain to accessibility (namely, that people know it's a link, which is a far broader issue for users) and makes an inconsistent UI to boot. Adding an underline fails similarly on this second option, has minor readability issues with it, and moreover will get 'unaesthetic' arguments thrown at it (people hate underlines). These links aren't intended to stand out.
Move the link out of the box. This is not an option for obvious reasons (stackability of navboxes).
Put the link itself in a box with a white background This will get me yelled at harder than just going all the way to grey in navboxes (example of which below). Uniform color is going to be seen as more important.

The primary argument against doing anything here just to make the arbitrary validator happy is also probably that these links... aren't all that important, so we don't lose a lot by failing contrast requirements for them. The pages at which they point have other ways to be accessed, if not so easily (click edit, find the navbox of interest in the transcluded templates, fin, just like every other template). Which is halfway to an argument for total removal, but that's also probably not something I can get consensus for, because 1. they are handy shortcuts, and 2. the balance between navbar links and show/hide links is aesthetically pleasing. (Well, these are the arguments I can foresee, I personally think I could get used to the issues presented by both.)

I do think something should probably be done not least because I don't like relying on the bold exemption in the context of what are smaller text items anyway for the links that are in the rest of the navbox (navboxes are at 88% font size), but I also don't have to like changing it. :) We probably also aren't going to get to 4.5 regardless though I think we can improve the current state, and on that you're probably going to just need to deal with it and find other valid things to complain about. Izno (talk) 22:10, 28 February 2024 (UTC)

Here's something grey. Visited colors against it are 4.0, 4.46, and 4.7. Our "upper bound" is f7f7f7 which is the grey used for the alternating row color. #eee is the darkest we can start if we want to hit 4.5 against visited.

I doubt keeping any colors is remotely possible.

Izno (talk) 22:13, 25 February 2024 (UTC)

Some other choices would be ditching our triple colors by making groups and titles all the same color and subgroups one color off, as well as nixing the alternating row color (which I would guess no-one can tell is missing these days with how monitors are built). Ditching the alternating colors would make the module simpler, but is much less of a win. I suspect implementing a set of these options is best. Izno (talk) 22:16, 25 February 2024 (UTC)

Night mode may need explicit color definitions

For what it's worth, this template appears to be causing any page using a navbox to be tagged by a new linting rule that tries to identify background colors without an explicit text color. {{Bolvadin District}}, for example, shows three instances (I hesitate to call them errors) on its Page Information page; I think the instances are in the V/T/E section of the template. I have been told that using a URL like https://en.wikipedia.org/wiki/Template:Bolvadin_District?vectornightmode=1 is supposed to show what the page looks like in night mode. For me, ironically, the navbox is the only part of the page that looks reasonable, although it displays in regular, not night, mode; almost everything else on the page is a bunch of blue on black or black on black, so I don't know if night mode has reached a development state in which adding explicit colors will show a useful improvement.

I don't know if there is any action needed here, but it might be worth a discussion either here or in a new subsection of the original linked discussion. – Jonesey95 (talk) 05:17, 23 March 2024 (UTC)

Somewhat (highly?) related to the above discussion. Izno (talk) 06:28, 23 March 2024 (UTC)

Until testing can be done, I'm not sure that there is a lot of point making any changes. -- WOSlinker (talk) 09:10, 23 March 2024 (UTC)

Agreed, unfortunately. Murphy's Law says that we'll spend a bunch of time coming up with a fix and when things get implemented it will side-step everything we've already done. It's not nice playing catchup but it's better than duplicating effort. Primefac (talk) 09:32, 23 March 2024 (UTC)

@Izno I think https://en.wikipedia.org/w/index.php?title=Module%3ANavbox&diff=1217155387&oldid=1157419082 will fix this provided we reorder the style e.g. append rather than prefix (args[cfg.arg.basestyle] or '') - what do you think? 🐸 Jdlrobson (talk) 06:39, 4 April 2024 (UTC)

For an example of what this lint rule is flagging: https://en.wikipedia.org/wiki/G%C3%B6lba%C5%9F%C4%B1,_Ad%C4%B1yaman?useskin=minerva&minervanightmode=1

(For clarification - Vector is 2 weeks away from working properly in night mode so only Minerva URLs are good for now) 🐸 Jdlrobson (talk) 06:42, 4 April 2024 (UTC)

@Jdlrobson, coincidentally, I noticed phab:T361785. Izno (talk) 08:17, 4 April 2024 (UTC)

The point of the styles in that section of the code is to override users setting the properties already listed there (bg, border, box shadow, padding). That's why the list comes after the two arguments.

Ignoring that, you appear to be trying to set these links as the color of normal text (light theme: blackish, dark theme: whiteish) with your suggestion. Which you need consensus for per the above discussion for the reasons I laid out there (namely, Changing the colors is feasible but fails to meet other expectations of links that also pertain to accessibility (namely, that people know it's a link, which is a far broader issue for users) and makes an inconsistent UI to boot.). Please do not reinstate anything remotely like that edit until you have it. I am not sure why you made the edit now that I think about the fact I had already said that, and the rest of what I had said above. Izno (talk) 08:03, 4 April 2024 (UTC)

Could we at least override rules into a stylesheet e.g.

.navbar abbr {
background:none transparent;border:none;box-shadow:none;padding:0;
}

(style attribute will override all of these so it will function the same but it won't trigger the lint warning)

This is creating a lot of noise in the Special:LintErrors which is making it difficult for us to QA the other test cases caused by the lint. 🐸 Jdlrobson (talk) 04:10, 5 April 2024 (UTC)

Jdlrobson I wanted to make a change in the context of TemplateStyling that got this particular block of CSS out of the module, which I've now done in the sandbox by resurrecting a change that I and Frietjes thought up (mostly Frietjes). It restricts the valid CSS for the VTE links to the color property, which is highly used in e.g. sports contexts, but I doubt any other properties are. The second template in Template:Navbox/testcases#Color extraction displays correctly in dark mode now, and the other test navboxes "as expected" for what happens when a color against a white base would otherwise look like (without the "extraneous" CSS that causes dark mode grief). I'll look to deploy this Soon. I hope I get no complaints. :') Izno (talk) 04:14, 17 May 2024 (UTC)

This change is live now and should be percolating. Izno (talk) 21:13, 17 May 2024 (UTC)

This edit request to Module:Navbox has been answered. Set the |answered= parameter to no to reactivate your request.

Assuming I didn't overlook some problem (though the testcases look fine), please copy the changes in Special:Diff/1235534036 to Module:Navbox. This conditionally loads Module:Navbar only when the navbar will actually be displayed (i.e. when |navbar= is not used, basically). I'm aware that I could make this change myself, but it's beyond what I'm comfortable doing on Module:Navbox, even with testcases all looking good, so I'd appreciate someone double-checking the actual change first. It's surprisingly hard keeping "navbox" and "navbar" straight when you're talking about them both... 「ディノ奴千？！」^{☎ Dinoguy1000} 19:53, 19 July 2024 (UTC)

Looks fine. Izno (talk) 19:57, 19 July 2024 (UTC)

Since we're updating the module, I'll also move the display: none that has been hanging out in MediaWiki:Print.css to TemplateStyles, which is this diff. Izno (talk) 20:34, 19 July 2024 (UTC)

Done Izno (talk) 19:25, 22 July 2024 (UTC)

Grey text on a white background

When editing a navbox, anything that is NOT a link is grey text on a white background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 22:20, 23 July 2024 (UTC)

Make navbox-title links show in dark mode

This edit request to Module:Navbox has been answered. Set the |answered= parameter to no to reactivate your request.

proposed fix

The following fix should address the issue described here. I do have edit rights but wanted a second opinion before applying these change.

The issue occurs because a mixture of things:

We have a well-meaning rule in MediaWiki:Vector-2022.css that makes all links black when a background is detected via inline styles (this corrects the large majority of issues in dark mode so we don't want to remove it)
mw:Extension:WikimediaMessages strips styling from navboxes in a way that clashes with the table rule.

My proposed fix is to do this on the template level.

An alternative I considered was to add another !important rule in MediaWiki:Vector-2022.css but I think it is preferable that the fix lives in the navbox styles. Hopefully on the long term we can move the color stripping in WikimediaMessages into the Navbox template itself and this will all be easier to follow. 🐸 Jdlrobson (talk) 18:57, 22 July 2024 (UTC)

The 3rd alternative is to resolve the task in Phab that allows us to turn off the dark mode for specific components, and then we can turn that one off for navbox. That's something that could take an hour or two tops. Izno (talk) 19:10, 22 July 2024 (UTC)

Right this is what I am talking about when I say "on the long term".

we are looking at a least a month for a fix for that to go into production given web team's other commitments. There are far more important issues that need addressing unfortunately.

It would be nice to have a short term fix in the mean time. We can reference the phabricator ticket in an inline comment and I can make sure it gets undone whenever that ticket gets worked on. 🐸 Jdlrobson (talk) 21:30, 22 July 2024 (UTC)

Am I reading the code correctly, inferring that the change applies only to links in the navbox title? If so, what is the fix for visited links in the navbox body, which are also showing as gray-on-black for me? I could be reading the code wrong. – Jonesey95 (talk) 00:43, 23 July 2024 (UTC)

Can you give an example page @Jonesey95? But yeh this is only for navbox title as that was the only issue I was aware of.

If there are other elements these could use the same rules, substituting th.navbox-title for the relevant selector. 🐸 Jdlrobson (talk) 17:59, 23 July 2024 (UTC)

It looks like my memory is wrong. I went back to {{Soulfly}}, and it is only the top navbar title and the subhead title where visited links are turning gray instead of purple. Carry on. – Jonesey95 (talk) 18:03, 23 July 2024 (UTC)

In what I assume is a related CSS problem, on {{Malawian roads}}, I see links to articles as blue or red if non-existent in light mode, but only blue in dark mode. For example, M26 road (Malawi) does not exist, but shows up as blue in dark mode. -- Beland (talk) 20:36, 2 August 2024 (UTC)

FTR, previewing {{Malawian roads}} and changing it to point to {{Navbox/sandbox}} did not fix the red link color problem. -- Beland (talk) 20:41, 2 August 2024 (UTC)

Not done for now: I've fixed this in the template at issue based on upstream support for self-link to Vector-2022/Minerva.css. If there are others (I suspect there may be), we can discuss those then. Izno (talk) 17:39, 5 September 2024 (UTC)

Thanks for the fix! That looks good on {{Malawian roads}} now. -- Beland (talk) 05:45, 6 September 2024 (UTC)

Dark mode white border

In dark mode, for all navboxes, the border looks like this:
Is there a way to fix this so that the borders appear correctly? It's a minor thing but one that affects a lot of articles. — Qwerfjkl talk 11:32, 7 August 2024 (UTC)

The white borders is used to distinguish odd/even list rows. Dabao qian (talk) 05:57, 8 September 2024 (UTC)

They shouldn't be visible borders, though, specially not bright white like that. The borders should be rendered the same color as the other grey borders. This can be fixed in the CSS rules for dark mode, were someone with the ability to edit it could do so. Down10 ^TACO 07:52, 8 October 2024 (UTC)

Directly render child navboxes

Lots of articles exceed the post-expand include size limit due to navboxes taking up a huge amount of bytes. A lot of this is caused by navboxes that include child navboxes, because nesting a navbox template inside another navbox template causes the inner navbox to be counted twice towards the limit (and if you are using the template instead of the module directly, it actually counts 4x). To alleviate this, I have modified Module:Navbox/sandbox to allow child navboxes to be added without having to add an additional template call or module invocation. For example, instead of

{{Navbox
| name = {{subst:PAGENAME}}
| title = Title
| list1  = {{Navbox|child
  | group1 = Group1.1
  | list1  = List1
 }}
| list2  = {{Navbox|child
  | group1 = Group2.1
  | list1  = List1
 }}
}}

You could do

{{Navbox
| name = {{subst:PAGENAME}}
| title = Title
| list1  = child
  | list1_group1 = Group1.1
  | list1_list1  = List1
| list2  = child
  | list2_group1 = Group2.1
  | list2_list1  = List1
}}

The code only kicks in if the text of list# is the "child" keyword AND at least one parameter is specified that starts with "list#_". The result is a drastically smaller post-expand include size and, in my opinion, easier to read code. Of course, the old method, or a combination of the two, still works, as demonstrated at User:Ahecht/sandbox4. Any thoughts before I make a formal edit request? --Ahecht (TALK
PAGE) 20:08, 30 July 2024 (UTC)

I've thought about doing it similar to this. I think I'd rather see something like list1.1 and group1.1 which is a little shorter and probably doesn't result in code too different.

I'm not totally certain we need to opt in with child, I'm pretty sure this could be done without the additional keyword. Izno (talk) 20:16, 30 July 2024 (UTC)

@Izno So a child navbox in "list 4" would use group1.4, list1.4, group1style.4, image.4, or would it be group4.1, list4.1, group4style.1, image4, etc? If it's the former, it shouldn't be any more difficult to code, although it doesn't have the same natural indentation, and the hierarchical order isn't what most people would expect (although using 4.group1, 4.list1, etc. fixes that problem). If it's the latter, the code would certainly be more convoluted since some arguments would be delimited, others wouldn't, and the number to extract is in a different place in different variables. It would also make converting existing navboxes more difficult.

You're right that there's no need to opt in with the child keyword -- we could scan the arguments for delimited ones, extract the list number, and add it to listnums. The only reason I included it is that it makes it clearly visible to someone creating or editing a navbox template that that list number is taken, which should make it less likely they'll accidentally add text to both list# and specify parameters for a child. --Ahecht (TALK
PAGE) 20:58, 30 July 2024 (UTC)

I am slightly more in favour of the listx_listy styling, as it will make visually distinguishing the groups (especially if they are aligned). Primefac (talk) 11:57, 31 July 2024 (UTC)

The thing I'm thinking about is that I've seen 3 or even 4 layers of navboxes, so list1_group1_list1_group1_list1_group1 gets kind of unwieldy. :) Actually, does the implementation work for the more layers case? Izno (talk) 15:52, 31 July 2024 (UTC)

Hrm, good point. Primefac (talk) 16:04, 31 July 2024 (UTC)

@Izno, Primefac The implementation is recursive so it does work with nested lists (I added an example to User:Ahecht/sandbox4), although it would "only" be list1_list1_list1_group1. The more I think about it, the more I dislike the list1_list1 notation (since it's not really a list at that point), and I'm leaning towards either child1_list1/subgroup1_list1 as more descriptive or just 1_list1 as more concise. --Ahecht (TALK
PAGE) 16:47, 31 July 2024 (UTC)

This edit request to Module:Navbox has been answered. Set the |answered= parameter to no to reactivate your request.

I've updated the sandbox at Special:Permalink/1239318936 to accept child1_list1, subgroup1_list1, and 1_list1 notation, as demonstrated at User:Ahecht/sandbox4. It currently requires either the child or subgroup keywords, but that requirement could be potentially removed in a future update. I also made the function that reads the arguments recursive to keep references in the correct order even when children/subgroups are used.--Ahecht (TALK
PAGE) 13:53, 8 August 2024 (UTC)

Done I went ahead and implemented this. Hopefully I didn't just break 8% of Wikipedia! --Ahecht (TALK
PAGE) 18:03, 16 August 2024 (UTC)

zh:Module:NavboxV2 has already achieved directly render child navboxes four years ago and integrated with {{Navbox with columns}} / {{Navbox with collapsible groups}} (throuth the |type= parameter). Dabao qian (talk) 05:52, 8 September 2024 (UTC)

@Dabao qian I've consolidated the three templates into Module:Navbox/sandbox. You can set |type= (or |1_type=) to "with columns" or "with collapsible groups". For {{Navbox with columns}} you use "col1_list1" notation for subgroups of the columns. See Template:Navbox/testcases#allthreetypes for an example. --Ahecht (TALK
PAGE) 01:14, 2 October 2024 (UTC)

Okay, that looks like the Chinese version. Set |type=(default sets to "vertical") to "horizontal" or "vertical_collapsible" to switch {{Navbox with columns}} or {{Navbox with collapsible groups}}. Dabao qian (talk) 13:10, 2 October 2024 (UTC)

@Dabao qian The exact keywords that are used can be set in Module:Navbox/configuration/sandbox as keyword.with_collapsible_groups and keyword.with_columns. I chose "with columns" and "with collapsible groups" because we've been using the names {{navbox with columns}} and {{navbox with collapsible groups}} on the English Wikipedia for the past 7 years so those terms are more familiar than "horizontal" and "vertical_collapsible" (plus it allows replacing {{navbox with columns}} with {{#invoke:navbox|with columns}}). --Ahecht (TALK
PAGE) 17:04, 2 October 2024 (UTC)

I've copied this module to zh-yuewiki (see yue:Module:NavboxV2) and modified for compatibility with zh:Module:NavboxV2. But how to allow both |1_border= and |list1=[child/subgroup] can be used? Dabao qian (talk) 17:18, 2 October 2024 (UTC)

@Dabao qian You shouldn't ever need to use |1_border=. If you use |list1=subgroup, the module automatically sets |1_border=subgroup without you having to specify it (it also automatically sets |1_navbar=plain). You can still use the old method as well, so {{#invoke:NavboxV2|navbox|list1=subgroup|1_list1=List 1}} should produce the same result as {{#invoke:NavboxV2|navbox|list1={{#invoke:NavboxV2|navbox|border=subgroup|navbar=plain|list1=List 1}}}}. --Ahecht (TALK
PAGE) 00:48, 8 October 2024 (UTC)

As the author of NavboxV2, I finally see that enwiki also has the problem of Navbox overload which is similar to zh and needs a solution. I feel touched. (LOL)

Regarding the parameter mode issue:

For the separator, I chose "-" (short dash), and you chose "_" (underscore). This is a personal choice and I don't plan to make compatibility here. It mainly involves the uncertainty of parameter detection (both dashes and underscores need to be detected at the same time), some hard-coded problems (some codes only use dashes as the value of the incoming parameter search), and my laziness;
For sub-body detection, I don't use listN=child because the sub-body detection code of the border parameter can be reused, and the uncertainty of parameter detection can be avoided as same time (it is necessary to guess whether the "child" of listN=child is the mark value of sub-body, or the ordinary list content value. And the former also requires more sub-body parameter detection code);
For regarding adding "list"-like parameters, such as "child" and "subgroup", similarly, since most of the code structure of {{Navbox}} is copied, the code position of the original "list" value, the parameter name is just "list", so keep it simple and don't add too much additional input uncertainty.

The code of NavboxV2 is not integrated into Navbox, but a new template is created. This is because I am not a local administrator and cannot update the code of Navbox at will. In addition, the new template can be debugged and fixed the code at any time to avoid affecting the normal operation of Navbox.

I'll keep an eye on your work and try to see if there's anything interesting I can draw on. --Cwek (talk) 09:35, 9 October 2024 (UTC)

Mobile visibility

Hello all,

I didn't want to be too WP:BOLD and remove the information stating that the template is not visible on mobile, although I checked just a second ago and it is. I also checked the Phab report linked in the header as part of an edit to another page and it seems that the issue has been at least partially resolved.

If someone would be willing to update the page to reflect recent changes, or alternatively tell me that I'm completely wrong lol, let me know!

JuxtaposedJacob (talk) | :) | 01:10, 18 October 2024 (UTC)

Navboxes are not generally visible on mobile. Remsense ‥ 论 01:28, 18 October 2024 (UTC)

Fascinating, I can see the ones on my userpage on mobile, but not the ones in article space.

Thanks!

JuxtaposedJacob (talk) | :) | 04:23, 18 October 2024 (UTC)

They are (now) visible outside of mainspace, so there probably should be a refinement to provide correct information. Izno (talk) 18:13, 18 October 2024 (UTC)

[show] and [hide] buttons miscolored

The [show] and [hide] buttons in the title bar have the pale, external link color on the original Vector skin. They're the only ones with this problem. Please fix this. 89.172.154.11 (talk) 21:11, 27 December 2024 (UTC)

How to make navbox with multiple horizontal bars/headers/sections?

So I'm just wondering, like for example, can I edit a navbox template to add a horizontal subheader? Like something similar to "above" or "below", except that I can insert it into the middle of the template or anywhere else. Do you understand what I mean? I tried to read about how to use the navbox template with collapsible subsections, but it just confused the hell out of me. AHI-3000 (talk) 05:23, 31 December 2024 (UTC)

If you're not looking to add a collapsible child subbox, you could always use a listX without the corresponding groupX, which would put the list values on its own line separating the other groups. At least, I think that's what you're aiming for based on your statement, but I might have misread. Primefac (talk) 17:28, 31 December 2024 (UTC)

@Primefac: I meant a distinct header to place above or between the groups/lists in the navbox, something to help organize a navbox by dividing it into like two or more sets of different groups. AHI-3000 (talk) 18:03, 6 January 2025 (UTC)

Your best bet is probably to use {{Navbox with collapsible groups}} with |stateX=off for each corresponding |groupX=. Primefac (talk) 16:08, 7 January 2025 (UTC)

ID

This template is using ids apparently for aria-labelledby. The ids are the arguments title, above or group1. This causes issues when more than one template is used on a page with the same title. Those pages end up on Special:LintErrors/duplicate-ids, which is currently unsupported by Parsoid, the new parser. I am not convinced these ids are necessary. Could it just have an accessible label and no id, instead of using aria-labelledby? Snævar (talk) 18:42, 26 November 2024 (UTC)

aria-labelledby is because there is no other way to identify the structure for navigation aids (well, there's aria-label lying around or something, but that would just include duplicating the title and then stripping all the potential wikitext and such which is hackier at the end of the day). I looked at this a bit when the lint rolled out and I think the easiest/best solution is just to rip it out for non-full-navboxes, and also removing support for using group1/above, which is most often the issue anyway. (above probably shouldn't be in the fallback list anyway.)

Patches welcome ~ Izno (talk) 19:25, 26 November 2024 (UTC)

The other solution would be doing something like hashing the full contents of the navbox, which is likely to result in a unique ID, and then using that instead. Izno (talk) 19:27, 26 November 2024 (UTC)

Couldn't it just generate a random string? Nardog (talk) 19:33, 26 November 2024 (UTC)

Based on what seed? Either it's unseeded and you're varying the parser cache unreasonably or it's seeded and you still have to figure out where the seed is coming from. Izno (talk) 19:38, 26 November 2024 (UTC)

Hmm. Can a module count how many times it's run on the page? Nardog (talk) 19:55, 26 November 2024 (UTC)

No. And intentionally not, so even if there is a way it's not supported and could be broken at will. Izno (talk) 21:07, 26 November 2024 (UTC)

Also: What's the harm in varying the parser cache? Isn't it generated only once per purge? Nardog (talk) 19:59, 26 November 2024 (UTC)

Uh, I'm not entirely sure what I said there was truthful? I'm just thinking that you can't determine what the content will be on any given day/week/month which is generally bad for caches. Izno (talk) 21:11, 26 November 2024 (UTC)

@Izno, Nardog, Snævar: I implemented a very "quick-and-dirty" hashing scheme in Module:Navbox/sandbox (it just adds up the total length of the arguments), but I don't know enough about aria (or the intent behind its implementation here) to see if it's really working as intended. --Ahecht (TALK
PAGE) 16:59, 8 January 2025 (UTC)

A part of this problem is that sometimes child navboxes get an id. For example Template:2024_United_States_presidential_election has an id from child7_title, even though the child is a part of an larger navbox. That id is never used by aria-labeledby. In that example, there is an conflict on Tom_Hoefling with Template:2016_United_States_presidential_election. The same happens with group1 in child navboxes. Snævar (talk) 20:04, 28 November 2024 (UTC)

Right. I don't really know why group was decided to be a fallback - I can think of basically no legitimate cases. Izno (talk) 06:32, 1 December 2024 (UTC)

TemplateStyles hoisting in collapsible groups

Moved from User talk:Izno

So what's up with {{IPA navigation}}? Is the stripping of TemplateStyles a bug on the module's part? Is there no workaround? Nardog (talk) 15:30, 3 January 2025 (UTC)

As I've commented earlier, it's supposed to work. And does work from the parameters which aren't the relevant lists. I couldn't tell you why it doesn't work. There is no workaround that doesn't require including the 4 separate TemplateStyles invocations directly in the template definition. Izno (talk) 20:21, 3 January 2025 (UTC)

Further discussion might reasonably be on Template talk:Navbox about it, Ahecht has done recent work and can probably fizzle the issue out. Izno (talk) 20:24, 3 January 2025 (UTC)

@Izno Looks like it has something to do with your Special:Diff/1128570433. As far as I can tell, the styles aren't being added back in if the navbox is a subgroup. I can pretty easily change that (as shown at Special:Diff/1268198362), and it does solve the {{IPA navigation}} problem, but I don't know enough about phab:T303378 to know if that will cause other issues. --Ahecht (TALK
PAGE) 15:58, 8 January 2025 (UTC)

That specific diff is when the hoisting was introduced, so if it never worked, it was either buggy from the get go or I just didn't think the issue totally through. Your change shouldn't cause an issue.

T303378 is the reason we have the hoisting in the first place. If/when that's no longer an issue (or when navboxes are displayed on mobile rather than stripped phab:T124168), we should be able to delete the relevant code entirely, but who knows when that will be. Izno (talk) 20:48, 8 January 2025 (UTC)

Thanks, and sorry for the confusing on the IPA navigation template. I could've sworn I was editing the sandbox. --Ahecht (TALK
PAGE) 20:50, 8 January 2025 (UTC)

You did. And then you also didn't. ;D

One thing about your adjustment, and there may just be nothing we can or want to do about it, is that it's pulling up the navbox templatestyles sheet into navbox-styles. These are naturally deduplicated by TemplateStyles so it probably isn't a big deal... Izno (talk) 20:55, 8 January 2025 (UTC)

And it seems to be pulling up a lot more copies into navbox-styles than it should. I think I count 5 plus the original? And something like 4 tags for the hlist styles plus the original that should already be there. Izno (talk) 20:57, 8 January 2025 (UTC)

@Izno I fixed some of the duplication by making hiding_templatestyles a global variable instead of outputting <div class="navbox-styles">...</div> for each of the child navboxes. The extra hlist styles are there because they're correctly being pulled from {{flatlist}}, which is in {{IPA common}}, which is in {{IPA pulmonic consonants}}, {{IPA non-pulmonic consonants}}, {{IPA co-articulated consonants}}, and {{IPA vowels}} (there's the 4 extra tags). --Ahecht (TALK
PAGE) 22:29, 8 January 2025 (UTC)

Ah nice. Izno (talk) 22:34, 8 January 2025 (UTC)

Revisiting merging Module:Navbox, Module:Navbox with collapsible groups, and Module:Navbox with columns

I'd like to revisit merging Module:Navbox, Module:Navbox with collapsible groups, and Module:Navbox with columns, as discussed in #Directly render child navboxes, now that the dust has had time to settle on those changes and the implementation of Module:Navbox with columns.

Module:Navbox/sandbox is currently set up to serve as the backend for all three templates. This has the advantage of keeping the code and configuration files in one place, so that it's easier to maintain consistency between the three, and allows for nesting one type of navbox inside another using the |type= (or |1_type=) parameter. It also allows replacing a call to {{navbox with columns}} or {{navbox with collapsible groups}} with {{#invoke:navbox|with columns}} or {{#invoke:navbox|with collapsible groups}}.

The downside is that Module:Navbox gets larger and somewhat harder to navigate, but I think the reuse of the helper functions makes it worth it.

Thoughts? --Ahecht (TALK
PAGE) 21:35, 7 January 2025 (UTC)

No fundamental issue for me. You might want to take a look at user talk:Izno#Navbox (I don't think your changes caused that issue but maybe they did, IDK). Izno (talk) 21:39, 7 January 2025 (UTC)

Done. Feel free to revert if this causes any problems. --Ahecht (TALK
PAGE) 19:30, 22 January 2025 (UTC)

I reverted due to issues with {{taxonbar}} and {{Military navigation}} that were not captured by the testcases. I have re-deployed the change with that bug fixed, but we'll see what else crops up. --Ahecht (TALK
PAGE) 20:05, 22 January 2025 (UTC)

generates errors from Module:Military navigation

When {{Military navigation}} is invoked, it ends up invoking Module:navbox which produces the error "Lua error in Module:Navbox at line 192: attempt to concatenate field 'argHash' (a nil value).". This is true even on the Module:Military_navigation page. What is causing this error? -- mikeblas (talk) 19:42, 22 January 2025 (UTC)

Ahecht, is this problem caused by your changes? The error appears on very many pages. -- mikeblas (talk) 19:49, 22 January 2025 (UTC)

@Mikeblas Yup, I've reverted and and working on deploying a fix now. --Ahecht (TALK
PAGE) 19:58, 22 January 2025 (UTC)

Still broken - see Wikipedia:Village_pump_(technical)#Incomprehensible_error_message.Nigel Ish (talk) 20:13, 22 January 2025 (UTC)

Default styles create Lint Errors

Since the default styles (bodystyle, basestyle, titlestyle, etc.) set background colors but do not set text colors, using this template creates Lint Errors. Please fix. Rob Kelk 23:14, 30 January 2025 (UTC)

This cannot be systematically corrected. Sorry. Specific templates setting colors will need to fix their inputs. Izno (talk) 23:35, 30 January 2025 (UTC)

Why not? It should be a simple addition to the code. --Rob Kelk 01:46, 31 January 2025 (UTC)

Whether it's appropriate to inherit colors is going to depend on the background itself. Izno (talk) 19:26, 31 January 2025 (UTC)

The backgrounds are specifically defined in the default styles. (That's what's creating the Lint Errors; background colors are specified but text colors are not. In order to stop creating the errors, either both need to be defined or neither need to be defined.) --Rob Kelk 20:36, 31 January 2025 (UTC)

If it's the default styles you're actually complaining about, which are not in fact set by any of the various style parameters as referenced in your initial comment, I refer you to this discussion. Izno (talk) 01:40, 1 February 2025 (UTC)

So it's been fixed for months but nobody updated the Documentation subpage to match? --Rob Kelk 15:30, 1 February 2025 (UTC)

Possibly. The documentation is not protected, so if you see a problem with it, and you know how to fix it, please do so. If you are reporting a problem with a specific page, please link to a page with an actual problem. – Jonesey95 (talk) 03:43, 3 February 2025 (UTC)

I didn't know that I had to specify that it was this page's documentation when talking about this page. Also, I don't know how things were fixed. --`Rob Kelk

A PHP Error was encountered

A PHP Error was encountered

Template talk:Navbox/Archive 24

Doesn't properly handle linebreaks at the start of a sublist

#invoke:Navbox

Can you patch line 452? gfind is obseleted in Lua 5.1

WCAG Compliance - Contrast

Multiple languages of parameters

evenodd?

autocollapse vs. mw-collapsed

Extraneous bullets in lists

Discussion on making navboxes compatible with night mode

Inaccessible links in navbar

Night mode may need explicit color definitions

Edit request (conditionally load Module:Navbar)

Grey text on a white background

Make navbox-title links show in dark mode

Dark mode white border

Directly render child navboxes

Mobile visibility

[show] and [hide] buttons miscolored

How to make navbox with multiple horizontal bars/headers/sections?

ID

TemplateStyles hoisting in collapsible groups

Revisiting merging Module:Navbox, Module:Navbox with collapsible groups, and Module:Navbox with columns

generates errors from Module:Military navigation

Default styles create Lint Errors