Template talk:Navbox

From Wikipedia, the free encyclopedia
Jump to: navigation, search

mw-collapsible[edit]

Is there any reason {{Navbox}} hasn't been switched to use mw-collapsible yet? I don't see any discussion anywhere in the archives. ディノ千?!? · ☎ Dinoguy1000 19:34, 21 March 2015 (UTC)

I've switched the sandbox over to it, and other than the apparent lack of autocollapse functionality (which I substituted default-to-collapsed for in place of a better solution), it seems to work fine. ディノ千?!? · ☎ Dinoguy1000 20:07, 21 March 2015 (UTC)
I think there was some question of centering the title + the padding for Navbar. --Izno (talk) 00:11, 22 March 2015 (UTC)
I can't think of any issues; I've matched the padding for mw-collapsible years ago. -- [[User:Edokter]] {{talk}} 08:14, 22 March 2015 (UTC)
Since it's been over a week without further comments, I went ahead and changed the live module; if I still shouldn't have, please revert and trout me as appropriate. =) ディノ千?!? · ☎ Dinoguy1000 08:37, 30 March 2015 (UTC)
This should have been done years ago, but no one knows why we didn't. Possible because of the animation... We'll see. -- [[User:Edokter]] {{talk}} 09:24, 30 March 2015 (UTC)
BTW, I changed the default messages from [expand]/[collapse] to [show]/[hide]. -- [[User:Edokter]] {{talk}} 09:29, 30 March 2015 (UTC)
I'm still a bit worried about the lack of autocollapse functionality in mw-collapsible; is there a bug for that? Or is that perhaps the default behavior, and I didn't glean that fact from reading the code, and my change therefore overrides that default for all navboxes now? ディノ千?!? · ☎ Dinoguy1000 10:27, 30 March 2015 (UTC)
Show/Hide doesn't work very well on Navboxes with blue backgrounds, so I've reverted it for now. -- WOSlinker (talk) 12:14, 30 March 2015 (UTC)
Can we agree NOT to revert in full when any tiny weeny bug is encountered? Please reinstate. -- [[User:Edokter]] {{talk}} 15:31, 30 March 2015 (UTC)
Is there a rush to get this implemented? Wouldn't it be better to get it right first? There are some other useability issues that I've noticed as well.
If the navbox has a state parameter set to {{{state|autocollapse}}} then it will always be expanded.
Also, the navboxes on most template pages are now collapsed rather than expanded which causes extra work when working a few navbox templates at once. -- WOSlinker (talk) 15:58, 30 March 2015 (UTC)
Looking at the source for jquery.makeCollapsible, it looks like we should be able to build our own "show"/"hide" link (see for example lines 324–331, and see buildDefaultToggleLink() for how the link itself is built; reading the comment on lines 225–228 suggests we'd need a mw-customcollapsible-XXX ID on the navbox, and a mw-customtoggle-XXX class on the toggle we built (where "XXX" in both cases is some custom string, presumably to help prevent collisions)), which would allow us to apply any custom text color in the header to the link. Unfortunately, my Lua skills aren't up to the challenge in this case - I have no doubt I could come up with something that "works" by faffing about for a couple of hours, but couldn't guarantee it would work well or fit with the style of the rest of the code.
The autocollapse issue is one I mentioned twice before, both in my opening comment(s) and in my comment following my edit to the live module. jquery.makeCollapsible has no handling for an autocollapse mode; see lines 174–179 for the default case for example. ディノ千?!? · ☎ Dinoguy1000 18:47, 30 March 2015 (UTC)
You'd be reinventing the wheel. A better way is to improve the mw-collapsible code. -- [[User:Edokter]] {{talk}} 20:55, 30 March 2015 (UTC)
Is there any reason not to add .navbox-title .mw-collapsible-toggle a {color: inherit;} to the relevant stylesheet? As for the autocollapse issue, is it really that hard to replicate locally? For example, if ( $( '.navbox' ).length > 3 ) { $( '.navbox mw-collapsible-toggle' ).click(); } Mdowdell (talk) — Preceding undated comment added 22:58, 30 March 2015 (UTC)
That would make the link black by default, which is not what we want. -- [[User:Edokter]] {{talk}} 07:29, 31 March 2015 (UTC)
I think we can recycle some code from Common.js that now handles autocollapse. Once that is working, we can dispense with most of the legacy collapsible code, including navframe. Templates that rely on the old collapsible code (and navframe) can be switched to mw-collapsible by swapping classes as an interim solution. -- [[User:Edokter]] {{talk}} 16:44, 6 April 2015 (UTC)
Krinkle's comment on phab:T32352 suggests autocollapse (and innercollapse/outercollapse) support may not happen in jquery.makeCollapsible (which would be a crying shame IMO). That would be the bug report to submit any such patches to, but in the meantime we should look at your suggestion, Edokter. ディノ千?!? · ☎ Dinoguy1000 23:38, 13 April 2015 (UTC)
I read it as more of a "let's ship the product we've got now and if someone comes along to add the functionality they need not to regress their local functionality while making use only of mw-collapsible, then cool". --Izno (talk) 00:28, 14 April 2015 (UTC)
Hence why I said "suggests" and pinged Krinkle: his comment is written very vaguely and I would appreciate it (and probably wouldn't be the only one) if he could clarify what he meant. =) ディノ千?!? · ☎ Dinoguy1000 00:47, 14 April 2015 (UTC)
My response on phabricator:T32352 4 years ago was vague because the request appeared to look at mw-collapsible as an updated version of the script that some wikis have developed locally. From that perspective it would indeed "miss" certain features. However it was instead as a fresh start. Primarily intended for new content that doesn't use the old system and didn't need additional features. As well as an attempt to provide mechanisms that are actively supported and maintained, and work across all wikis. The version of the gadget I looked at didn't have a "autocollapse", "innercollapse", or "outercollapse" option. And when I later saw them elsewhere I didn't see a major use case for them that would justify delaying the initial version. Feel free to create tasks for specific features, with examples of how/where they would be useful. Note that mw-collapsible does support making an element collapsed by default. Simply give it mw-collapsed in addition to mw-collapsible. --Krinkle (talk) 01:13, 14 April 2015 (UTC)

Navbox/Navbar on mediawiki.org[edit]

Can someone share some insight wether it is possible to make the navbar links "translatable"? I have a user that keeps reverting mw:Template:Navbox to the old template code because he doesn't know how to localize the links in mw:Module:Navbar. I don't know either... but I do know the old template does not provide any translations. -- [[User:Edokter]] {{talk}} 16:48, 6 April 2015 (UTC)

Max number of groups/lists[edit]

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)

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)

