Template talk:Navbox/Archive 17

Archive 10

←

Archive 15

Archive 16

Archive 17

Archive 18

Archive 19

Archive 20

wheel warring?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

can someone point me to where [1], [2], and [3] are being actively discussed? I started a thread on Template talk:NRHP in Champaign County, Ohio, but got no discussion, just more reverts. Frietjes (talk) 22:50, 28 February 2013 (UTC)

You probably got no discussion at Template talk:NRHP in Champaign County, Ohio because that page has exactly one watcher. I'm guessing it's yourself... --Redrose64 (talk) 23:08, 28 February 2013 (UTC)

We could just discuss it here. Category:Navigational boxes without horizontal lists is useful to see what Navboxes do not have the hlist class applied to them. Category:Navigational boxes with custom list spacing is one I was using to remove some uses of the padding & line-height styles in navboxes but is no longer needed. And Category:Navboxes using background colours which has been left in there does not seem to have been used for much since it was added. If there is some agreement from some editors that it's still useful to track into Category:Navigational boxes without horizontal lists then I'll add it back in. -- WOSlinker (talk) 23:42, 28 February 2013 (UTC)

we should re-add the Category:Navigational boxes without horizontal lists tracking. I disagree that "its sole purpose is to permit a tiny minority to impose non-policy on the vast majority of editors who disagree". I find it useful to track templates like Template:Ancestry of José Rizal and Template:Glass chemistry see also which aren't traditional navigational boxes, but are using the navbox template. Frietjes (talk) 23:52, 28 February 2013 (UTC)

Please can somebody restore the recently-removed and useful hList tracking category; apparently removed due to a content dispute elsewhere. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:58, 28 February 2013 (UTC)

• I also used it often and believe it should be readded. Removing it was pointless and unhelpful. -CapitalR (talk) 07:01, 6 March 2013 (UTC)
  •  Done. There is consensus at this talk page for having a tracking category for hlist, and it has not been demonstrated by the opponents that there was any other discussion about removing it. De728631 (talk) 14:05, 6 March 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Quote at the bottom

In Template:Swami Vivekananda, I "experimentally" added a quote at the bottom, see this version, which was removed later by another editor. I did not revert his edit or ask any question, since it was a minor issue. The only other template where I added such quote was Template:Sister Nivedita. Note,. both the quotes were 1) taken directly taken from Wikiquote 2) were well sourced (at Wikiquote), 3) brief in length and 4) linked back to Wikiquote. But, the quote at Template:Prabhat Ranjan Sarkar, which followed the mentioned two articles, has started some edit disputes.

I personally don't see any issues if 1) we understand readers will look for quotes of the person and thus it'll be helpful 2) that fulfils the 4 conditions mentioned above. Also I am not going to fight with anyone if they remove the quote. Opinions? --Tito Dutta (contact) 21:51, 4 March 2013 (UTC)

Where they will look for those quotes is on the article page or at Wikiquote. A navbox is not the appropriate place to have that information. This is not to say that a link to Wikiquote might not be a good idea or a bad idea, simply the use of a quote is definitely a bad idea. --Izno (talk) 22:10, 4 March 2013 (UTC)

Hm, a) the template goes at the bottom of every articles related the person, and Wikiquote link is generally included in the main biographical article only! b) Wikiquote can not be linked without adding a sample quote! --Tito Dutta (contact) 22:14, 4 March 2013 (UTC)

This just seems like a bad idea. Besides the invitation to fight over which quote gets used, it bulks out an area which is already typically overcrowded (which is why so many of these templates are normally collapsed). Mangoe (talk) 02:06, 5 March 2013 (UTC)

Quotations should only be included in a navbox when they have articles themselves (not many have that notability). For example, if there was a navbox for Julius Caesar, the inclusion of Alea iacta est would be justified. Otherwise, a generic link to wikiquote and related pages at other projects may be enough. Cambalachero (talk) 12:53, 5 March 2013 (UTC)

The point of navboxes is to help readers navigate though the articles about a subject. Adding quotes would confuse things, and would distract readers from the goal. --NaBUru38 (talk) 15:02, 6 March 2013 (UTC)

I don't really care enough to prohibit this. I could imagine university templates adding their mottoes in this way. If the editors involved in the particular templates agree that this is desirable, then I don't think we need to add a rule saying that they can't experiment with new ideas. In fact, it's our official policy that editors are permitted to try out new ideas on occasion, if they think that the new idea might result in an improvement. WhatamIdoing (talk) 16:56, 9 March 2013 (UTC)

By the same token, editors are not free to edit against a consensus, and I would consider 4 or 5 users to be such in this matter (not all of whom may be involved; however, a third opinion was sought). There are also things like WP:NAVBOX and WP:NAV to consider. --Izno (talk) 18:12, 9 March 2013 (UTC)

Relation of Template:Navbox to Template:Navbox/doc?

May I ask what the relation of Wikipedia:Template Navbox is to Template:Navbox/doc? I thought knew per Wikipedia:Template documentation link, but on checking at the recent history Edits for Template:Navbox, I see that there is no automatic migrating of material from the first to the 2nd.

True, there might be lots of things that are incomprehensible to most readers in Template:Navbox, but with automatic migrating, at least there would be a benchmark from which to attempt clarification in Template:Navbox/doc. --Thomasmeeks (talk) 11:10, 10 April 2013 (UTC)

What do you mean by automatic migrating? The information which is changed at the /doc page appears on the main template page, give or take a day or two for the database to "catch up". If that is what you mean by automatic migration, then yes, but not (really) in the direction you think. --Izno (talk) 13:13, 10 April 2013 (UTC)

Well, thank you.

Hmm. Maybe I'm missing something, but it looks like that's not happening below in going

FROM:

Template:Navbox/doc: Revision history:

18:54, 28 March 2013? DixonDBot ? m . . (37,432 bytes) (-1,679)? . . (Migrating 59 interwiki links, now provided by Wikidata on d:Q5030944)

16:00, 1 March 2013? Romaine ? . . (39,111 bytes) (+26)? . . (+Interwiki) (undo) (cur | prev) 20:58, 30 December 2012? Redrose64 ? . . (39,085 bytes) (-40)? . . (??Setup parameters: cut down on some (not all) the <nowiki>)

