Template talk:Navbox

autocollapse vs. mw-collapsed

It seems this module adds the autocollapse class. autocollapse is defined in MediaWiki:Common.js. It's unclear to me why it doesn't add mw-collapsed instead which is part of MediaWiki?
Edit: just noticed this note in Common.js: "deprecated Since MediaWiki 1.20: Use class="mw-collapsible" instead which is supported in MediaWiki core. Shimmable since MediaWiki 1.32"
Edit2: I'm not reading right and I get it now. For reference: collapsible is deprecated in favor of mw-collapsible and collapsed is deprecated in favor of mw-collapsed. The function of autocollapse in common.js is specifically to collapse the element only if more than one collapse element exists on the page. So if a page has only one navbox and no other collapsible elements, the navbox will be uncollapsed by default. But if another navbox is added, both will be collapsed by default.
While I see why this can be desired, I think it's also rather confusing, making navboxes act differently depending on the presence of other elements on the page. — Alexis Jazz (talk or ping me) 20:27, 4 September 2023 (UTC)

FWIW, it's how they have worked for a long time. I'm not saying it's good or bad. – Jonesey95 (talk) 22:36, 4 September 2023 (UTC)

Jonesey95, I was testing some stuff and found a navbox to not collapse by default on one article, but collapse by default on another. I thought it was a bug or oversight in something I wrote, only to finally figure out what "autocollapse" actually does.
I suppose we could discuss whether navbox should use autocollapse or not. From what I understand, if an article has one navbox and one collapsible list is added somewhere in the infobox with the autocollapse class that'll also cause the navbox to autocollapse.
Having the navbox as the only collapsible item uncollapsed by default would sometimes make sense. But on a short stub it would look a bit silly. My thought is that editors would be best suited to decide on a per-article basis which (if any) navboxes should be uncollapsed by default. — Alexis Jazz (talk or ping me) 00:57, 5 September 2023 (UTC)

IMO the autocollapsing is a generally a good thing if more than one navbox is present. I wasn't aware that this behaviour is also influenced by other collapsible elements in the body, which are discouraged. I suppose we have to leave it to editors to decide whether overriding |state= is appropriate sometimes (e.g. having one navbox closely related to the the article's subject and several others only loosely related). -- Michael Bednarek (talk) 01:35, 5 September 2023 (UTC)

Alexis Jazz, if I understand your desire correctly: any navbox can be expanded in a given article by adding |state=expanded to its transclusion. You can see this in action at Wikidata#External links or U.S. state#External links. If it doesn't work for a given navbox template, the template's code might need a bit of adjustment; sometimes people delete the standard collapsing code. If you want or need a demo, link to an article and suggest a navbox to be expanded. – Jonesey95 (talk) 03:22, 5 September 2023 (UTC)

Jonesey95, thanks, I think I understand how it works. What mostly bothers me is that this template is essentially depending on the code in Common.js, which is kinda odd and makes it more confusing for any other project to import this template/module. It also confused me when I was testing navboxes on the mobile site where Common.js doesn't get loaded. I've resolved that issue though.
I think I'd personally support changing the default from "autocollapse" to "collapsed", but unless others feel the same I don't expect it to happen. — Alexis Jazz (talk or ping me) 03:47, 5 September 2023 (UTC)

We could of course just change this to be something like. If this is the main namespace, then if there is one navbox have it open, but if there is more than one navbox, collapse them all. and get rid of the entire old auto collapse behaviour. The one problem I see is that I'm not entirely sure where else auto collapse is used. —TheDJ (talk • contribs) 08:26, 27 September 2023 (UTC)

