Template talk:Navbox

Edit request (conditionally load Module:Navbar)

This edit request to Module:Navbox has been answered. Set the |answered= or |ans= 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)

Make navbox-title links show in dark mode

This edit request to Module:Navbox has been answered. Set the |answered= or |ans= 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)

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)

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= or |ans= 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)

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. — Qwerfjkltalk 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)