Jump to content

Template talk:Navbox: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Line 575: Line 575:


Also, noticed on {{tl|UK Labour Party}} that there was a LUA error: "Lua error in Module:Navbox at line 279: attempt to index local 'key' (a number value)." -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 11:35, 7 September 2015 (UTC)
Also, noticed on {{tl|UK Labour Party}} that there was a LUA error: "Lua error in Module:Navbox at line 279: attempt to index local 'key' (a number value)." -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 11:35, 7 September 2015 (UTC)
: I believe I've fixed both the error and the actual tracking, and I've undone all the other changes. I'll leave it to somebody else to check before publishing. [[User:Alakzi|Alakzi]] ([[User talk:Alakzi|talk]]) 12:10, 7 September 2015 (UTC)
: {{Ping|Kephir|WOSlinker}} I believe I've fixed both the error and the actual tracking, and I've undone all the other changes. I'll leave it to somebody else to check before publishing. [[User:Alakzi|Alakzi]] ([[User talk:Alakzi|talk]]) 12:13, 7 September 2015 (UTC)

Revision as of 12:13, 7 September 2015

Max number of groups/lists

What is the maximum number of groups or lists in a navbox? Is it finite (limited), or unlimited? GeoffreyT2000 (talk) 01:12, 16 May 2015 (UTC)[reply]

In theory, there is no upper limit. In practice, there is; at some point you will hit one of the template limits such as "Pages where template include size is exceeded" but the exact moment when that happens will vary with both the complexity of the navbox and the complexity of the transcluding page. It's possible that the navbox will display just fine on its template page but will fail on any article that you transclude it to. --Redrose64 (talk) 05:07, 16 May 2015 (UTC)[reply]

Width having opposite effect

I found a bug in Chrome, see {{United States Military Academy superintendents}}. The width: 100%; for the list cell has the opposite effect in Chrome. -- [[User:Edokter]] {{talk}} 17:59, 13 June 2015 (UTC)[reply]

