Jump to content

Template talk:Navbox/Archive 18

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15Archive 16Archive 17Archive 18Archive 19Archive 20→Archive 24

Question about groupstyle width

Example:

why even if i say width: 120px;, its width is still not 120px? C933103 (talk) 21:18, 2 September 2014 (UTC)

Because text in group header is non-wrapping (and 120px acts as minimum width is that case). Try adding white-space:normal;:
-- [[User:Edokter]] {{talk}} 21:27, 2 September 2014 (UTC)
Thanks!C933103 (talk) 02:37, 3 September 2014 (UTC)

"Please read before posting"

The advice in that box doesn't appear to have been changed much since I originally wrote it some years ago. How much of it is still relevant at this point? (At the very least, it needs rewritten to address the template's current Lua version, and I'm not sure if it still requires Tidy to be installed.) 「ディノ奴千？！」? · ☎ Dinoguy1000 01:03, 6 September 2014 (UTC)

We've managed to get Tidy out of the loop, so that part can go. The navbar bits are duplicated so that can also be cleaned up. -- [[User:Edokter]] {{talk}} 08:55, 6 September 2014 (UTC)

Need Your Help on Navbox

I imported all possibly necessary items for Navbox from enwiki tu Sundanese (suwiki) including common.css, common.js, monobook.css, monobook.js. The problem is : Navbox doesn't appear properly, only navbox border appear, no Navbar, no text, no contents. Example : su:Template:Glaciers of Iceland. What else should we do? Thank you --Tedi (talk) 02:25, 16 October 2014 (UTC)

@Mssetiadi: You forgot to update the template's name (which is different since your Template namespace isn't named Template). I fixed it in su:Special:Diff/439831. Jackmcbarn (talk) 02:52, 16 October 2014 (UTC)
Oh my God, seem as simple as it ... but the result is so amazing for me. I thought template and citakan is changeable ... Anyway, thank you very much --Tedi (talk) 03:20, 16 October 2014 (UTC)

"Autocollapse" state is not pretty good

Why the default behavior is "autocollapse"? There are many articles with one template. Then is a problem: the expanded template takes more place on the page, attracts a lot of attention. Is not better "collapsed" as default behavior?--Unikalinho (talk) 14:55, 3 November 2014 (UTC)

  • It is not. If you have a page or a specific navbox that is troublesome, I suggest posting on the talk page for that page or that navbox and achieving a consensus to change the state of that box to collapsed. But, on a whole, autocollapse is the best fit. — {{U|Technical 13}} (e • t • c) 16:22, 3 November 2014 (UTC)
Well. For example. Naim Kryeziu. Luigi Barbesino. On this pages there is one template "autocollapse". As well is one, is expanded... And here and here is collapsed, because is not one. Must this template to be necessarily expanded on the pages, where is only one?--Unikalinho (talk) 16:43, 3 November 2014 (UTC)
  • As I said, make a case for it on the talk pages of the pages you think should be changed. Make sure to notify any wikiproject listed at the top of the talk page of your proposal to encourage discussion. Here is not the place for your request. Happy editing! — {{U|Technical 13}} (e • t • c) 16:59, 3 November 2014 (UTC)
We are talking about setting of the templates exactly, not about the pages or browser-problems etc. And I was sent here from this place. I don't understand, why the default behavior is autocollapse and why I may not change by "collapsed". I was told that this must be discussed here --Unikalinho (talk) 17:41, 3 November 2014 (UTC)
  • Comment I directed Unikalinho here because of a large number of identical edits (specifically, setting |state=collapsed rather than leaving |state=autocollapse) made over the past 24 hours, as he was making a unilateral decision to appease his own personal aesthetic rather than seeking consensus or even leaving a reason for his edits. This editor has also done this same thing across several projects other than WP:FOOTY. -- Jkudlick (talk) 17:49, 3 November 2014 (UTC)
I have replied to Jkudlick
  • I will not respond to comments on this discussion left on my talk page if they are better left here. You asked "The people like to see an expanded template?" Does it matter? Just because you don't want to see an expanded navbox doesn't give you the right to unilaterally change the way navboxes are displayed on dozens of articles. Part of being a good editor is building consensus. A consensus on having the default navbox behavior as autocollapse was reached years ago before you or I began editing. If you wish to change the display of the navbox on that many articles, start a discussion on the project talk page rather than enforcing your personal aesthetic. -- Jkudlick (talk) 18:03, 3 November 2014 (UTC)
