Jump to content

Template talk:Navbox

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Module talk:Navbox)

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

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)[reply]
 Done. Feel free to revert if this causes any problems. --Ahecht (TALK
PAGE
)
19:30, 22 January 2025 (UTC)[reply]
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)[reply]

generates errors from Module:Military navigation

[edit]

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

Ahecht, is this problem caused by your changes? The error appears on very many pages. -- mikeblas (talk) 19:49, 22 January 2025 (UTC)[reply]
@Mikeblas Yup, I've reverted and and working on deploying a fix now. --Ahecht (TALK
PAGE
)
19:58, 22 January 2025 (UTC)[reply]
Still broken - see Wikipedia:Village_pump_(technical)#Incomprehensible_error_message.Nigel Ish (talk) 20:13, 22 January 2025 (UTC)[reply]

Default styles create Lint Errors

[edit]

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

This cannot be systematically corrected. Sorry. Specific templates setting colors will need to fix their inputs. Izno (talk) 23:35, 30 January 2025 (UTC)[reply]
Why not? It should be a simple addition to the code. --Rob Kelk 01:46, 31 January 2025 (UTC)[reply]
Whether it's appropriate to inherit colors is going to depend on the background itself. Izno (talk) 19:26, 31 January 2025 (UTC)[reply]
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)[reply]
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)[reply]
So it's been fixed for months but nobody updated the Documentation subpage to match? --Rob Kelk 15:30, 1 February 2025 (UTC)[reply]
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)[reply]
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

Improved readability

[edit]
Other languages:
Korean English

For improved readability, how about deleting

:css('padding', '3px')  on line 531
:css('width', '1px')  on line 171
:css('width', '1px')   on line 255

and changing the 8th line of Module:Navbox/styles.css to 0px?

Changed result (sandbox):

Whatback11 (talk) 15:33, 29 April 2025 (UTC)[reply]

This would need to be tested with multiple other configurations e.g. subboxes and groups, and all of those have a reason themselves anyway. Width of 1px is there to ensure certain cells are guaranteed to be the minimum size, and padding is insufficient for e.g. the image cell (and I suspect is there for whitespace between rows). Izno (talk) 16:13, 29 April 2025 (UTC)[reply]
What exactly does 'certain cell' mean? Whatback11 (talk) 10:36, 1 May 2025 (UTC)[reply]
We want to minimize the width of the group cells, and setting their width to 1px does so. Or did so, I'm not sure which. That's why those are set to 1px in those locations. Izno (talk) 16:08, 1 May 2025 (UTC)[reply]
What's this Korean thing for? --Redrose64 🌹 (talk) 21:09, 29 April 2025 (UTC)[reply]
The user started the same conversation on ko.wp. Izno (talk) 23:18, 29 April 2025 (UTC)[reply]
I appear to have been mentioned at ko: wikipedia. Pointless really, as I don't read a word of it, as my user page there clearly states. --Redrose64 🌹 (talk) 20:20, 4 May 2025 (UTC)[reply]
You were mentioned via being quoted, because of your earlier question. (Technically, not a direct quote. A translated version of your comment was attributed to you.) Whatback11 is continuing to mirror the conversation between the Korean and English versions of this discussion. (With translations of each comment.) I'll now be mentioned as well, presumably. FeRDNYC (talk) 09:06, 14 May 2025 (UTC)[reply]
I'm confused. Module:Navbox hasn't changed since January, yet I can find no :css('padding', '3px') on line 531, no :css('width', '1px') on line 171, and no :css('width', '1px') on line 255.
In general principle, though, applying inline styles when generating HTML programmatically is a code smell. Even if those styles are needed, that's what style classes are for. It's as easy to generate a class="" attribute as it is to generate a style="" attribute, and the class="" doesn't screw up your carefully-planned CSS (or interfere with being able to make design updates down the road just by tweaking that CSS).
And if the styles apply in certain specific situations that can only be determined algorithmically, that's fine. (Although it's surprising just how much you can accomplish using pure CSS, thanks to pseudo-classes like :first-child, :nth-of-type, and if you can afford to get really fancy, :has().) But even in code-only situations, it's still better to define a new class to represent those cases, :addClass() that in the code, and apply the styles to the class instead of inline. (We have TemplateStyles for a reason, after all.)
The overuse of inline styles is almost certainly a big part of why there are so many ugly !important rules in the various site and skin CSS files, as designers then try to force the CSS to override style="" attributes. And when it comes to code smells, they don't get much stinkier than !important.
So, IOW — and purely in my opinion (though it's not a particularly humble one, in this instance) — if "the group cells" need to have a width of 1px, and only the code can determine what's a group cell...
Bad
if i_am_a_group_cell_and_I_have_an_image  -- or whatever
then
    row
        :tag('td')
            :stuffStuff()
            :css('width', '1px')
Good
if i_am_a_group_cell_and_I_have_an_image then
    row
        :tag('td')
            :stuffStuff()
            :addClass(cfg.class.navbox_group_cell_with_image)
coupled with, in the TemplateStyles,
td.navbox-group-with-image {
  width: 1px;
}
FeRDNYC (talk) 09:59, 14 May 2025 (UTC)[reply]
I think the reason this is inline CSS and not classes is that the class names would be just as long as what is added inline, or something to that effect. What they're doing here also doesn't have any particular need to be overwritten by arbitrary other requirements. (I'm not particularly compelled to defend the position.)
That said, this section isn't about them being inline but instead solely about their existence at all. Izno (talk) 17:04, 14 May 2025 (UTC)[reply]