I don't think that it's the list cell, but the image cell - if you zoom out or in, the gaps left and right of that image remain in proportion to the image width, the list then occupying whatever space is left. Using the "Inspect element" feature shows that the image is enclosed in an <a>...</a> element, which itself is enclosed in a <div>...</div> element with no attributes - but that div is apparently 316px × 105px. The problem lies with whatever sets that to 316px instead of 120px, the actual image width. --Redrose64 (talk) 10:50, 14 June 2015 (UTC)[reply]
I found that when I uncheck the width: 100%; in my inspector (set on the <td>), the dimensions normalize, but not when I disable the width: 0%; in the image cell. -- [[User:Edokter]] {{talk}} 11:54, 14 June 2015 (UTC)[reply]
This behaviour sounds either the same or quite similar to Safari (no big surprise, given their common WebKit heritage). To me, the problem really is that the HTML table is being defined as (100%+width of image), i.e. more than 100%, which seems to invite inconsistency between browsers. I'm not certain that the behaviour in that situation is rigorously defined by the standards (a quick bit of reading of W3C CSS 2.1 didn't leave me convinced that there is a singular expected result). It seems to me that if you want predictable behaviour that is similar for most browsers right now (there are new CSS features at the draft stage which provide explicit fitting of width to content, but you probably won't be able to reliably use them for a few years), you need to override the supplied default "width: 100%" and/or "width: 0%". You could try one or both of the following:
  • |liststyle=width: auto;
  • |imagestyle=width: 120px; (add padding-left and padding-right to taste)
I also observed that adding |list2=some content seemed to change the behaviour to give a minimum width image cell (that's why you can't see this behaviour on the testcases subpage). It's possible that this is really more of a doc bug, and the fix would be just to strongly suggest setting the width (and any desired padding) for the image cell in the docs. I've not done any multi-browser testing of those ideas, just some experimentation out of passing curiosity, having been doing a bit of work with Navbox on another wiki.
--Murph9000 (talk) 09:02, 20 June 2015 (UTC)[reply]

Unlinked content in navboxes

I think there should be a consensus gathered on whether navboxes should allow unlinked information inside a navbox – for example: Template:Jebediah.

I personally think it should not be allowed, and that the whole purpose of a navbox in the first place is to navigate between existing articles, not to fully document, in this case, an artist's discography (that is what a Discography section or article is for). Lachlan Foley (talk) 04:48, 13 July 2015 (UTC)[reply]

WP:NAV, an explanatory essay for WP:NAVBOX, already comments on this. --Izno (talk) 13:41, 13 July 2015 (UTC)[reply]
@Lachlan Foley: It's already under discussion at Wikipedia talk:Categories, lists, and navigation templates#Reference links within Navbox templates, and at least one other place. Please see WP:MULTI and don't start more discussions. --Redrose64 (talk) 18:50, 13 July 2015 (UTC)[reply]
Different discussion Redrose. One is on external links and the one Foley is on about is unlinked items. As I suggested, in this particular case WP:NAV contains the relevant essay/guidance he is looking for. --Izno (talk) 19:05, 13 July 2015 (UTC)[reply]
I did mention "at least one other place"; that ongoing discussion (which I can't find) arose after some recent TfDs for navboxes that had few blue links. It was decided that rather than debate each navbox individually, there would be a general discussion to set a guideline. --Redrose64 (talk) 21:30, 13 July 2015 (UTC)[reply]
I think that discussion might be the one about red links as at WT:Red link? I haven't seen anything on VPR, MOS, MOSTABLE, VPP, CENT... --Izno (talk) 21:51, 13 July 2015 (UTC)[reply]
That's the one. @Lachlan Foley: this discussion is Wikipedia talk:Red link#Proposal regarding redlinks in navigation templates, and it included a proposal about non-linked text (i.e. "black links") as a compromise, which did not receive sufficient support. I think that covers your proposal here, but I see that it's not ongoing, since it closed six days ago - discussing the matter again so soon after closure would not be productive. --Redrose64 (talk) 06:51, 14 July 2015 (UTC)[reply]

Has the image parameter been broken?

It definitely doesn't work as indicated in the documentation, or any other way I can find. Adam Cuerden (talk) 21:07, 19 July 2015 (UTC)[reply]

Could you be more specific, perhaps with an example of what is broken? -- [[User:Edokter]] {{talk}} 21:59, 19 July 2015 (UTC)[reply]
Let's do a simple one: Template:Aida is set up per instructions to have an image. I've tried several variants as well. I'd ideally lijke to do a {{CSS image crop}} but I'll take minimally functional over completely non-functional. Adam Cuerden (talk) 22:04, 19 July 2015 (UTC)[reply]
For images to work |list1= has to be non-empty. -- WOSlinker (talk) 22:24, 19 July 2015 (UTC)[reply]
Right. That should probably be mentioned. There seems to be the occasional tendency towards grabbing pre-made formats and leaving lines unneeded blank. Adam Cuerden (talk) 01:36, 20 July 2015 (UTC)[reply]

rewrite in the name of performance?

Some navboxes e.g. Barack Obama account for over 40% of the markup required to render an article. The table based layout also doesn't work on mobile.

I wonder if using JavaScript and JSON stored blobs/wikidata we could reduce the HTML for these templates and make the experience more interactive. Worth exploring? Cc @thedj @gwicke Jdlrobson (talk) 02:26, 28 July 2015 (UTC) Jdlrobson (talk) 02:26, 28 July 2015 (UTC)[reply]

Mobiles don't have a problem with tables per se. The reason that they don't display navboxes is because the CSS file for mobiles has a rule that sets display:none; for one of the classes that is associated with every navbox. --Redrose64 (talk) 08:07, 28 July 2015 (UTC)[reply]
The rationale for which is because displaying these templates on mobile doesn't make sense i.e. it doesn't work. Same result. :^) --Izno (talk) 12:59, 28 July 2015 (UTC)[reply]
Exactly.. for the same result, try minimising the window of Vector to 320px and you'll see the problem we have here. Really this would need to be rethought from a mobile first perspective. Something like http://wiki.polyfra.me/ for instance would be a really innovative way to navigate between related articles if we provided structure data to allow this. Jdlrobson (talk) 17:37, 10 August 2015 (UTC)[reply]

Accessibility

The default colours of this template, with #332BCD ( ; links) against #CCCCFF ( ) or #DDDDFF ( ) backgrounds, is of insufficient contrast to meet WP:COLOUR, as explained at WP:Colour contrast. Paler backgrounds such as #ECECFF ( ) or #ECECF2 ( ), would be OK. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 30 July 2015 (UTC)[reply]

I don't know where you get the #332BCD, but our default link color is ##0645AD, which on #CCCCFF is AA compliant. -- [[User:Edokter]] {{talk}} 16:37, 30 July 2015 (UTC)[reply]
But not AAA compliant (I sampled using "Colour Contrast Analyser version 2.2a"; perhaps I caught shading). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:24, 30 July 2015 (UTC)[reply]
Only the color. Contrast-wise, it is OK. We are comitted to accessability, but that doesn't mean everything should be AAA. -- [[User:Edokter]] {{talk}} 17:52, 30 July 2015 (UTC)[reply]
@Edokter: Everything should be AAA when feasible. This seems feasible to fix. EvergreenFir (talk) Please {{re}} 19:08, 30 July 2015 (UTC)[reply]
I'm all for accessability, but this is just chasing complience, not an actual improvement. If everything on WP must be AAA, we'd probably have to change everything. -- [[User:Edokter]] {{talk}} 19:22, 30 July 2015 (UTC)[reply]
No. By definition, moving from AA to AAA is an improvement. There is always a spectrum of disability with visual impairment, and a proportion of readers will be unable to cope with AA (or find it difficult) but will be able read AAA. WCAG differentiates between AA and AAA by stating "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content."[1] So we ask editors to meet AA standards and AAA where possible. It is perfectly possible to make the foreground and background colours in a template meet AAA standards - and therefore we ought to require that. The relaxation to AA is only for situations where meeting AAA standards is not possible, and this isn't one of them. --RexxS (talk) 02:41, 31 July 2015 (UTC)[reply]
We won't have to change "everything", because we already mangae to have a lot of things that are already AAA compliant - it's not hard to do. But this is not about changing much, just one small, though widely-used, template. You do not seem to advance any argument that it is infeasible to make this template AAA compliant, so I suggest that we do so ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:26, 31 July 2015 (UTC)[reply]
It is still a color change on a universally used template. If the link color is not AAA here, it isn't AAA on any other template that uses a blue(ish) background color. So it stands to reason to change the link color instead. -- [[User:Edokter]] {{talk}} 17:26, 31 July 2015 (UTC)[reply]
Does anyone have any preferred AAA-complaint colours, or shall I just pick some? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:26, 31 July 2015 (UTC)[reply]
The darkest blue that gets AAA-compliance with #0645AD is #E7E7FF   -- WOSlinker (talk) 07:18, 31 July 2015 (UTC)[reply]
I'm not sure I have an opinion on changing these colors yet, but we should consider the best color against a:visited, not a. Which the Firefox inspector declined to provide me that color when I clicked on some links. --Izno (talk) 13:28, 31 July 2015 (UTC)[reply]
Why? The visited link colour is darker. Alakzi (talk) 13:31, 31 July 2015 (UTC)[reply]
I'm probably not sure what I'm talking about in discussion of contrast then. Time for some research I suppose. --Izno (talk) 13:47, 31 July 2015 (UTC)[reply]
my stylesheet was using e6e6ff, eeeeff, and efefff, but e7e7ff, eeeeff, and efefff would work as well [2]. Frietjes (talk) 13:39, 31 July 2015 (UTC)[reply]
@Pigsonthewing and Alakzi: Changes to link colors would need to be discussed someone with a larger audience... but I've noticed that   is almost never AAA compliant on any non-white background. I think either we need to discuss (1) changing the link color or (2) allowing AA compliance against   and AAA compliance against   EvergreenFir (talk) Please {{re}} 17:50, 31 July 2015 (UTC)[reply]
WP:COLOUR requires AAA "where feasible". It is clearly feasible to change the background in this template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:27, 1 August 2015 (UTC)[reply]
Then we will only be able to use pastel colors. EvergreenFir (talk) Please {{re}} 16:48, 1 August 2015 (UTC)[reply]
That's a problem because..? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:55, 1 August 2015 (UTC)[reply]
It severely limits options? I'd rather see the link color change. EvergreenFir (talk) Please {{re}} 18:01, 1 August 2015 (UTC)[reply]

To demonstrate the problem with AAA contrast against the unvisited link color, here's a table of the darkest AAA colors possible:

colour table
WCAG AAA compatible colours against black, unvisited links (#0645AD), and visited links (#0B0080)
base colour name base colour base colour in hex base colour hue darkest AAA colour text (black) darkest AAA color unvisited links (#0645AD) darkest AAA color visited links (#0B0080)
red #FF0000 0°
#FF7B7B
#FFE2E2
#FF8A8A
orange #FF8000 30°
#FFA74F
#FFE4C8
#FF9021
yellow #FFFF00 60°
#FAFA00
#F0F000
#B2B200
chartreuse #80FF00 90°
#A8FF4F
#AAFF53
#62C300
green #00FF00 120°
#7BFF7B
#99FF99
#00C800
spring green #00FF80 150°
#4FFFA8
#87FFC3
#00C663
cyan #00FFFF 180°
#00FAFA
#53FFFF
#00C0C0
dodger blue #0080FF 210°
#4FA8FF
#D6EBFF
#62B1FF
blue #0000FF 240°
#8888FF
#E6E6FF
#A3A3FF
electric indigo #8000FF 270°
#BB76FF
#F1E3FF
#CA95FF
magenta #FF00FF 300°
#FF28FF
#FFDEFF
#FE76FE
deep pink #FF0080 330°
#FF52A9
#FFE0F0
#FF83C1
grey #808080 -
#A7A7A7
#E8E8E8
#ACACAC

First 5 columns and table syntax taken from User:RexxS/AAAcolour. EvergreenFir (talk) Please {{re}} 18:17, 31 July 2015 (UTC)[reply]

Contrast ratios

{{#invoke:Color contrast|styleratio|css style statement string|default background color|default text color}} should now work (ymmv), which means one could introduce tracking for finding particular bad combinations in |titlestyle=, |basestyle=, |groupstyle=, ... it won't parse <span>...</span> and <font>...</font> strings within the |title=, |groupX=, ... but that could be done as well with some string processing within this module. Frietjes (talk) 16:05, 1 August 2015 (UTC)[reply]

Not knowing about this debate, I implemented this in the sandbox. It only checks styles against the AA standard. Can at least this be integrated into the main version? —Keφr 12:15, 6 September 2015 (UTC)[reply]

Done Alakzi (talk) 11:06, 7 September 2015 (UTC)[reply]
Had to revert. See Template_talk:Navbox#Change_reverted. -- WOSlinker (talk) 11:39, 7 September 2015 (UTC)[reply]

Tracking category

Pinging @Pigsonthewing, Alakzi, and Mr. Stradivarius: - Can we get a tracking category for this template at all? I imagine it would compare the basestyle and the groupstyle to the #0645AD. (Please ping in reply) EvergreenFir (talk) Please {{re}} 04:15, 14 August 2015 (UTC)[reply]

see the last example in Module:Color_contrast. Frietjes (talk) 22:07, 14 August 2015 (UTC)[reply]

Redux

We still need to agree a solution to this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:17, 25 August 2015 (UTC)[reply]

I've brightened the colours below as a demonstration. Would this be a good starting point? Alakzi (talk) 13:54, 26 August 2015 (UTC)[reply]

I like your new (the second) design. I propose that we adopt it. If others have alternative, equally accessible solutions, then I suggest that we adopt your styling as an accessible interim solution while we discuss them and reach a consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 26 August 2015 (UTC)[reply]

@Alakzi: I see the code is in a module, What actually needs to be changed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:28, 26 August 2015 (UTC)[reply]
The changes need to be made to the navbox classes in MediaWiki:Common.css. Alakzi (talk) 20:30, 26 August 2015 (UTC)[reply]
I find them way too pale. Requiring AAA is severly limiting use of color. I think AAA should be reserved for running text, not interface and navigation elements, which are better suited with AA. -- [[User:Edokter]] {{talk}} 21:08, 26 August 2015 (UTC)[reply]
"Sorry folks, your visual disability means you are not suited to use our interface and navigation elements" is hardly compatible with WMF policy. But you're welcome to propose rewriting WP:COLOUR, which specifically refers to colour-contrast within templates and tables, if you think there will be consensus to do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:18, 26 August 2015 (UTC)[reply]
No need to be so dramatic. Note that AAA is warranted where possible. And while that is a broad term, it comes down to common sense. The fact remains that AAA basically allow only black and white. The general public should not suffer from the measures imposed to accomodate the few. That is why there are several levels of accessability; AA is perfectly suitable for navigation, while AAA is targeted at content. -- [[User:Edokter]] {{talk}} 16:34, 28 August 2015 (UTC)[reply]
My invitation stands. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:21, 28 August 2015 (UTC)[reply]
Edokter, that can't be right - how are you going to find the content you want to read if you can't use the navigational elements? Opabinia regalis (talk) 20:25, 28 August 2015 (UTC)[reply]
It's not "can't"; it's just a little harder to see perhaps. Don't make it sound as if anything non-AAA is absoletely unreadable. -- [[User:Edokter]] {{talk}} 20:48, 28 August 2015 (UTC)[reply]

Let's not make this any harder than it has to be: we need a neutral color scheme for the default design of Template:Navbox. Why not simply use the same background and link colors as those used for the standard Wikipedia frameset: pale blue screen with dark blue links and black text. Given that it is ubiquitous on every page of Wikipedia, I assume it is AAA-color-contrast compliant. It would also have the obvious advantage of appearing to be part of a common Wikipedia layout and design. Dirtlawyer1 (talk) 20:35, 27 August 2015 (UTC)[reply]

Which is the frameset? Alakzi (talk) 21:07, 27 August 2015 (UTC)[reply]
A: What I'm calling the "frameset" is everything to the left and atop the Wikipedia pages that may be edited. To the left there are the menus, upper left there is Wikipedia globe logo, and on top there are the Template, Talk, Read, Edit, View history, and More tabs. It appears to be a 10 to 20 percent blue screen, with royal blue links, black text, and two shades of blue tool lines. I believe this is the default frameset, but you can choose other preferences on your preferences page. Dirtlawyer1 (talk) 01:25, 28 August 2015 (UTC)[reply]
@Alakzi and Edokter: And strangely, the frameset color scheme appears to be very close to Alakzi's second option above. Coincidence? I doubt it. I suspect the WMF website design guys have already been through this exercise. Isn't there a "reveal codes" function for web pages whereby you can examine the underlying HTML coding and hex colors? I find it difficult to understand how Edokter or anyone else could object to a default design that uses the same colors as our basic Wikipedia frameset. It is, after all, a default design which we all know can be changed in any particular instance to any set of colors that are AAA-contrast compliant. Dirtlawyer1 (talk) 17:24, 28 August 2015 (UTC)[reply]
You could use the inspector in your browser (right click and "Inspect Element" in Firefox, Chrome and Safari). Alakzi (talk) 17:34, 28 August 2015 (UTC)[reply]
@Dirtlawyer1: Or you could look at the HTML for the whole page at once, virtually all browsers provide a "View page source" function (or similar), usually through right-click but it might be in the menu bar. Ctrl+U works in several. But please don't use the term "frameset" for something that isn't. --Redrose64 (talk) 18:01, 28 August 2015 (UTC)[reply]
@Redrose64: Yes, sir, Ctrl-U does reveal the page's underlying HTML coding in Mozilla Firefox, which I use as my primary browser. For my own education, if the pale blue rectangular spaces that contain our menu list to the left and various article-related tabs on top of a Wikipedia webpage are not part of the "frameset," then what is the correct terminology? Dirtlawyer1 (talk) 18:26, 28 August 2015 (UTC)[reply]
Ctrl-U would be useless since the stylesheets are external to the document. Alakzi (talk) 18:30, 28 August 2015 (UTC)[reply]
In Firefox, the page source obtained through Ctrl+U has clickable links to external pages, including the stylesheets; these are mostly the <link rel="stylesheet" href="..." /> elements. There are the top navigation menu, the tabs, the left navigation menu, and the footer. --Redrose64 (talk) 18:54, 28 August 2015 (UTC)[reply]
the proposed replacement colours looks good to me, and close to what I have in my common.css. Frietjes (talk) 21:15, 28 August 2015 (UTC)[reply]

Consensus?

It looks like we've got a consensus for the new colour scheme. Who will do the honours? Alakzi (talk) 22:15, 28 August 2015 (UTC)[reply]

I see like, 5 people. For changing the default of a template used on over a million articles, you're going to need a few more people to comment. An {{RFC}}'s worth. --Izno (talk) 00:26, 29 August 2015 (UTC)[reply]
We could do without the trolling in your edit summaries, TYVM. Brightening the colours slightly to satisfy WP:COLOUR is uncontroversial; inviting the input of the uninformed masses is one stupid idea. Alakzi (talk) 00:43, 29 August 2015 (UTC)[reply]
Why don't you get the uninformed mass's opinion on this one before deeming it "uncontroversial"? You must not watch any of the village pumps, else I think you'd probably know how "uncontroversial" changing anything affecting the website at-large can be. --Izno (talk) 01:52, 29 August 2015 (UTC)[reply]
There is no consensus here, and such a change would certainly generate a lot of controversy. Like it or not, the world wide web is a visual medium, and requiring AAA on everything is not feasable, which happens to be the condition set by WP:COLOUR for AAA. Put this to an RfC if you must, but I'm not going to change any colors based only on the discussion above. -- [[User:Edokter]] {{talk}} 08:03, 29 August 2015 (UTC)[reply]
Those paler colours are very monitor dependant. I've got two different monitors and on one, the AAA colours look ok and on the other the colours look very washed out. I would prefer having the AAA colours as an optional gadget. -- WOSlinker (talk) 08:42, 29 August 2015 (UTC)[reply]
Your misconfigured monitors are not our problem. HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:29, 29 August 2015 (UTC)[reply]
Well, if the gatekeeper said no, I think I'm done with this talk page. Alakzi (talk) 08:50, 29 August 2015 (UTC)[reply]
And if anybody's interested, take a look at MediaWiki talk:Common.css, where he flatly refuses to implement several changes there's consensus for because he knows better. Alakzi (talk) 08:58, 29 August 2015 (UTC)[reply]
How is it my fault that no other admin is bothered by sitewide CSS? Maybe because they think it is in good hands... -- [[User:Edokter]] {{talk}} 09:38, 29 August 2015 (UTC)[reply]
Alakzi: attitudes like that have already caused Plastikspork and Gadget850 to quit - is it your intent that Edokter be similarly driven away? It certainly isn't mine. --Redrose64 (talk) 12:56, 30 August 2015 (UTC)[reply]
What a pathetic attempt to turn this around on me; and what a pity you've only got any sympathy for administrators. Alakzi (talk) 13:25, 30 August 2015 (UTC)[reply]
Right, you clearly want me gone too. Unwatching. --Redrose64 (talk) 13:39, 30 August 2015 (UTC)[reply]
@Redrose64: Be careful what situations you cite; Plastikspork had clearly been in decline for a long time, and reacted very badly when another administrator reasonably questioned a poorly reasoned TfD close, and then quit in a huff. No one, no single administrator, should be perpetually responsible for bearing the burden of work in any particular area. It inevitably leads to a perspective of exaggerated indispensability and burnout. I for one respect the work Edokter does elsewhere, but I have also seen signs of self-perceived "indispensability." That said, I think everyone should dial it back a notch or two rhetorically. Alakzi and others are correct when they say AAA-color-contrast compliance is strongly preferred and achievable in this instance; Edokter also has a point, in that we should not rely on "consensus" of four or five participants in 24 hours for a change that impacts thousands of templates, and hundreds of thousands of articles and template transclusions. We can certainly solicit more input, more widely, and wait a few a days for that input. I for one would also like to hear from Edokter why we should not use a default color scheme for navboxes that is identical or very close to the color scheme for our default Wikipedia menus and tabs that appear on every Wikipedia page -- as previously noted by me above -- and which is very, very close to the color scheme proposed by Alakzi above. The logic of it is undeniably strong. So, how about it, Edokter? Dirtlawyer1 (talk) 13:38, 30 August 2015 (UTC)[reply]
Dirtlawyer1 I am not easily pushed away. I also don't feel 'indispensible'; I just like taking care of technical stuff. That said, I continue to oppose this change, because the only reason for seem to be the unconditional complience to AAA. If you looked at the color table above, that basically means we can only use colors that are nearly white against nearly black. That is too severe a constraint in our use of colors. That is why it says "when feasable". I know it's vague, but it does apply here, in that it is not feasable. I don't know how these AAA standards came to be, but they are touted as a fix-for-all, which I do not believe. Just look in your Windows color schemes and try the high-contrast settings, which any sight-impaired user has no doubt already enabled. Also, color use is not the only factor in legibility and accessability as the WCAG suggests. One should olso properly interpret the WCAG's recomendations, and what the ratings actually means:
  • Priority 1: Web developers must satisfy these requirements, otherwise it will be impossible for one or more groups to access the Web content. Conformance to this level is described as A.
  • Priority 2: Web developers should satisfy these requirements, otherwise some groups will find it difficult to access the Web content. Conformance to this level is described as AA or Double-A.
  • Priority 3: Web developers may satisfy these requirements, in order to make it easier for some groups to access the Web content. Conformance to this level is described as AAA or Triple-A
So you see that AAA is not a "requirement", just a step further to make it a little easiers for the impaired. That is what our accessability guidelines are based on: that we "at least" provide AA, and use AAA "where feasable". That is maybe even more strict then the actual WCAG guideline. So yes, I continue to oppose this change, which is proposed only for the sake of the change, and not on any argument that is actually backed by the WCAG recomendations. -- [[User:Edokter]] {{talk}} 14:59, 30 August 2015 (UTC)[reply]
@Edokter: I've read it and I understand it, as well or better than some of the folks who are trying to enforce it. That said, you're missing the point: this is the default color scheme. Because I frequently work with sports articles, I am well aware of the panoply of ways to use multiple team colors and still obtain AAA compliance. The most problematic elements are the royal blue links -- they usually work best on white backgrounds, but the overwhelming msjority of our navboxes already use white backgrounds for the interior navbox space where the links are located. The pale blue percentage screens for the interior navbox background space are arguably redundant anyway. This is not about whether other non-default color schemes for navbox exeriors and graphics may be used; they are, and they can comply. Dirtlawyer1 (talk) 16:00, 30 August 2015 (UTC)[reply]
The "Priorities" quoted by Edokter are from WCAG 1.0; which was superseded by WCAG 2.0, over six years ago. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:16, 30 August 2015 (UTC)[reply]
While I agree there's a need for more input on the matter, AAA is both perfectly feasible and a good idea for key navigational elements on such a large number of pages. Accessibility broadly construed is a core goal of the project and shouldn't be intentionally compromised on subjective aesthetic grounds without broader input. Incidentally, accessibility is a live issue in open-access academic publishing, where Wikipedia is increasingly seen as an important downstream user of OA-licensed content; while nobody there to my knowledge is checking out our navbox colors yet, it'd be a lot harder to argue for attention to the topic if we won't eat our own dogfood. Opabinia regalis (talk) 09:16, 29 August 2015 (UTC)[reply]
You're wasting your time; logic doesn't work on these people. Alakzi (talk) 09:24, 29 August 2015 (UTC)[reply]
If someone needs AAA compliance to be able to read the text on a website then they are probably going to have some browser plugin or other software already installed on their machine to adjust the colours anyway otherwise they wouldn't be able to read things on many websites. There are not that many websites which are fully AAA compliant. -- WOSlinker (talk) 11:46, 29 August 2015 (UTC)[reply]
Well, sure; we're not claiming to aim for full compliance - that's why WP:COLOR says "when feasible" and not "always". The fact that we're having this discussion makes clear that it is feasible to use AAA colors in navboxes. It's probably true that people will object, but being realistic, most of the objections will look like these ;) Opabinia regalis (talk) 21:43, 29 August 2015 (UTC)[reply]
That said, Opabinia, these templates have existed in their present form for years (more than my six years on-wiki); we can and probably should get more input, and there is no harm in waiting a few more days for others to chime in. There is no emergency here, and no one likes to get the bum's rush. And this is coming from someone who supports the change -- ultimately, AAA contrast compliance needs to be supported by the community as a whole, not a handful of technicians, which means these discussions need to educate editors who are not familiar with WP:ACCESSIBILITY issues such as color contrast. This is ultimately not just a technical problem, but an education/informational challenge, and the proponents need to accept that gentle education is part of the job description if they are going to work in this area. Dirtlawyer1 (talk) 13:38, 30 August 2015 (UTC)[reply]

I have started RfC below per the concerns about wider input expressed above. EvergreenFir (talk) Please {{re}} 17:56, 30 August 2015 (UTC)[reply]

RfC: Should the default colors for this template be changed to satisfy AAA level accessibility color contrasts WP:COLOR? If so, to which colors?

There has been an extended discussion regarding the default colors for {{Navbox}}. The crux of the issue whether or not the colors should be changed to satisfy AAA level color contrasts per WP:COLOR. Specifically, ensuring that the contrast ratio between the unvisited links font color ( ) and the background color is greater than or equal to 7:1. This RfC is being created as some expressed a desire for wider community input before implementing any changes to such a widely-used template.

The reason for meeting certain levels of contrast is to ensure accessibility for color-blind, low-vision, and vision-impaired users and readers. WP:COLOR says that, "Ensure the contrast of the text with its background reaches at least WCAG 2.0's AA level, and AAA level when feasible." AA level is contrast greater than or equal to 4.5:1 which "compensate[s] for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision" and AAA level is contrast greater than or equal to 7:1 which "compensate[s] for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/80 vision" ([3]).

Below are the current template colors and the colors proposed above. Other proposal are welcome and people responding to this RfC should feel free to offer alternatives. Current colors:

Proposed colors:

Thank you. EvergreenFir (talk) Please {{re}} 17:52, 30 August 2015 (UTC)[reply]

RfC opinions

  • Support changing to proposed colors - This is a reasonably minor change in colors to a template to satisfy WP:COLOR. The change is more than "feasible". I personally see no reason for contention here. EvergreenFir (talk) Please {{re}} 17:58, 30 August 2015 (UTC)[reply]
  • Support AAA-color-contrast compliance between (a) linked text and background colors, and (b) unlinked text and background colors for our default color scheme for Template:Navbox. Now let's argue about what that color scheme should be -- personally, I support a color scheme identical to that of the so-called "Vector" default skin for out left-side menu links and our top-sided tabs shown on every Wikipedia page. I note that this is very close what User:Alazki has proposed above. Dirtlawyer1 (talk) 18:04, 30 August 2015 (UTC)[reply]
  • Support - and remember, WMF policy says we must not discriminate against people on the basis of their disability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:06, 30 August 2015 (UTC)[reply]
  • Support; this change clearly falls into the category of "feasible", and I see no reason to make the default style of such a widely used template an exception to WP:COLOR. This benefits those who need it, and harms nothing in the process. (And - not that it matters, but - I find the revised version more visually appealing.) Opabinia regalis (talk) 18:26, 30 August 2015 (UTC)[reply]
  • Opposed, White isn't a color. Now get off your Macs and go out into the real world. — Dispenser 18:53, 30 August 2015 (UTC)[reply]
  • Oppose as the proposal stands. The paler colours make it difficult for me to differentiate between the different areas of the navbox. The white cell borders no longer contrast with the cell colours. If there is a need for the paler cell colours for some readers to be able to see the text then fine but the white cell border needs making into a darker colour so that the different areas of the navbox can still be indentified. -- WOSlinker (talk) 20:18, 30 August 2015 (UTC)[reply]
  • Oppose - The use of colors is severly limited if AAA becomes required, almost to black and white. As WOSlinker said, that also makes it impossible to use levels of color, besically because there is only one possible level left: almost-but-not-quite-white. There are alternatives, like changing the link color instead. -- [[User:Edokter]] {{talk}} 20:22, 30 August 2015 (UTC)[reply]
    Surely it would be much more complicated to change the link color for the entire site. It wouldn't make sense to use different link colors in navboxes vs. elsewhere. AAA certainly isn't limited to white; I don't claim the current colors defined by {{Taxobox colour}} are beautiful, but they are compliant and not white. Dirtlawyer pointed this out above, but there's nothing about this change that precludes custom navbox colors for specific uses.
    Using larger, bolded text in the navbox title bar is an option, though maybe a more startling change for editors. Opabinia regalis (talk) 20:58, 30 August 2015 (UTC)[reply]
    To illustrate this, I believe the centre box below is AAA-compliant due to the large, bold text in the title:

 

-- Dr Greg  talk  21:24, 30 August 2015 (UTC)[reply]
@Dr Greg: The "VTE" and "hide" would not be compliant even if the title is bold. EvergreenFir (talk) Please {{re}} 00:42, 31 August 2015 (UTC)[reply]
An implementation in which the contents are accessible, even if the interface elements that interact with the interface itself are not, is still an improvement over the status quo, though. Opabinia regalis (talk) 04:07, 31 August 2015 (UTC)[reply]
14 points is 120% the base font size. This is what WCAG defines as "large text": Title link or Title link. The font size of the navbox is 88% of the content text, which is 87.5% of the base font size; therefore, 120% in the title of the navbox equals 92.4% of the base font size. Alakzi (talk) 09:48, 31 August 2015 (UTC)[reply]
OK, the large font idea turns out to be unfeasible, so here's another idea: render the text within the title bar (but not the bar itself) with the "abovestyle" background. It would look like this (imagine the "hide" is rendered the same way; I can't change that).

 

-- Dr Greg  talk  12:24, 31 August 2015 (UTC)[reply]
What other websites do does not negate the guidelines in WP:COLOR. We set our own standards, now let's implement them. EvergreenFir (talk) Please {{re}} 17:12, 31 August 2015 (UTC)[reply]
We have; "...at least AA" has been met. -- [[User:Edokter]] {{talk}} 17:30, 31 August 2015 (UTC)[reply]
  • Oppose - The proposed box just looks all grey(ish) to me, The seperation between title & content doesn't seem obvious compared to the current box, I'm all for making WP easily readable but not when it makes life harder for everyone else. –Davey2010Talk 18:33, 31 August 2015 (UTC)[reply]
  • Oppose per Davey2010 and others. There needs to be sufficient contrast between title, heading, and content backgrounds. Alternative colours proposed by Dr Greg look feasible for improving text/link-on-background contrast without making the backgrounds too hard to distinguish - Evad37 [talk] 05:16, 1 September 2015 (UTC)[reply]
  • support any new scheme which improves the contrast. I am currently overriding the defaults with my personal common.css, and would be nice to not need to override the default to make things easier to read. Frietjes (talk) 15:09, 1 September 2015 (UTC)[reply]
  • Oppose – While accessibility is important, it alone should not dictate and override other factors that contribute to the overall usefulness of our encyclopedia. This proposal simply removes color saturation. Black and white is not answer. Why? Because it fails to take in the needs of the vast majority of our readers whole do expect a visually appealing experience. The Web is exploding with color! Good design techniques allow for both aims to be met. By adopting this proposal, we take the easy way out. The Wikimedia Foundation has cash giveaway programs for anyone who asks. So let's ask them to hire some real web designers to give a us better solution than the one we see considering. Senator2029 “Talk” 10:33, 2 September 2015 (UTC)[reply]
  • Support - The proposed template looks more readable and whiter. --Stranger195 (talk • contribs • guestbook) 13:09, 2 September 2015 (UTC)[reply]
  • Oppose for insufficient contrast. Users with severe difficulties have the option to use custom style sheets. Accessibility does not mean making more difficult for normal readers. Stifle (talk) 06:44, 3 September 2015 (UTC)[reply]

RfC discussion

Just a note after reading past discussion, status quo is not a sufficient reason to reject these changes. Because because something has been this way for a long while does not mean it cannot be improved. Moreover, this improvement is more than feasible to implement per WP:COLOR's guidelines. EvergreenFir (talk) Please {{re}} 17:55, 30 August 2015 (UTC)[reply]

Actually, the threshold for this change is that consensus is required. Without it, no change can take place. Status quo does not equal consensus, so... well you can do the math. -- [[User:Edokter]] {{talk}} 20:28, 30 August 2015 (UTC)[reply]
I have placed a neutral notice regarding this RfC on WP:VP/T. It can be found here. EvergreenFir (talk) Please {{re}} 18:02, 30 August 2015 (UTC)[reply]
BTW, for AAA, best to economise on the green ink. Thincat (talk) 21:23, 30 August 2015 (UTC)[reply]
  • Comment: Per WOSlinker's oppose, would it also be worthwhile to add some borders inside the navbox? Is anyone willing to make an example navbox with (fairly thin, but still noticeable) black borders around each line? — Bilorv(talk)(c)(e) 01:12, 31 August 2015 (UTC)[reply]
  • Comment The proposed version may add to the readability of the text, but it decreases, at least for me, the perceived distinction between the headings. That's an accessibility isssue, though I do not know if its one of the formal criteria. The alternate proposal seems to do much better in this respect. DGG ( talk ) 04:28, 31 August 2015 (UTC)[reply]
@DGG: Bilorv's idea of borders would be one option. Other color combos would be another. Any suggestions? EvergreenFir (talk) Please {{re}} 17:13, 31 August 2015 (UTC)[reply]

Ugly rendering on w:mr

Rendering as seen on a derived template

Hello,

Navbox template is rendering in a rather un-pretty manner as shown in the screenshot below. We have tried several things but no dice. Can someone please take a look and see what we may be missing?

Thank you for your help.

अभय नातू (talk) 16:46, 2 August 2015 (UTC)[reply]

Your wiki seems to be missing the hlist classes for horizontal lists which is used by {{navbar}}. -- [[User:Edokter]] {{talk}} 16:56, 2 August 2015 (UTC)[reply]
@Edokter: That's a redlink (or it would be, if cross-wiki links weren't always blue) --Redrose64 (talk) 19:06, 2 August 2015 (UTC)[reply]
It should be mw:Snippets/Horizontal lists. Alakzi (talk) 19:10, 2 August 2015 (UTC)[reply]

Thank you very much for the quick responses. Made the suggested changes at mw:Snippets/Horizontal lists but no luck yet. I'll try to gather more details/symptoms before asking for more help. I did want to acknowledge your prompt turnaround!

अभय नातू (talk) 00:57, 3 August 2015 (UTC)[reply]

p.s. I should clarify that the rendering is better now (horizontal list instead of vertical) but is on a separate line, not on the same as title line. Probably need more css tweaks. Do let me know if there're classes/scripts I should inspect/tweak first. — Preceding unsigned comment added by अभय नातू (talk • contribs) 01:00, 3 August 2015 (UTC)[reply]

It seems as though the Navbox has been broken somehow on certain categories of pages. From the template page for the Navbox, the good example - University of Michigan page no longer displays the Navbox appearing even though the correct tags are still in the pages' code. This seems to an issue with places and colleges. Can someone help with this?Blanksamurai (talk) 13:10, 7 August 2015 (UTC)[reply]

I took a look and didn't see a problem. --Izno (talk) 13:20, 7 August 2015 (UTC)[reply]

Hi Izno, I apologize it's an error related to use of Internet Explorer 9 (probably unsupported now). Thanks for following up. Blanksamurai (talk) 17:30, 7 August 2015 (UTC)[reply]

Autocollapse default

This has been a long time coming. The suggested default for |state= has been | state = {{{state|}}} in the doc for some time now. But when navboxes use that extra pipe, the default autocollapse doesn't actually kick in (solitary navboxes do not auto-expand). The trick is removing that extra pipe. The param still allows state changes to be specified when calling the template, but it actually does autocollapse on its own. I've corrected the documentation to reflect this. – czar 21:57, 7 August 2015 (UTC)[reply]

@Czar: This is a hack. It's not working for you because of {{Video game reviews}}; if there's more than one collapsible element on any page, they all are automatically collapsed. Due to the way Module:Navbox is programmed to handle |state=, literally "{{{state}}}" replaces the collapsed class; essentially, this is no different than defaulting to expanded. Alakzi (talk) 22:11, 7 August 2015 (UTC)[reply]
Thanks—I didn't know vg reviews was the culprit. What a pain in the ass – czar 22:15, 7 August 2015 (UTC)[reply]
@Alakzi, does {{infobox vg}} also count as a collapsible element, or just vg reviews? – czar 22:20, 7 August 2015 (UTC)[reply]
It does iff "collapsible" is set to "yes". Alakzi (talk) 22:22, 7 August 2015 (UTC)[reply]
(edit conflict) I see. So if vg reviews defaulted to not use the collapsible function (as the infobox does), there would be no other reason for the navbox to not autoexpand. Gotcha – czar 22:24, 7 August 2015 (UTC)[reply]
Correct. --Izno (talk) 23:21, 7 August 2015 (UTC)[reply]

In the case of {{UK Labour Party}}, is there any reason why | basestyle = background:{{Labour Party (UK)/meta/color}}; color:white; doesn't apply to the main header's link color as well? The show/hide links and non-linked titles change color with the color:white input, but not the main header. – czar 00:45, 26 August 2015 (UTC)[reply]

The CSS selector that colours the links site-wide has got higher specificity that an inline style on the parent element; thus, the color is not inherited by links. Inside Module:Navbox, the basestyle is passed on to Module:Navbar and is applied to its links directly. Alakzi (talk) 07:56, 26 August 2015 (UTC)[reply]
So there's no way to control the color of the navbox header links apart from putting span style tags within their wikilink? – czar 15:15, 26 August 2015 (UTC)[reply]
Well, we could try to add the spans inside the module by extracting wikilinks using regexes, but I'm not all too fond of that idea. Alakzi (talk) 15:25, 26 August 2015 (UTC)[reply]
This happens with every wiki link, not just navboxes. So yes, adding a span is the only workaround. That said, it is not recognizable as a link, which creates an accessability issue (hiding a link). That is why coloring links is discouraged. -- [[User:Edokter]] {{talk}} 16:45, 26 August 2015 (UTC)[reply]

Change reverted

I've just reverted the change that was made to the navbox module.

It had more than just some colour tracking additions. It included changes to the collapsible code which didn't work in all situations.

Also, noticed on {{UK Labour Party}} that there was a LUA error: "Lua error in Module:Navbox at line 279: attempt to index local 'key' (a number value)." -- WOSlinker (talk) 11:35, 7 September 2015 (UTC)[reply]

@Kephir and WOSlinker: I believe I've fixed both the error and the actual tracking, and I've undone all the other changes. I'll leave it to somebody else to check before publishing. Alakzi (talk) 12:13, 7 September 2015 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Navbox&oldid=679888927"