"A consensus on having the default navbox behavior as autocollapse was reached years ago before you or I began editing" — can I see this consensus?--Unikalinho (talk) 18:09, 3 November 2014 (UTC)
I went to Wikipedia:Village pump (proposals). This is answer for me! Vicious circle!--Unikalinho (talk) 02:15, 4 November 2014 (UTC)
I do not see a reason why it should be changed. When there is only one template, i think it's good that it is expanded right away. Kante4 (talk) 15:01, 4 November 2014 (UTC)
The purpose of a navbox template is to allow easy access to links to related articles, so they should be open for all to use. When many such templates are on a page, it becomes distracting to have them all open as it becomes harder to find the navigation box you are most interested in, hence the autocollapse option when many are present to reduce this problem. I find the current arrangement far superior to collapsing navboxes by default (if the links are so unimportant that we don't need to show them when the navbox is the only content there, they perhaps we don't need the navbox). The current arrangement is a very sensible and useful one from many perspectives. I will agree to change if you design a navbox template that automatically opens when Wikipedia's brain reading software detects a reader is interested in it. SFB 18:12, 6 November 2014 (UTC)
I understand that you would like the navboxes to be even "expanded" instead of "autocollapse"?
But a person can always to expand it for himself. On the other hand, when the navbox is expanded by default, distracts the reader from the main text (the page).--Unikalinho (talk) 21:26, 6 November 2014 (UTC)
Agree with SFB, who has explained it clearly. A single navbox is hardly going to distract the reader when they are placed right at the bottom, away from the main text. LRD 00:34, 7 November 2014 (UTC)

Switching to mw.html

Any objections to switching to mw.html? Module:Navbox/sandbox has, what should be, a working version using mw.html. Frietjes (talk) 17:57, 18 October 2014 (UTC)

If it is functionally equivalent to htmlbuilder, then I see no problem. -- [[User:Edokter]] {{talk}} 21:36, 18 October 2014 (UTC)
yes, it's about 99% the same (just change the periods to colons). Frietjes (talk) 16:35, 19 October 2014 (UTC)
since there were no objections, I have updated the code (saved the old version temporarily in the sandbox). Frietjes (talk) 19:16, 14 November 2014 (UTC)

HTML

.attr('cellspacing', 0) is obsolete. I think this should be .css('border-spacing', '0px'). Looks like there are two instances of this. --  Gadget850 talk 14:59, 14 November 2014 (UTC)

Any CSS should be in Common.css, if not already there. -- [[User:Edokter]] {{talk}} 15:40, 14 November 2014 (UTC)
What is your recommendation for this instance? --  Gadget850 talk 15:50, 14 November 2014 (UTC)
Check if the necessary CSS is already in Common.css, then remove the attributes; do not replace them with inline CSS. -- [[User:Edokter]] {{talk}} 19:02, 14 November 2014 (UTC)
Since you added the rule to the navbox class, it looks like I can remove the attribute, correct? --  Gadget850 talk 20:25, 14 November 2014 (UTC)
Already removed, along with the inline cell-spacing. -- [[User:Edokter]] {{talk}} 20:29, 14 November 2014 (UTC)

Nowrap lists

@Jackmcbarn, Dinoguy1000, Edokter, WOSlinker, and Isaacl: it would be helpful to avoid adding nowrap manually to lists. this is possible by preprocessing the input and adding the appropriate span tags. as a proof-of-concept, see Module:Navbox with nowrap lists. is there any objection to adding this feature to Module:navbox? in particular, it would not happen unless someone uses |nowraplists=yes or some similar parameter or class. I really don't care how it is triggered, but it would be very helpful to not have to explicitly add nowrap to each list item in these cases. if you want to see it in action, try template:navbox/sandbox3. (notifying recent editors of the module and the author of Module:Team roster navbox) Frietjes (talk) 19:44, 8 December 2014 (UTC)

