Template talk:Navbox

Edit request (conditionally load Module:Navbar)

[edit]

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)[reply]

Looks fine. Izno (talk) 19:57, 19 July 2024 (UTC)[reply]
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)[reply]
 Done Izno (talk) 19:25, 22 July 2024 (UTC)[reply]
[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
 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)[reply]
Thanks for the fix! That looks good on {{Malawian roads}} now. -- Beland (talk) 05:45, 6 September 2024 (UTC)[reply]

Grey text on a white background

[edit]

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)[reply]

Directly render child navboxes

[edit]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]
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)[reply]
Hrm, good point. Primefac (talk) 16:04, 31 July 2024 (UTC)[reply]
@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)[reply]
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)[reply]
 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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]

Dark mode white border

[edit]

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)[reply]

The white borders is used to distinguish odd/even list rows. Dabao qian (talk) 05:57, 8 September 2024 (UTC)[reply]
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)[reply]

Mobile visibility

[edit]

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)[reply]

Navboxes are not generally visible on mobile. Remsense ‥ 论 01:28, 18 October 2024 (UTC)[reply]
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)[reply]
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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Navbox&oldid=1251898278"