This template (like all templates) is within the scope of WikiProject Templates, a group dedicated to improving the maintenance of Wikipedia's templates. This particular template is especially important to the project because it is used in the maintenance of other templates. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TemplatesWikipedia:WikiProject TemplatesTemplate:WikiProject TemplatesTemplates
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.
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
}}}}
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]
@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]
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)[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.
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. — Qwerfjkltalk11:32, 7 August 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. Down10TACO07:52, 8 October 2024 (UTC)[reply]
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!
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]
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)[reply]
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.)
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Moved from User talk:Izno