This used to be done for all lists in the css but was removed in Nov 13. So may be able to add back without the need for the spans. -- WOSlinker (talk) 19:55, 8 December 2014 (UTC)
Not likely... It was removed because IE refused to behave. The spans are actually the only viable workaround. I'd have no problem with an optional mode that adds these spans. -- [[User:Edokter]] {{talk}} 20:25, 8 December 2014 (UTC)
@Frietjes: The idea itself seems fine. I reworked your implementation of it, though. Jackmcbarn (talk) 20:17, 8 December 2014 (UTC)
I suck at lua... Does that code account for any list markers (even mulptiple) to avoid wrapping the list marker itself inside the span? -- [[User:Edokter]] {{talk}} 20:25, 8 December 2014 (UTC)
Yes. Jackmcbarn (talk) 20:31, 8 December 2014 (UTC)
Jackmcbarn, for your next challenge, remove the edit links from the child box. Frietjes (talk) 20:33, 8 December 2014 (UTC)
note, I realize that problem may go away if the intermediate module is merged, rather than using the current hack. Frietjes (talk) 20:35, 8 December 2014 (UTC)
Indeed it will, so I don't think it's worth fixing now. Jackmcbarn (talk) 22:23, 8 December 2014 (UTC)
Jackmcbarn, good. a first draft of a version is now in Module:Navbox/sandbox (updated the example above). may be better to move the nowrapping to just before each list is rendered? also, may be useful to split this off as a separate module if it would be of use for {{hlist}} via Module:List. Frietjes (talk) 15:49, 9 December 2014 (UTC)
@Frietjes: Do you think this is ready for deployment now? (I'm fine with keeping the nowrapping where it is.) Jackmcbarn (talk) 21:18, 9 December 2014 (UTC)
Jackmcbarn, so long as there are no objections to triggering it with |nowraplists=yes, we are ready to go. I wasn't sure if this was the best parameter name (but seems fine to me). Frietjes (talk) 21:21, 9 December 2014 (UTC)
Ambiguous name. If I may suggest |nowraplistitems=, or if that is too long, |nowrapitems=. -- [[User:Edokter]] {{talk}} 21:43, 9 December 2014 (UTC)
Excellent idea. Please make it so! Plastikspork ―Œ(talk) 23:41, 8 December 2014 (UTC)

Chack the "name"

Maybe it would be worth to add check, if the |name= is suitable? I mean, some people won't know, that you need to fill "name" parameter with the PAGENAME value, otherwise the link will be red. --Edgars2007 (talk/contribs) 16:24, 26 January 2015 (UTC)

  • Typically, |name= parameters aren't used unless the name to be displayed is somehow different than the {{PAGENAME}}. This template is coded in Lua, so that will need to be fixed by someone who knows how to set the default name to the pagename in Lua. — {{U|Technical 13}} (e • t • c) 16:38, 26 January 2015 (UTC)
ifexist checks are relatively expensive. if feasible, I would think this would be useful for {{navbar}} as well. at one point, we had a database dump of all inappropriate uses, and then went through and cleaned them up. we may consider doing that on a regular basis? Frietjes (talk) 16:50, 26 January 2015 (UTC)
@Technical 13: The |name= parameter is necessary to make the v-t-e links appear at upper left. These links are present more often than absent, so "aren't used unless the name to be displayed is somehow different than the {{PAGENAME}}" simply isn't true.
@Edgars2007: Any navboxes with the |name= set incorrectly are picked up by monthly report Wikipedia:Database reports/Invalid Navbar links (see Wikipedia:Bot requests/Archive 62#Navbox templates with wrong names), which I normally act on within 24 hours, so any redlinks persist for no more than 32 days. --Redrose64 (talk) 17:05, 26 January 2015 (UTC)
Which should still be able to be done with default values just like is done on all infoboxes. — {{U|Technical 13}} (e • t • c) 17:31, 26 January 2015 (UTC)
Which "default values" would those be? --Redrose64 (talk) 18:21, 26 January 2015 (UTC)
I wouldn't spend too much time on this, since at some point in the future, the name parameter will become unnecessary. Jackmcbarn (talk) 19:49, 26 January 2015 (UTC)

Avoiding nowrap for groups

Here's a tip to avoid wide group cells, which happen due to CSS nowrap: use parameter "groupstyle = white-space: normal;". As far as I can see there is no unfortunately simpler way to do that. Perhaps this trick should be documented. --Chealer (talk) 00:01, 30 January 2015 (UTC)

V • T • E

Is there a way to suppress just the "V • T • E" without the "[show]/[hide]" button?--- ARTEST4ECHO(Talk) 22:59, 4 February 2015 (UTC)

Yes, you can control the VTE links with the |navbar= parameter, and the show/hide link with the |state= parameter. They are documented on the template page. -- [[User:Edokter]] {{talk}} 23:09, 4 February 2015 (UTC)
Thanks. For some reason I never saw the |navbar= parameter. I found the |state= parameter, but the off and plain hide both. Thanks--- ARTEST4ECHO(Talk) 20:52, 6 February 2015 (UTC)
They do hide both, bit plain reserves space so the title remains centered. See Template:Navbox/testcases. -- [[User:Edokter]] {{talk}} 21:01, 6 February 2015 (UTC)

Not visible in App

This template is not visible in the Android App, while the Dutch version is visible. In English I only came across Template:Jesuit, that works fine, but always in collapsed state. Is there a reason for this difference? Wiki-uk (talk) 21:41, 17 February 2015 (UTC)

Automatic striping with numeric gaps

I created a proof-of-concept in Template:Navbox with striping, but this would be more elegant if there were another option for |evenodd= to enable this feature, rather than the hack that I am using. any comments? Frietjes (talk) 18:32, 21 February 2015 (UTC)

note, this would be used in Template:Country topics and Template:Navbox Ukraine district‎, for example. Frietjes (talk) 18:38, 21 February 2015 (UTC)

class="metadata"

Please add the "metadata" class to the whole navbox. Otherwise the multimedia viewer galleries are filled by unrelated icons contained in navboxes. See mw:Help:Extension:Media_Viewer#How_can_I_disable_Media_Viewer_for_unrelated_images.3F for more info. --Nemo 12:15, 12 November 2014 (UTC)

Don't use editprotected for feature request... This requires some new code, and even I don't know where to begin. Ping Mr. Stradivarius. -- [[User:Edokter]] {{talk}} 12:27, 12 November 2014 (UTC)
Note that doing so will make it totally unusable from mobile view. Jackmcbarn (talk) 21:41, 12 November 2014 (UTC)
Might be worth considering for {{Portal}} though. -- WOSlinker (talk) 21:56, 12 November 2014 (UTC)

@Nemo:, are there any particular navboxes that have icons visible in media viewer? Might be possible to modify some other templates, such as {{Icon}} instead. -- WOSlinker (talk) 13:09, 14 November 2014 (UTC)

@WOSlinker:, uh, you wanted to reply to User:Nemo_bis, not User:Nemo :) --.../Nemo (talk • Contributions) 03:38, 25 February 2015 (UTC)

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)