18:11, 30 December 2012? Funandtrvl )? . . (39,125 bytes) (+176)? . . (add examples, sections, rmv ex sp)

TO:

Template:Navbox: Revision history:

02:45, 26 March 2013? Dragons flight? . . (128 bytes) (-19,743)? . . (Installing Lua version)

14:01, 6 March 2013? De728631 ? . . (19,871 bytes) (+872)? . . (Restored tracking category per Template talk:Navbox#wheel warring? There is consensus to have this implemented.)

22:34, 28 February 2013? Nyttend ? . . (18,999 bytes) (-872)? . . (Re-remove category; its sole purpose is to permit a tiny minority to impose non-policy on the vast majority of editors who disagree)

22:25, 24 February 2013? WOSlinker? . . (19,871 bytes) (+872)? . . (Adding back tracking category, this is still useful for now. There is not really a need to have discussions for adding tracking categories.But there is a need to discuss before removing useful things.)

22:12, 24 February 2013? Nyttend? . . (18,999 bytes) (-4)? . . (Remove stray brackets. Apologies for not making enough sandbox tests)

22:08, 24 February 2013? Nyttend? . . (19,003 bytes) (-868)? . . (Removing tracking category: it was added without discussion, despite the instructions at this page, and it's being used by a tiny minority of editors to force their will on everyone else)

Rather it looks like there are independent edits happening at Template:Navbox, which would lead to a growing discrepancy over time between the 2 pages. Is that correct? --Thomasmeeks (talk) 18:10, 10 April 2013 (UTC)

the actual parameters used by this template have been fairly stable for some time. what you are seeing in the history for the template (1) changes in tracking categories, which are not typically documented, and (2) changes in the details implementation, which should change the parameters or their usage. so, none of these required any changes to the documentation. what you are seeing in the history for the documentation is migrating interwiki links, and formatting of the presentation. in theory, any time a functional change is made to the template, the documentation should be updated. I see nothing to suggest that hasn't been happening here. I have, however, seen problems with other templates. Frietjes (talk) 22:42, 10 April 2013 (UTC)

by the way, in the pre-lua days, I wrote a script that would take a chunk of template code and return all the parameters used by the code. this would help with generating a blank version of the template. I'm sure something similar could be written for lua code. Frietjes (talk) 22:43, 10 April 2013 (UTC)

Well, double hmm (; ). But studying some of the Edits in (1) and (2) together with the above should bring all of them into further focus. But I think I get the gist. Thank you for your patience. --Thomasmeeks (talk) 02:54, 11 April 2013 (UTC)

Lua implementation

I've written a Lua implementation of the template at {{Navbox/lua}}. The Lua code is at Module:Navbox. All the testcases render identically to the current template, as far as I can see. The testcases page, with its 112 navboxes, renders in about 5 seconds, versus 9 seconds for the current version. I believe the Lua version is a lot easier to understand and maintain, as it uses an HtmlBuilder module I wrote to avoid the current mishmash of HTML tags, CSS, and content. It also adds support for an unlimited number of rows, at no additional cost. Any feedback is appreciated. Toohool (talk) 03:05, 8 March 2013 (UTC)

Just thinking it might be worth merging in the {{Navbox with columns}} features as well? -- WOSlinker (talk) 21:00, 8 March 2013 (UTC)

That template can certainly stand to be converted to Lua, but I'm not sure it should be "merged" with this one. It basically uses {{navbox}} as a shell. All the complexity in it is generating the table of columns, to be passed in as list1 of the navbox. To me, it's more logical to keep it as a separate template/module, that simply invokes this one. Toohool (talk) 23:46, 8 March 2013 (UTC)

I found a slight difference in the Lua version regarding the evenodd param. In the current version, an empty evenodd param causes the navbox to have no striping. This seems like a bug, as it's undocumented (evenodd=off is the documented way to turn off striping), and results in meta-templates like {{Navbox musical artist}} that pass through the evenodd param having no striping by default. There's a similar issue with the listpadding param; if it's empty, the list cells end up with no padding, instead of the default 0em 0.25em. The Lua version fixes these problems.

Rolling this new version out to 2 million pages at once is a bit scary, so I'd propose a test phase to be deployed on a few of the most widely-used meta-navboxes. For example, we could first roll it out to {{US county navigation box}} (79,000 transclusions) and {{Navbox with collapsible groups}} (65,000), by simply replacing their transclusion of {{navbox}} with {{navbox/lua}}. Then, if all goes well, to {{Navbox musical artist}} (129,000), and then to the main template. It's not a perfect test, as it would only exercise the navbox features that are used by these templates, but it's better than nothing. Toohool (talk) 07:26, 13 March 2013 (UTC)

To begin a test deployment of the new Lua implementation, I'd like to request that {{Navbox with collapsible groups}} and {{US county navigation box}} be modified to use it, by simply changing {{Navbox to {{Navbox/lua. I've tested these changes in the TemplateSandbox on a number of pages and all looked identical. Toohool (talk) 21:17, 17 March 2013 (UTC)

Perhaps on a somewhat smaller scale; please use a separate lua version of {{Navbox with collapsible groups}} first before replacing the live template. — Edokter (talk) — 21:59, 17 March 2013 (UTC)

I'm not exactly sure what you mean about a separate Lua version... I have a version at User:Toohool/sandbox/Template:Navbox with collapsible groups, which I used for testing in the TemplateSandbox. Anyone can go there and enter a sandbox prefix of User:Toohool/sandbox to render any page with the Lua version. Do you mean that you'd rather see this deployed first on some templates with fewer transclusions? Toohool (talk) 22:11, 17 March 2013 (UTC)

I went ahead and installed the Lua version in {{Navbox with collapsible groups}}, that is used less often than {{US county navigation box}} and it's children are more varied so it probably makes for a better test. Dragons flight (talk) 00:56, 19 March 2013 (UTC)

Note, I've also semi-protected the two related Modules and one related template. This is a compromise between broad visibility and the need to allow the author access to correct any errors that might arise during testing. It should be upgraded to full protection before a broader deployment. Dragons flight (talk) 01:05, 19 March 2013 (UTC)

• I haven't had a chance to look through it carefully, but so far it looks great. Toohool, thanks for all your hard work getting this done -- I wish I had the time to help! --CapitalR (talk) 20:19, 19 March 2013 (UTC)

• I copied the current template to {{Navbox/old}} so that editors on a wiki without Lua can have something to work with. We have been doing this on the cite templates, and I think we should do it across the templates. See also {{cite compare}} which compares old and Lua templates and could be adapted to compare other templates. --— Gadget850 (Ed) ^talk 00:48, 20 March 2013 (UTC)

Bugs

• First bug reported at user talk:Frietjes#Attention, navbox fundi (it may be unrelated, but I figured I'd throw it out there). --Izno (talk) 12:35, 26 March 2013 (UTC)

Here's a shortened example. Seems to affect {{Navbox with columns}} & {{Navbox with collapsible groups}} -- WOSlinker (talk) 13:17, 26 March 2013 (UTC)

Also, if you change list1 to above they then work. -- WOSlinker (talk) 13:32, 26 March 2013 (UTC)

The problem

Tracked in Phabricator
Task T48566

function p.navbox(frame)
    -- ParserFunctions considers the empty string to be false, so to preserve the previous 
    -- behavior of {{navbox}}, change any empty arguments to nil, so Lua will consider
    -- them false too.
    local args = {}
    for k, v in pairs(frame:getParent().args) do
        if v ~= '' then
            args[k] = v
        end
    end
    return p._navbox(args)
end

pairs(frame:getParent().args) runs getAllExpandedArguments which parses every template input; however, neither pairs nor getAllExpandedArguments appear to be order preserving. If the above= parameter gets processed first, then everything is normal. However, if the below= parameter is processed first, then it reaches <references /> before the call to <ref> has been processed and there is nothing to display. Strictly speaking I would consider this to be a bug in the Lua engine itself; however, we probably need a workaround for right now. Dragons flight (talk) 13:47, 26 March 2013 (UTC)

Okay, I've patched Module:Navbox to force in order parsing of all parameters that could reasonably contain references. I'll go make a bugzilla report as well. Dragons flight (talk) 14:08, 26 March 2013 (UTC)

Reported as bugzilla:46566. Dragons flight (talk) 14:29, 26 March 2013 (UTC)

Very subtle, kudos for tracking that down. Based on BJorsch's comment in that bug, it seems that Lua-backed templates cannot iterate over all their arguments without potentially breaking <references />. (Unless they first read all the arguments in the proper order, like your patch, but that's an incomplete fix for templates that take an unlimited number of arguments, like this one.) That is somewhat unsettling. Toohool (talk) 07:46, 27 March 2013 (UTC)

But why did you put limitation of 20 lists/groups in that patch? --DixonD (talk) 08:37, 18 April 2013 (UTC)

Since it wasn't actually an issue with getAllExpandedArguments, instead being the fault of {{Navbox with columns}} (which has since been fixed), can someone remove the patch so the template isn't limited to 20 lists? 120.144.193.219 (talk) 10:34, 27 April 2013 (UTC)

The patch doesn't limit the template to 20 rows, it only means that navboxes with more than 20 rows may still have the issue with <references /> not working as expected... and that would only happen with other meta-navboxes that may have the same argument order issue that {{Navbox with columns}} had. Toohool (talk) 01:33, 4 May 2013 (UTC)

list0000000n

Your navbox somehow reacts to the fake parameters such as list{a number of zeros}n, for example, list01, list0002, list0000000000000018 etc. Note the white space between "Title" and "group4" (in the original was not so):

However, you may not bother, I already removed these parameters from my templates... Chermundy (talk) 08:07, 28 March 2013 (UTC)

the original would have a gap if the first list was not either 1 or 2, see this thread above. however, the gap was not as large. in your example there are multiple height:2px blank rows. Frietjes (talk) 17:03, 28 March 2013 (UTC)

Navbox on Meta Wiki

I was hoping to use the navbox template on Meta-Wiki. Years ago someone tried to copy the template but failed for some reason. I see the instructions at the top about installing on a home wiki, but Meta is not my own wiki to manipulate as I like. Are the necessary extensions installed on Meta? Should I be able to copy files and make this template work on Meta-Wiki? Thanks. Blue Rasberry (talk) 15:25, 13 May 2013 (UTC)

I copied over most of what you need, and tested it. it basically works, but it looks like you are missing some CSS class definitions that need to be added to MediaWiki:Common.css. I started a thread at meta:MediaWiki talk:Common.css#importing navbox to this wiki Frietjes (talk) 16:52, 13 May 2013 (UTC)

Thanks so much for this. Everything works there as it works on en.wiki. I appreciate your arranging this for me. Blue Rasberry (talk) 18:36, 29 May 2013 (UTC)

does Navbox require Scribunto?

I'm new to wikis and I'm trying to get navboxes on my own wiki, but I'm confused by the instructions. I thought it would be as simple as infoboxes, but apparently not! I'm working on MW 1.20.6. I have parserfunction, and Navbar. Do I really need HTML tidy? I couldn't seem to properly export and import the non-HTML Tidy template version. I think I properly exported and imported the common.css and common.js.

I went to Special:Export and exported Template:Navbox. But when I took a look at the page it made reference to {{#invoke. If my research is correct, it seems that Navbox makes use of Lua and by extension (pun intended) Scribunto. Is this correct, and if so, should this be in the documentation? I'm also having problems getting Scribunto to work properly despite it showing up in my Versions page, but I guess that's something I should be asking on Scribunto. Anyway, any assistance would be appreciated - thanks! Mentatim (talk) 18:21, 29 May 2013 (UTC)

check the edit history, and you can find a version that is pre-LUA, and should function nearly the same. Frietjes (talk) 18:23, 29 May 2013 (UTC)

bugfix - mobile

I have figured out an way to solve an issue on mobile wikipedia, where an black line appears between the groups and lists, and even between the groups and subgroups, if the latter are present. Obviously, the black line is not supposed to be there. This issue can be seen for example in the "parameter list" section of http://en.m.wikipedia.org/wiki/Template:Navbox The fix is to add the following newline after line 205 in Module:Navbox (without the syntaxhighlight tags, obviously):

 .css('border-left-color', '#fdfdfd')

--Snaevar (talk) 15:37, 28 June 2013 (UTC)

Disabled for now. This should be tested in the sandbox first to ensure this does not interfere with custom styling. Also, transparent may be a more appropriate value. — Edokter (talk) — 20:15, 28 June 2013 (UTC)

seems fine, although I would mimic the construct used earlier in the template, where these css statements are combined (search for fdfdfd and you will find it). I checked it in the version on meta (meta:module:navbox) didn't see any problems. Frietjes (talk) 20:35, 28 June 2013 (UTC)

URLs in below label

Is it appropriate to place URLs in the below labels of navboxes? The example given in the documentation (i.e. here) suggests that it's OK, but, now that I think about it, I don't think I've ever seen the below label used in this way before. If it's no longer appropriate, could we update the documentation to reflect this? Thankyou. V_oBEDD 12:58, 2 July 2013 (UTC)

there is some general policy that discourages the inclusion of external links within navigational boxes (see Wikipedia:NAV#Navigation templates provide navigation within Wikipedia). I will revise the documentation. Frietjes (talk) 18:48, 2 July 2013 (UTC)

The one place I've seen external links used are with public companies on the stock market(s). I personally don't agree to that usage, but that's there. --Izno (talk) 02:13, 3 July 2013 (UTC)

Thankyou for clarifying this. V_oBEDD 23:56, 4 July 2013 (UTC)

Edit request on 8 October 2013

please add 'hlist hwrap' after 'hlist hnum' in the list of horizontal list classes which will remove Template:EmmyAward ComedyVarietyMusicWriting 1960s and others from the tracking category Frietjes (talk) 21:41, 8 October 2013 (UTC)

 Done De728631 (talk) 13:19, 9 October 2013 (UTC)

Fixed ordered list bug

I finally fixed a bug in the module (old template code contained the same bug) where multiple ordered lists were rendered as unordered lists. I initially attributed it to the parser, but it was in fact caused by poor wiki formatting. In wikitext, list items should always be contained on their own line; closing div tags on the same line as the last list item causes the parser and Tidy to fail. I've added a newline to each navbox container (except title) so that list items are no longer polluted with closing div tags. — Edokter (talk) — 12:34, 29 September 2013 (UTC)

@Edokter: I am guessing this bug fix is the reason why we now have excessive <p>...</p> tags in the above and below sections of these navboxes. check the html source for

what is the fix? Frietjes (talk) 19:04, 3 October 2013 (UTC)

I don't know. I'll revert the fix for now. Apparently, the newline() causes unwanted paragraphs when anything other then lists are used. — Edokter (talk) — 19:20, 3 October 2013 (UTC)

What's up with Navbox lately? The "above" and "below" groups on all of them seem to be huge (lots of space above/below the text inside them). It's making many of them look off -- just look at Template:Navbox and see how all the above/below cells in the examples are now ugly. Some of the group/list cells also look like they may have slightly more padding as well. Not sure if this is related to this change or something else that was modified....--CapitalR (talk) 16:41, 11 October 2013 (UTC)

probably issues with stale cache. try opening the page in question, performing no edits, then saving it. if that doesn't solve the issue, provide a screenshot and/or example link. Frietjes (talk) 17:01, 11 October 2013 (UTC)

I don't believe this is an issue with caching. I'm viewing these pages on Windows 7 using Chrome. In my browser, the Navbox on the right (shown below) has extra padding above and below the text in the "Above" pane. The only difference between the two Navboxes are that the one on the right uses an hlist for the contents of "Above", while the one of the left does not. This extra spacing should not be occurring, and is new. I have seen this before when divs are used inside of cells, which is likely what's going on here. Is there any way we can fix this so that Navboxes don't have some cells with different padding that others? I know it's a minor issue, but it's nice to have things be aesthetically pleasing and pixel perfect. --CapitalR (talk) 02:38, 27 October 2013 (UTC)

My original fix caused the above/below to double in height, so this is technically not related. hlist has slightly different margins then regular text, so some minor discrepancy is expected. Before it was converted to LUA, I have made every effort to match hlist display to regular text inside navbox as close and consistent as possible, but some difference will always remain. — Edokter (talk) — 10:35, 27 October 2013 (UTC)

Source code

{{#invoke: Navbox | navbox }}

Where i can view the source code? XXN (talk) 11:35, 16 November 2013 (UTC)

At Module:Navbox -- WOSlinker (talk) 12:47, 16 November 2013 (UTC)

Edit request on 21 November 2013

Similar to Frietjes's request above, please add 'hlist vevent' after 'hlist vcard' to the list of horizontal list classes. This will remove Template:1989 WWF pay-per-view events and all the similar templates from the tracking category (very obvious, since they all appear at the front of the tracking category display). NSH002 (talk) 19:26, 21 November 2013 (UTC)

 Done -- WOSlinker (talk) 22:42, 21 November 2013 (UTC)

Nowrapping entries?

Is there a way to nowrap the individual rows when using the hlist listclass? See {{Detroit Tigers roster navbox}}. I'd like to make sure each entry in the list won't wrap. Or is my only recourse to no {{nowrap|12 [[Andy Dirks]]}} (for example)? Thanks!— X96lee15 (talk) 15:38, 22 November 2013 (UTC)

adding a &nbsp; between the number and the entry might do it for the first list. for the reason why the entries now wrap see MediaWiki talk:Common.css. Frietjes (talk) 16:21, 22 November 2013 (UTC)

Question about section linking

I can't seem to figure this out: if the link in the navbox links to a particular section on a page rather than the entire page, i.e.

[[page name#section name|displayed text]]

The "displayed text" is not black in the navbox on the bottom of that page. Please help. Timmyshin (talk) 04:33, 3 December 2013 (UTC)

The black and bold display is triggered by links to the same page, but links to sections are obviously different from an article's title (cf. Template talk:Navbox vs Template talk:Navbox). A workaround would be

[[page name#section name|{{#ifeq:{{BASEPAGENAME}}|page name|'''displayed text'''|displayed text}}]]

E.g. [[Template talk:Navbox#Question about section linking|{{#ifeq: {{BASEPAGENAME}}|Navbox |'''Template talk:Navbox'''|Template talk:Navbox}}]] produces: Template talk:Navbox. De728631 (talk) 14:10, 3 December 2013 (UTC)

Thanks for your input, but at least on my browser this only boldens the display and did not make it black and unlinkable. Timmyshin (talk) 18:43, 3 December 2013 (UTC)

As a note, this is one of the reasons why it is suggested not to link to sections in a navbox at WP:NAV. There are other reasons too. --Izno (talk) 23:02, 3 December 2013 (UTC)

Horizontal shrinkage

Since one of the latest Firefox updates (but I cannot remember which one) the navbox, when collapsed, shrinks not only vertically but also horizontally to the minimum allowed width so that the title is shown on one line. When the navbox expands, only then it reaches the whole page width. Some suggestions on how to improve the situation or even only to understand what is wrong? The horizontal shrinkage does not happen on Chrome nor Explorer. Carlotm (talk) 02:50, 21 January 2014 (UTC)

I haven't seen this problem in any recent version of Firefox. Do you have personal Javascript or CSS that may be interfering? Have you checked the offending navboxes? --Izno (talk) 03:37, 21 January 2014 (UTC)

Thanks Izno for your involvement. Any navbox was affected, of any type, any language. I think it's related to my Wiki preferences because when I reload a page with a navbox, I can see for a very short while the navbox in its full page format, then it shrinks. Nevertheless my Global account status says: All in order!. Carlotm (talk) 08:02, 21 January 2014 (UTC)

try checking without being logged in. Frietjes (talk) 13:44, 21 January 2014 (UTC)

Preferences → Beta features → Near this page broke navboxes. Per T61912 this is fixed but it is not yet deployed. --  Gadget850 ^talk 14:45, 21 January 2014 (UTC)

Yes, the issue is gone just by disabling all my settings in Preferences --> Beta Features. Thanks everybody. Carlotm (talk) 22:14, 21 January 2014 (UTC)

Double check the header notice

From what I can tell, the notice on this page is outdated since the introduction of Lua e.g. Navbox and Navbar no longer require parser functions. Someone want to double-check me on that or even fix it? --Izno (talk) 03:58, 21 January 2014 (UTC)

Navbar still uses parser functions. — Edokter (talk) — 14:56, 5 February 2014 (UTC)

Only the module is used in Navbox, so that's kind of irrelevant, isn't it? --Izno (talk) 19:35, 5 February 2014 (UTC)

Extra bullets between list entries

It appears that there are now two bullets between list entries (e.g. Template:Navbox/doc#Examples or Template:Denver Broncos roster navbox). What's the right way to fix this? Thanks! GoingBatty (talk) 14:13, 5 February 2014 (UTC)

I don't see two bullets. Need more info/screenshots. — Edokter (talk) — 14:55, 5 February 2014 (UTC)

I was seeing them yesterday when using the newest version of Firefox. I don't see two bullets today using IE8. Will check my Firefox later. Hopefully the problem has been resolved. Thanks! GoingBatty (talk) 18:43, 5 February 2014 (UTC)

Don't see the problem anymore on FF - thanks to whomever resolved the issue! GoingBatty (talk) 03:41, 6 February 2014 (UTC)

HTML errors

It seems the module produces a large amount of invalid HTML. I see table cells on a row to create a 2px lines that don't take into account the colspan, and I see problems with lists, that are prepended to a closing div element, before the list was parsed by MediaWiki (leading to the sequence div ul li /div /li /ul ). Some of this might be hidden due to Tidy, but if you throw a page with navboxes, like for instance Template:Dancing_with_the_Stars_(United_States) into the Special:ExpandTemplates, cross the "Show raw html" checkbox and then put the result in http://validator.w3.org then you will notice the errors. We should probably get this fixed, it might have unintended consequences on sites that copy this module and don't have tidy, as well as on things like Parsoid (for Visual editor) for instance. —TheDJ (talk • contribs) 14:22, 6 March 2014 (UTC)

You only just discoverd this? :) Navbox has always been a trainwreck. The 2px rows only need one cell to create the 2px vertical space, so no colspan is needed; this is purely for spacing the rows. As for the rest, there are error that will trip the parser into switching closing tags (last list item is not terminated by a line-break), which in turn throws Tidy into a fit. Perhaps a few well-placed linebreaks can fix a lot. Unfortunately, lua is still on my to-learn list, so I has little influence there. I know the old template code behaved better. — Edokter (talk) — 15:17, 6 March 2014 (UTC)

the colspan for the spacer would be easy to fix like this. Frietjes (talk) 18:21, 6 March 2014 (UTC)

That's not actually a bug, just the way table rows are expoited. The bigger concern is the linebreaks. There are no linebreaks to prevent paragraphs being added by the parser, but this causes trouble with lists; the last list item must be ended by a newline to be parsed correctly. This wasn't a problem in the old template. — Edokter (talk) — 19:08, 6 March 2014 (UTC)

can you provide a very simple example using {{navbox/old}}? if it wasn't a problem with the old template, then it "should" be possible to fix. Frietjes (talk) 21:26, 6 March 2014 (UTC)

Seems the old one has the same problem (paste the above in Special:ExpandTemplates and look at raw HTML). I'm going to test how linefeeds affect navbox/old. — Edokter (talk) — 21:47, 6 March 2014 (UTC)

Well, that introduces <p>...</p> around the list contents (and other fields like above/below) when there is no list, so we have the same problem there. Possible workaround: .navbox p { margin: 0; } to negate the extra space added by paragraphs, at the cost of normal paragraphs having no space in between (if they ever appear there). Then we can add newlines before every closing div, in navbox/old and the module. — Edokter (talk) — 21:53, 6 March 2014 (UTC)

a hack (see User:Frietjes/n) is to use {{str left}} to detect if the list starts with a bullet, and if so, add the newlines after the opening div, and before the closing div. but, if not, then no newlines. seems to validate and not add spurious <p>...</p>. string processing in the lua version would also be possible. Frietjes (talk) 00:13, 7 March 2014 (UTC)

Not going to bother with the old template. But if someone can write a function isList() in lua, then it can be applied in the module. — Edokter (talk) — 02:09, 7 March 2014 (UTC)

there is probably a cleaner way to do it, but this change appears to fix the module. it appends newlines if the list/above/below/title start with '*' or ':' or ';' or '#' or '{|', which covers all the lists and tables. is there anything else that needs to start on a newline? Frietjes (talk) 18:02, 7 March 2014 (UTC)

Can't think of anything else. Seems to work as advertised. — Edokter (talk) — 19:42, 7 March 2014 (UTC)

Can't we just parse the wikicode of lists, before we append it to the rest of the html string ? —TheDJ (talk • contribs) 21:06, 7 March 2014 (UTC)

seems like that might work, but I don't know if there is some other issue with changing the parsing order. Mr. Stradivarius, Dragons flight, or Toohool might know. Frietjes (talk) 21:35, 7 March 2014 (UTC)

That is a fairly complex business, especially with nested lists. I think Frietjes' solution works quite well. — Edokter (talk) — 21:50, 7 March 2014 (UTC)

That's not possible, as frame:preprocess doesn't turn wikitext lists into HTML; that's left for the parsing stage after Scribunto has finished running. And even if you could do it, it would mean sending the same wikitext through the parser twice, which doesn't sound like the best way to do things. If just adding line breaks doesn't work, then Frietjes' code is probably the way to go. — Mr. Stradivarius ^{♪ talk ♪} 02:28, 8 March 2014 (UTC)

Module is now updated to add condtional newlines, so it should not longer emit invalid wikitext/HTML for Tidy to trip over. — Edokter (talk) — 16:37, 14 March 2014 (UTC)

hlist wrapping

so, we now have module:team roster navbox. this is basically a frontend to module:navbox, which adds non-breaking spaces to list items. it seems like this could either be made more general, and/or an option could be added to module:navbox to 'nowrap' list items. basically, you would add <span class=nowrap> to any lists in the input fields if a flag is set. comments? Frietjes (talk) 18:28, 11 March 2014 (UTC)

In the beginning, the entire list item were nowrapped via CSS by default. This caused to many bugs, who's workaround only created more bugs, so the nowrap was removed. As long as you only nowrap the content of a list item, then it should not be a problem. Can you try wrapping the content of the list items inside a nowrap span? — Edokter (talk) — 20:40, 11 March 2014 (UTC)

right, the idea is to have the module add <span class=nowrap> to each list item, if a flag is set. Frietjes (talk) 23:21, 11 March 2014 (UTC)

I mean, can you test it in module:team roster navbox instead of adding non-breaking spaces? — Edokter (talk) — 01:18, 12 March 2014 (UTC)

yes, will do shortly. Frietjes (talk) 16:20, 15 March 2014 (UTC)

see Module:Navbox with nowrap lists, as implemented in template:navbox/sandbox3. there is an additional hack to prevent lists from being processed twice. for example, when you use child navboxes. seems to work on most of the tests I have tried, but I am sure there is some corner case that I haven't considered. Frietjes (talk) 01:00, 19 March 2014 (UTC)

Would this solve the sublist wrapping error,

• ............................................................
• i.e.
• when | ← template edge

• (this
• happens)
• ......

instead of

• ............................................................
• i.e.
•   | ← template edge

• when (this
• happens)
• ......

(at least, in Firefox-based browsers)...? Sardanaphalus (talk) 22:45, 27 May 2014 (UTC)

Template-protected edit request on 18 June 2014

I would like to add the page "{List of songs recorded by 5 Seconds of Summer} into the template. Btloveadele1d (talk) 09:15, 18 June 2014 (UTC)

I'm sorry, the template linked to the wrong talk page (I fixed that). However, there is no page with the title List of songs recorded by 5 Seconds of Summer, but 5 Seconds of Summer discography does exist, and is linked from the navbox. -- [[User:Edokter]] {{talk}} 09:27, 18 June 2014 (UTC)

Categorisation into Navboxes using background colours

Template:Other category-header templates is in Category:Navboxes using background colours, and that's fine. It's used on Template:Redirect category/doc, which is not in Category:Navboxes using background colours, and that's fine as well. But Template:Redirect category/doc is used in Template:Redirect category, which is in Category:Navboxes using background colours, but shouldn't be. Why is Template:Redirect category in a cat which is not applicable? --Redrose64 (talk) 11:20, 14 June 2014 (UTC)

I see what's going on. The intent of the tracking category is to catch navbox templates that use background colors, but it can't distinguish between navbox templates and regular templates that use navboxes (but it can distinguish between templates and doc pages). There's currently not a good way to fix this, but I plan to add a feature to Scribunto soon that will take care of it. Jackmcbarn (talk) 14:40, 14 June 2014 (UTC)

Is there no equivalent to <noinclude>...</noinclude>? --Redrose64 (talk) 15:17, 14 June 2014 (UTC)

There is, but that won't work. We need it to include one level deep, but no further. Jackmcbarn (talk) 15:23, 14 June 2014 (UTC)

In module Module:Navbox, the code in the hasBackgroundColors function is just checking to see if the titlestyle or groupstyle are used and if they are, the page gets added to Category:Navboxes using background colours. The code could be updated to check for "background" or "background-color" within those two parameters before adding pages to the category since templates such as Template:Other category-header templates use groupstyle but are only setting it to "font-weight:normal;" which has nothing to do with background colours. Should also be checking the basestyle parameter as well. -- WOSlinker (talk) 17:58, 14 June 2014 (UTC)

That fixed this particular instance of the problem, but it didn't fix the root cause. Jackmcbarn (talk) 15:55, 18 June 2014 (UTC)

Navbox not showing right

My Navboxes

• dont show any border,
• are squeezed to the left
• have "vte" in vertical bullet-list and
• consist of {{{title}}}{{{group1}}}|{{{list1}}}, etc. stuff

I exported/imported the whole Navbox-Template-Series, style (MediaWiki:Common.css) and script (MediaWiki:Common.js) and have LUA running. Afaik, I've Tidy running (although I found a statement saying it's not needed anymore).

Plz, what else is needed or needs to be done?!?Collabet (talk) 11:02, 3 March 2014 (UTC)

Did you also copy the styles for .navbar and .hlist? — Edokter (talk) — 11:40, 3 March 2014 (UTC)

Took the whole common.css (fresh MW 1.22 so didnt care) .navbar/.hlist not in there?!?Collabet (talk) 12:32, 3 March 2014 (UTC) ... thx for the hint! Dunno what the "export pages" put into my package, but it sure wasnt the media:common.css ... now it's running ... 2 days^^ *gnarf*Collabet (talk) 12:43, 3 March 2014 (UTC)

I am also running into trouble porting this over to another Wiki. I don't have server side access, but I did copy the (MediaWiki:Common.css) and script (MediaWiki:Common.js) (tied the ones from MediaWiki first then Wikipedia, but both had the same result). Most of the navbox displays correctly, except my lists are vertical. I copied the navbox/doc subpage, so I know the formatting is correct. I copied {Flatlist} to our Wiki just in case it was required, and it is working fine, but the {navbox} is still vertical. I can see the .navbar and .hlist entries in the Common.css files I copied, so I am not sure what else I missed. We do not have Lua installed, so I am using the original scripts for the non-Tidy installations. The show and hide is working great. Kentsmith9 (talk) 07:35, 29 June 2014 (UTC)

@Kentsmith9: Would you share the link to your wiki ? (I wouldn't mind having a look) also have you posted at MediaWiki help desk ? Mlpearc (open channel) 14:09, 29 June 2014 (UTC)

@Mlpearc: No problem, here http://wiki.waze.com/wiki/Template:USA_Navbox No I have not posted at the help desk, but I will now. Thanks. Kentsmith9 (talk) 16:57, 29 June 2014 (UTC)

I have now posted the question over there as recommended if anyone is having similar problems and wants to see what happens. http://www.mediawiki.org/w/index.php?title=Project:Support_desk#Navbox_not_working_100.25_44855 Kentsmith9 (talk) 16:57, 29 June 2014 (UTC)

class

There doesn't seem to be a class parameter that's interchangeable with bodyclass as style is with bodystyle – is this correct, or am I just missing something?

If there is no class parameter, then, for the sake of consistency, would someone with the know-how please add it..? Sardanaphalus (talk) 17:31, 18 June 2014 (UTC)

Is there a need for it? If not, adding redundant parameters is not an action that improves the template. In fact, I just removed the style= parameter from the documentation. -- [[User:Edokter]] {{talk}} 18:44, 18 June 2014 (UTC)

• There may be a need for clarification. I'm not sure if each pair (class / bodyclass, style / bodystyle) is (or should be?) taken as synonymous. Is the "body" of (in this case) a template always taken to mean the entire template, or, for instance, the entire template less anything header or footer-like (e.g. a titlebar, a "below" line, {{navbar}} links, etc)..? The style and class parameters, their documentation and other things may yet be useful (if that qualifies as needed). Sardanaphalus (talk) 15:55, 19 June 2014 (UTC)

The body refers to the entire body of the template. -- [[User:Edokter]] {{talk}} 19:02, 19 June 2014 (UTC)

• ...except when it's used to refer to the "middle" of the template or to "everything under the title / main heading" of the template, etc. Perhaps, therefore, it's better to retain class and style rather than bodyclass and bodystyle? Sardanaphalus (talk) 07:32, 20 June 2014 (UTC)

We have bodyclass, aboveclass, groupclass, listclass, belowclass and respective style parameters. For additional styling we have even more style parameters like basestyle, imagestyle, etc. That should proivide for any feasable scenario. -- [[User:Edokter]] {{talk}} 10:21, 20 June 2014 (UTC)

• That's not the point. The point is that bodyclass, bodystyle etc are ambiguous: "body" is sometimes used to refer to (1) an entire template, including headers, footers, etc; and/or (2) a template's container (usually invisible, e.g. a table); or (3) a template's contents other than any headers, footers, etc. So, while I'd retain bodyclass, bodystyle etc as alternate names, I'd keep class and style as the basic names. Sardanaphalus (talk) 15:56, 23 June 2014 (UTC)

For the purpose of styling, 1) and 2) are the same. For the middle, you can combine groupclass and listclass. We're not adding class parameters just for the sake of it. -- [[User:Edokter]] {{talk}} 16:41, 23 June 2014 (UTC)

• This is still beside the point. It's not about what I might want or could do, etc, etc. It's because "bodyclass" and "bodystyle" are ambiguous. Do you understand? Sardanaphalus (talk) 23:34, 23 June 2014 (UTC)

In any structure with identifiable header(s) or footer(s), the body is that part which is neither header nor footer. When there are neither headers nor footers, the body is then synonymous with the structure as a whole. Either way, it's case (3) described in your post of 15:56, 23 June 2014 - do you have examples of cases (1) or (2)? --Redrose64 (talk) 08:01, 24 June 2014 (UTC)

Not to hand, no, but it's something I've seen a number of times previously. Sardanaphalus (talk) 11:43, 29 June 2014 (UTC)

In navbox, |class and |bodyclass are synonymous. What is your point? -- [[User:Edokter]] {{talk}} 08:30, 24 June 2014 (UTC)

• That it isn't necessarily thought of as such. Why such resistance to retaining class? Do you also oppose retaining style alongside bodystyle? Sardanaphalus (talk) 11:43, 29 June 2014 (UTC)

Yes I do. That is why I removed style= from the documentation. The reason I oppose is simple; what if body and style are needed at some point in the future that does differ in functionality from bodyclass and bodystyle? -- [[User:Edokter]] {{talk}} 12:17, 29 June 2014 (UTC)

• Any thoughts as to what that functionality might be...? (Meanwhile, class and style should be retained.) Sardanaphalus (talk) 08:22, 30 June 2014 (UTC)

..._nclass

I'm here to request a group_nclass be added to this module. This would be useful for navboxes which have some sections that should only be viewed by certain user groups (such as the "actions" group of {{User toolbox}} for example since all of those pages would return "no permission" type errors, those links shouldn't be shown to "most" users. I've added the code for this functionality to this example template to be able to use it as a preview (since the parameter existing and not being used hurts nothing)). I would do it myself in the sandbox, but don't currently have enough knowledge of Lua to feel comfortable doing it right now (I may tackle it in a few weeks in no-one gets to it by then). Thanks for your consideration in this request. — {{U|Technical 13}} ^{(e • t • c)} 15:41, 28 June 2014 (UTC)

I made that change I mentioned and in the process of doing so I've found that group_n and list_n when set to display: none; leave an extra gap and I'm hoping someone can fix that. I also found out that setting groupnstyle doesn't also apply to listnstyle... So, I'm assuming that in addition to groupnclass we'll also need listnclass to be able to apply that style (group-show class) to the group and list. — {{U|Technical 13}} ^{(e • t • c)} 23:01, 28 June 2014 (UTC)

That is quite different from the above request, so I have split it. Groupn- and listnstyle are ment to work independently; that is by design. I'll have to dive in the gap issue, but that may be an old issue caused by hiding rows and cells. -- [[User:Edokter]] {{talk}} 00:35, 29 June 2014 (UTC)

• Edokter I'm hoping to get group_nclass and list_nclass added to the module, this would eliminate the need to use the ..._nstyle because the class would do all the styling... Just to make sure I'm clear. Thanks. — {{U|Technical 13}} ^{(e • t • c)} 02:14, 29 June 2014 (UTC)

• I know where you're going. Unfontunately, as navbox is structured now, it won't work without the gaps. You would want to hide the entire row, plus its accompanying 'gap row' (you'd need a row_nclass). Is there any way to detecta usergroup in a module? Then you can simply call that module as a condition checker for the entire group/list. -- [[User:Edokter]] {{talk}} 10:01, 29 June 2014 (UTC)

No, there's no way of detecting user rights from Lua at the moment. — Mr. Stradivarius ^{♪ talk ♪} 10:23, 29 June 2014 (UTC)

If you change the code in User toolbox from

| group5            = Admin history
| group5class = {{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||usertoolbox-admin}}}}
| group5style = {{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||display: none;}}}}
| list5style = {{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||display: none;}}}}
| list5                =

to

| group5            = Admin history
| list5{{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||donotshow}}}} =

then it will get rid of the gaps. -- WOSlinker (talk) 10:36, 29 June 2014 (UTC)

• I didn't see anything like this documented... I'll play with it on a testcases page and see if it will work for what I have in mind. — {{U|Technical 13}} ^{(e • t • c)} 13:00, 29 June 2014 (UTC)

Wouldn't it be simpler to do (simplified):

{{#if: <very complicated parser function used above>|
{{!}} group5 = Admin history
{{!}} list5  = ...
}}

-- [[User:Edokter]] {{talk}} 11:02, 29 June 2014 (UTC)

• I'm not aware of any way to get the viewing user's username or groups without JavaScript. Isn't that why the group-show css classes were created in the first place? — {{U|Technical 13}} ^{(e • t • c)} 13:00, 29 June 2014 (UTC)
  • Let me reprase that... -- [[User:Edokter]] {{talk}} 08:35, 30 June 2014 (UTC)
    • Edokter, that doesn't address the:

| group8         = Actions
| group8class = sysop-show
| list8            =
: [[Special:Block/{{{1|{{PAGENAME}}}}}|block]]
: [[Special:Unblock/{{{1|{{PAGENAME}}}}}|unblock]]
: [[Special:Userrights/{{{1|{{PAGENAME}}}}}|flag]]
: [[Special:RenameUser/{{{1|{{PAGENAME}}}}}|rename]]
: [[Special:Nuke/{{{1|{{PAGENAME}}}}}|mass delete]]
: [[Special:GlobalBlock/{{{1|{{PAGENAME}}}}}|globally block]]
: [[Special:GlobalUnblock/{{{1|{{PAGENAME}}}}}|globally unblock]]
: [[Special:CentralAuth/{{{1|{{PAGENAME}}}}}|merge global account]]
: [[Special:GlobalBlockWhitelist/{{{1|{{PAGENAME}}}}}|disable global blocks locally]]

issue where it is only suppose to show if the viewing user is in the administrator usergroup. Defining the class for the group should define it for all components of the group. — {{U|Technical 13}} ^{(e • t • c)} 12:00, 30 June 2014 (UTC)

I was merely trying to optimize WOSLinkers code. Using classes is not possible due to the gaps issue; it is not possible to hide an entire HTML table row using either class or style. The only way for that to work is to add rowclass/rowstyle. -- [[User:Edokter]] {{talk}} 12:44, 30 June 2014 (UTC)

Not done for now: I see. It actually "can" be done using tables, but not everything is set in place for that. I'm guessing the best way for this to happen, is that the module should be rewritten to make use of divs instead of a table. This is not a project I would expect anyone else to undertake, and I've no time to start working on learning Lua to do it myself for at least a couple weeks. As such, I'm marking this as not done for now, but will ping the commenters of this page when I do have time and have a working sandbox/testcases version to get some consensus as to whether or not to switch to that version if no-one beats me to it. — {{U|Technical 13}} ^{(e • t • c)} 13:34, 30 June 2014 (UTC)

Nobr

I'm almost sure that the answer is no, but I wanted to clarify: If I'm using hlist class, do I need to use the {{nobr}} template for certain elements (like {{nobr|SomethingVeryLong-OtherLongPartOfElement}}). --Edgars2007 (talk/contribs) 15:10, 22 July 2014 (UTC)

You don't need to, and not really recommended, but you can use it for individual list items if absolutely necessary. -- [[User:Edokter]] {{talk}} 15:51, 22 July 2014 (UTC)

Thanks. --Edgars2007 (talk/contribs) 08:46, 23 July 2014 (UTC)