TheDJ, I'm guessing many editors use autocollapse because they confuse it with mw-collapsed, thinking it just means "always automatically collapse this". I only figured out what autocollapse means after analyzing Common.js. If I had no idea it's pretty much guaranteed a new editor has no clue either. (sure it's in the template documentation, but editors often learn by copying existing wikicode) Take a look at Geographic coordinate system: the navbox has the autocollapse state specifically set as a parameter and the navbox gets collapsed due to the presence of {{Geodesy}}. No way that was the intention of any editor. It was added by an IP editor in Geographic coordinate system (Diff ~675689024) btw. This is largely a running theme when looking at Special:Search/insource:autocollapse. My personal opinion is still that it would be clearer if state=collapsed was the default for navboxes and editors would have to set the parameter state=expanded where appropriate. But that's merely my 2 cents.
That being said, changing autocollapse to only react to navboxes would make its behavior a bit easier to understand, more logical and less likely to be triggered accidentally as it is on Geographic coordinate system. The end result on that article may or may not be desirable, but the presence of {{Geodesy}} has no bearing on that. — Alexis Jazz (talk or ping me) 15:47, 27 September 2023 (UTC)

@TheDJ the other notable location for autocollapse is Template:Sidebar with collapsible lists and probably that one's mother-template-by-time of Template:Collapsible list (which ends up in infoboxes). Izno (talk) 18:17, 7 October 2023 (UTC)

Rather late to the party, but I've added an anchor to the state documentation, with the appropriate redirect shortcut WP:AUTOCOLLAPSE, to hopefully help with future confusion. 「ディノ奴千？！」^{☎ Dinoguy1000} 01:09, 16 December 2023 (UTC)

evenodd?

Is the evenodd parameter actually still needed for anything after this edit to the module in 2017 (relevant discussion)? 「ディノ奴千？！」^{☎ Dinoguy1000} 11:29, 15 December 2023 (UTC)

I don't remember but evenodd is still supported and has an effect. I don't think it is needed. Johnuniq (talk) 23:10, 15 December 2023 (UTC)

Extraneous bullets in lists

(For background, see Wikipedia:Help desk#Removing a bullet from a template)

In the example above, a bullet is (incorrectly?) rendered after list 2.1a but not after list 1.1a. This may be a MediaWiki bug; viewing this with Parsoid shows no bullet after either. LittlePuppers (talk) 23:46, 19 February 2024 (UTC)

I don't know if it's the actual cause, but removing the blank line between the list items makes the two appear the same for me in edit preview. List items belonging to the same list shouldn't have a blank line between them, or else the MediaWiki parser will treat them as two separate lists. isaacl (talk) 23:57, 19 February 2024 (UTC)

Indeed, that causes them to appear the same, but the intention appears to be subdividing the list: see {{Men's college basketball award navbox}} for one place this is used (and where this question comes from). LittlePuppers (talk) 00:11, 20 February 2024 (UTC)

I see; your naming convention made it seem like the two items belonged to the same list. I don't know which specific section in the navbox you are referring to; could you create a smaller example with real data, or point to the appropriate location to examine? found where to look isaacl (talk) 00:23, 20 February 2024 (UTC)

Using the browser HTML debugging tools, I can see that list item 2.1a isn't being surrounded by <ul>...</ul>, so the CSS style rule that suppresses adding the trailing bullet isn't getting applied. I don't know why this isn't being parsed as a list, though. isaacl (talk) 00:50, 20 February 2024 (UTC)

Also see WP:LISTGAP. It looks like that navbox starts a new list inside of a list where it says "Discontinued". I think that's just GIGO, invalid list markup, so you should not expect good behavior. The fix is to use proper list markup, I think, maybe by nesting more subgroup navboxes. – Jonesey95 (talk) 01:04, 20 February 2024 (UTC)

Inaccessible links in navbar

The navbox styled in Module:Navbar/styles.css uses a color contrast for links that doesn't pass AA guidelines for small text.

Please consider adding the following rule or similar:

.navbar a { color: #1C376D; }
.navbar  a:visited { color: #423168; }

? Jdlrobson (talk) 04:37, 2 February 2024 (UTC)

Wouldn't it be better to update the colors for all links in commons.js rather than just these as there are going to be others of a similar size defined elsewhere? -- WOSlinker (talk) 08:37, 2 February 2024 (UTC)

Deactivating request per WOSlinker. * Pppery * _{it has begun...} 04:25, 4 February 2024 (UTC)

The issue is specifically with the Navbar. It is changing the background color but not the link color, so it is creating a color contrast issue. The issue doesn't exist on normal links outside the Navbox so must be made here. Jdlrobson (talk) 22:49, 7 February 2024 (UTC)

You can see the issue on Portal:Current_events in "Current events by month". The background color is set on .navbox-title but the links inside this remain the default #3366cc which creates a color contrast issue (you can run Lighthouse in Chrome dev tools to flag this under "Background and foreground colors do not have a sufficient contrast ratio.")

Another approach would be to drop this rule or change the color to something more compatible with link colors:

.navbox-title {
	background-color: #ccf; /* Level 1 color */
}

Let me know if this request is still not clear. Jdlrobson (talk) 22:55, 7 February 2024 (UTC)

The navbox title color is set in Module:Navbox/styles.css. If the title background color is to be changed then it would probably need the other colors in the navbox reviewing as well so that there is still some differences between the different sections of the navbox. There have been discussions in the past about the set of navbox colors (for example at Template talk:Navbox/Archive 19) and while going for paler colours helps the text to be more visible on the backgrounds, it makes it more difficult to distinguish between different areas of background. Could you make your original css rules more specific so that they only applied to navbars within navboxes? -- WOSlinker (talk) 10:59, 8 February 2024 (UTC)

I think either the background color or the links color should be changed. I assumed the links color would make more sense here and is already scoped to navbars.

If we want navbars inside navboxes the following seems appropriate, no?:

.navbox .navbar a { color: #1C376D; }

.navbox .navbar a:visited { color: #423168; } Jdlrobson (talk) 17:57, 16 February 2024 (UTC)

I've moved this discussion (@Jdlrobson@Pppery@WOSlinker) because I'm fairly certain it concerns only navbars in navboxes.

Regarding which, we have a consensus from 2015 about changing the background colors instead to support AAA which never got implemented. With the adjustments in link colors since due to style guideline adjustments and etc., I think it would be more prudent in the meanwhile to adjust the group/title background colors since those are what are being set to at least support AA (though I anticipate some yowling) with the default colors in Vector22. I would appreciate someone throwing some colors at the wall that are in the generally same palette as today. Izno (talk) 02:14, 23 February 2024 (UTC)

Not doneing the request for now since it is not ready to implement. Izno (talk) 02:15, 23 February 2024 (UTC)

(We can also remove Module:Navbox/styles.css#L-17 when we have the colors ready since there are no navboxes directly next to other navboxes these days.) Izno (talk) 02:31, 23 February 2024 (UTC)

Current blocks of colors that need adjustment:

.navbox-title {
	background-color: #ccf; /* Level 1 color */
}

.navbox-abovebelow,
.navbox-group,
.navbox-subgroup .navbox-title {
	background-color: #ddf; /* Level 2 color */
}

.navbox-subgroup .navbox-group,
.navbox-subgroup .navbox-abovebelow {
	background-color: #e6e6ff; /* Level 3 color */
}

Izno (talk) 02:35, 23 February 2024 (UTC)

And the current link colors in Vector 22 are:

• unvisited, hover, focus(visible/within), target: #36c.
• visited: #795cb2
• and for completeness, active (probably not a big issue since it's orange; nb I'd expect focus color to be similar to active): #faa700

Izno (talk) 02:46, 23 February 2024 (UTC)

AA comparison

Navbox	Unvisited (#36c)	Visited (#795cb2)
Level 1 (#ccf)	3.49	3.42
Level 2 (#ddf)	4.05	3.98
Level 3 (#e6e6ff)	4.38	4.3

Not inspiring! :) Izno (talk) 01:04, 24 February 2024 (UTC)

Well, WMF basically made it impossible to keep colors in navboxes without relying on the "if it's bold, it can have a lower contrast" exception that is in the WCAG AA for contrast, using the Vector 22 link colors. We have to go basically to white and various shades of light grey to meet AA 4.5 for normal text (which I wouldn't hate TBF, and I think I recall someone having a go at that before). All of the levels are in bold text though, so perhaps we just decide to ignore it. Izno (talk) 21:52, 25 February 2024 (UTC)

"WMF basically made it impossible to keep colors in navboxes". How so? What would you have done instead?

It seems like you have several options here:

• Use a different link color e.g. black or white (consider underlining the link or adding an icon to make it more obvious it's clickable)
• Move the link out of the box.
• Put the link itself in a box with a white background

Jdlrobson (talk) 21:45, 28 February 2024 (UTC)

How so? You changed the link colors in Vector in phab:T213778. We probably weren't hitting the requirement specifically for the navbar links before anyway because we couldn't claim to be meeting the exception for bold text that WCAG allows (unlike the rest of the links in these locations), but changing the colors in the way that you did made it much harder to thread any needle whatsoever (my options really are light grey and no other colors and even now the darkest grey I've suggested below misses 4.5 by half a point [that was a number picked out of hat]). (Incidentally, there appear to be remaining issues as discussed on that task that WMF appears to have moved on from without any response.)

1. Use a different link color e.g. black or white (consider underlining the link or adding an icon to make it more obvious it's clickable) Adding an icon is not feasible with space requirements. Changing the colors is feasible but fails to meet other expectations of links that also pertain to accessibility (namely, that people know it's a link, which is a far broader issue for users) and makes an inconsistent UI to boot. Adding an underline fails similarly on this second option, has minor readability issues with it, and moreover will get 'unaesthetic' arguments thrown at it (people hate underlines). These links aren't intended to stand out.
2. Move the link out of the box. This is not an option for obvious reasons (stackability of navboxes).
3. Put the link itself in a box with a white background This will get me yelled at harder than just going all the way to grey in navboxes (example of which below). Uniform color is going to be seen as more important.

The primary argument against doing anything here just to make the arbitrary validator happy is also probably that these links... aren't all that important, so we don't lose a lot by failing contrast requirements for them. The pages at which they point have other ways to be accessed, if not so easily (click edit, find the navbox of interest in the transcluded templates, fin, just like every other template). Which is halfway to an argument for total removal, but that's also probably not something I can get consensus for, because 1. they are handy shortcuts, and 2. the balance between navbar links and show/hide links is aesthetically pleasing. (Well, these are the arguments I can foresee, I personally think I could get used to the issues presented by both.)

I do think something should probably be done not least because I don't like relying on the bold exemption in the context of what are smaller text items anyway for the links that are in the rest of the navbox (navboxes are at 88% font size), but I also don't have to like changing it. :) We probably also aren't going to get to 4.5 regardless though I think we can improve the current state, and on that you're probably going to just need to deal with it and find other valid things to complain about. Izno (talk) 22:10, 28 February 2024 (UTC)

Here's something grey. Visited colors against it are 4.0, 4.46, and 4.7. Our "upper bound" is f7f7f7 which is the grey used for the alternating row color. #eee is the darkest we can start if we want to hit 4.5 against visited.

I doubt keeping any colors is remotely possible.

Izno (talk) 22:13, 25 February 2024 (UTC)

Some other choices would be ditching our triple colors by making groups and titles all the same color and subgroups one color off, as well as nixing the alternating row color (which I would guess no-one can tell is missing these days with how monitors are built). Ditching the alternating colors would make the module simpler, but is much less of a win. I suspect implementing a set of these options is best. Izno (talk) 22:16, 25 February 2024 (UTC)

Night mode may need explicit color definitions

For what it's worth, this template appears to be causing any page using a navbox to be tagged by a new linting rule that tries to identify background colors without an explicit text color. {{Bolvadin District}}, for example, shows three instances (I hesitate to call them errors) on its Page Information page; I think the instances are in the V/T/E section of the template. I have been told that using a URL like https://en.wikipedia.org/wiki/Template:Bolvadin_District?vectornightmode=1 is supposed to show what the page looks like in night mode. For me, ironically, the navbox is the only part of the page that looks reasonable, although it displays in regular, not night, mode; almost everything else on the page is a bunch of blue on black or black on black, so I don't know if night mode has reached a development state in which adding explicit colors will show a useful improvement.

I don't know if there is any action needed here, but it might be worth a discussion either here or in a new subsection of the original linked discussion. – Jonesey95 (talk) 05:17, 23 March 2024 (UTC)

Somewhat (highly?) related to the above discussion. Izno (talk) 06:28, 23 March 2024 (UTC)

Until testing can be done, I'm not sure that there is a lot of point making any changes. -- WOSlinker (talk) 09:10, 23 March 2024 (UTC)

Agreed, unfortunately. Murphy's Law says that we'll spend a bunch of time coming up with a fix and when things get implemented it will side-step everything we've already done. It's not nice playing catchup but it's better than duplicating effort. Primefac (talk) 09:32, 23 March 2024 (UTC)

@Izno I think https://en.wikipedia.org/w/index.php?title=Module%3ANavbox&diff=1217155387&oldid=1157419082 will fix this provided we reorder the style e.g. append rather than prefix (args[cfg.arg.basestyle] or '') - what do you think? 🐸 Jdlrobson (talk) 06:39, 4 April 2024 (UTC)

For an example of what this lint rule is flagging: https://en.wikipedia.org/wiki/G%C3%B6lba%C5%9F%C4%B1,_Ad%C4%B1yaman?useskin=minerva&minervanightmode=1

(For clarification - Vector is 2 weeks away from working properly in night mode so only Minerva URLs are good for now) 🐸 Jdlrobson (talk) 06:42, 4 April 2024 (UTC)

@Jdlrobson, coincidentally, I noticed phab:T361785. Izno (talk) 08:17, 4 April 2024 (UTC)

The point of the styles in that section of the code is to override users setting the properties already listed there (bg, border, box shadow, padding). That's why the list comes after the two arguments.

Ignoring that, you appear to be trying to set these links as the color of normal text (light theme: blackish, dark theme: whiteish) with your suggestion. Which you need consensus for per the above discussion for the reasons I laid out there (namely, Changing the colors is feasible but fails to meet other expectations of links that also pertain to accessibility (namely, that people know it's a link, which is a far broader issue for users) and makes an inconsistent UI to boot.). Please do not reinstate anything remotely like that edit until you have it. I am not sure why you made the edit now that I think about the fact I had already said that, and the rest of what I had said above. Izno (talk) 08:03, 4 April 2024 (UTC)

Could we at least override rules into a stylesheet e.g.

.navbar abbr {
background:none transparent;border:none;box-shadow:none;padding:0;
}

(style attribute will override all of these so it will function the same but it won't trigger the lint warning)

This is creating a lot of noise in the Special:LintErrors which is making it difficult for us to QA the other test cases caused by the lint. 🐸 Jdlrobson (talk) 04:10, 5 April 2024 (UTC)