mw-collapsible

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)

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)

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

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

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?

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)

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)

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

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)

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

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)

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)

@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)
Thanks—I didn't know vg reviews was the culprit. What a pain in the ass – czar 22:15, 7 August 2015 (UTC)
@Alakzi, does {{infobox vg}} also count as a collapsible element, or just vg reviews? – czar 22:20, 7 August 2015 (UTC)
It does iff "collapsible" is set to "yes". Alakzi (talk) 22:22, 7 August 2015 (UTC)
(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)
Correct. --Izno (talk) 23:21, 7 August 2015 (UTC)

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)

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

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)

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

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)

@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)
@Alakzi: I checked the sandbox changes against a few navboxes and they were fine, so I copied the sandbox to live. -- WOSlinker (talk) 12:31, 7 September 2015 (UTC)
@Alakzi: Ping fail. See why. —Keφr 12:36, 7 September 2015 (UTC)
@Kephir: Could you be more specific? I did actually sign again. Alakzi (talk) 12:39, 7 September 2015 (UTC)
@Kephir: Just wondering though why {{UK Labour Party}} is in the category and {{Independent Labour Party}} is not when both navboxes have the same colours? -- WOSlinker (talk) 12:40, 7 September 2015 (UTC)
The <nowiki>...</nowiki> tag in {{Labour Party (UK)/meta/color}} is retained; <nowiki>#DC241f</nowiki> is an invalid colour. Alakzi (talk) 13:02, 7 September 2015 (UTC)
mw:Help:Echo, first point: "The diff hunk must be recognised as an addition of new content, not a change to existing content". Basic reading comprehension. —Keφr 13:19, 7 September 2015 (UTC)
How is adding pings not an addition? Alakzi (talk) 13:21, 7 September 2015 (UTC)
Starting a new paragraph or new line is a new addition. Not so the same line. --Izno (talk) 15:40, 7 September 2015 (UTC)
I see; thank you. Alakzi (talk) 20:58, 7 September 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Navbox/Archive_18&oldid=848611355"