Width having opposite effect[edit]

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)

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

Unlinked content in navboxes[edit]

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)

WP:NAV, an explanatory essay for WP:NAVBOX, already comments on this. --Izno (talk) 13:41, 13 July 2015 (UTC)
@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)
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)
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)
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)
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)

Has the image parameter been broken?[edit]

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)

Could you be more specific, perhaps with an example of what is broken? -- [[User:Edokter]] {{talk}} 21:59, 19 July 2015 (UTC)
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)
For images to work |list1= has to be non-empty. -- WOSlinker (talk) 22:24, 19 July 2015 (UTC)
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)

rewrite in the name of performance?[edit]

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)

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

Accessibility[edit]

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)

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)
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)
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)
@Edokter: Everything should be AAA when feasible. This seems feasible to fix. EvergreenFir (talk) Please {{re}} 19:08, 30 July 2015 (UTC)
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)
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)
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)
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)
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)
The darkest blue that gets AAA-compliance with #0645AD is #E7E7FF      -- WOSlinker (talk) 07:18, 31 July 2015 (UTC)
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)
Why? The visited link colour is darker. Alakzi (talk) 13:31, 31 July 2015 (UTC)
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)
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)
@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)
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)
Then we will only be able to use pastel colors. EvergreenFir (talk) Please {{re}} 16:48, 1 August 2015 (UTC)
That's a problem because..? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:55, 1 August 2015 (UTC)
It severely limits options? I'd rather see the link color change. EvergreenFir (talk) Please {{re}} 18:01, 1 August 2015 (UTC)

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

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

Contrast ratios[edit]

{{#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)

Ugly rendering on w:mr[edit]

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)

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)
@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)
It should be mw:Snippets/Horizontal lists. Alakzi (talk) 19:10, 2 August 2015 (UTC)

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)

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 अभय नातू (talkcontribs) 01:00, 3 August 2015 (UTC)