Templates | ||||
|
To help centralise discussions and keep related topics together, Module talk:Navbox redirects here. |
|
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
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.
|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)
|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)
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.state
documentation, with the appropriate redirect shortcut
WP:AUTOCOLLAPSE, to hopefully help with future confusion. 「
ディノ奴
千?!」
☎ Dinoguy1000 01:09, 16 December 2023 (UTC)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)
(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)
<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)
This
edit request to
Module:Navbox/styles.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
.navbox-title {
background-color: #ccf; /* Level 1 color */
}
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:
Izno ( talk) 02:46, 23 February 2024 (UTC)
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)
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.)
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.
Move the link out of the box.This is not an option for obvious reasons (stackability of navboxes).
Put the link itself in a box with a white backgroundThis 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.
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)
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 /info/en/?search=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)
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)
.navbar abbr {
background:none transparent;border:none;box-shadow:none;padding:0;
}
Templates | ||||
|
To help centralise discussions and keep related topics together, Module talk:Navbox redirects here. |
|
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
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.
|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)
|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)
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.state
documentation, with the appropriate redirect shortcut
WP:AUTOCOLLAPSE, to hopefully help with future confusion. 「
ディノ奴
千?!」
☎ Dinoguy1000 01:09, 16 December 2023 (UTC)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)
(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)
<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)
This
edit request to
Module:Navbox/styles.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
.navbox-title {
background-color: #ccf; /* Level 1 color */
}
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:
Izno ( talk) 02:46, 23 February 2024 (UTC)
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)
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.)
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.
Move the link out of the box.This is not an option for obvious reasons (stackability of navboxes).
Put the link itself in a box with a white backgroundThis 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.
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)
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 /info/en/?search=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)
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)
.navbar abbr {
background:none transparent;border:none;box-shadow:none;padding:0;
}