Template talk:navbox#Moving to a streamlined navbox

When {{tl|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)

:{{u|Ahecht }}, is this problem caused by {{diff||1271144115|1243116216|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)

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

class="wikitable" |+ {{int:tpt-languages-legend}}
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):

{{Navbox/sandbox

| name = Navbox/doc

| state = uncollapsed

| title = {{{title}}}
test

| above = {{{above}}}
test

| image = {{{image}}}

| group1 = {{{group1}}}
test

| list1 = {{{list1}}}
test

| group2 = {{{group2}}}
test

| list2 = {{{list2}}}
test

| group3 = {{{group3}}}
test

| list3 = {{{list3}}}
test

| group4 = {{{group4}}}
test

| list4 = {{{list4}}}
test

| below = {{{below}}}
See alternate navbox formats under: Layout of table

}} Whatback11 (talk) 15:33, 29 April 2025 (UTC)

: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)

::What exactly does 'certain cell' mean? Whatback11 (talk) 10:36, 1 May 2025 (UTC)

:::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)

:What's this Korean thing for? --Redrose64 🌹 (talk) 21:09, 29 April 2025 (UTC)

::The user started the same conversation on ko.wp. Izno (talk) 23:18, 29 April 2025 (UTC)

:::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)

::::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.) {{u|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)

: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)

::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)

{{edit template protected|Module:Navbox/configuration|answered=yes}}

I propose to change text at line 114, as it seems like a typo:

{{TextDiff|colhfooterstyle {{=}} 'colfooterstyle',|colfooterstyle {{=}} 'colfooterstyle',}} Repakr (talk) 15:39, 17 June 2025 (UTC)

:{{ping|Ahecht}} since you poked at this merge. Izno (talk) 19:26, 17 June 2025 (UTC)

:{{ping|Repakr|Izno}} {{done}} --Ahecht (TALK
PAGE) 20:06, 17 June 2025 (UTC)