Jump to content

Template talk:Navbox/Archive 16

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

Orphan parentheses : non-breaking spaces, please !

Hello,

I encountered these orphan parentheses.

Look at these screen photos :

  1. screencast.com/t/MVErKf9Gw1
  2. screencast.com/t/g6J0pCZ6I

I like the spaces in the parentheses, but these orphan parentheses are not nice typography. Please replace the spaces with non-breaking spaces, so that every parenthesis be on the good line.

Thanks,

--Nnemo (talk) 21:45, 25 February 2012 (UTC)

See #Small bug above. ---— Gadget850 (Ed) talk 22:06, 25 February 2012 (UTC)

Small bug

Hi there, I was looking at Template:Mongol Empire, and noticed some spurious spaces in "( see also House of Ogedei )". I went to remove them, but it seems they are auto-generated by the template. The relevant lines are: 

* [[Chagatai Khanate]]
** see also [[House of Ogedei]]

Whatever I do to try to close up the whitespace in the source, the spaces still incorrectly appear in the output. I assume, therefore, that this is a bug in the "navbox" template itself. Regards, 86.177.105.189 (talk) 03:11, 14 February 2012 (UTC)

  • Hi, I believe this is by design, and is due to CSS settings in MediaWiki:Common.css, not in the Navbox template. I tend to agree with you that the spaces are unnecessary, but consensus has gone the other way. Since it's only a minor aesthetic issue it's not that big of a deal. If you'd like to continue the discussion at that talk page, please feel free (you can see my comments on a similar spacing issue here). --CapitalR (talk) 03:39, 14 February 2012 (UTC)
Thanks, I left a note at that talk page. 86.177.105.189 (talk) 03:54, 14 February 2012 (UTC)
It may be aesthetically minor, but in spelling it is a major breakthrough ( into the wrong direction ). -DePiep (talk) 08:44, 14 February 2012 (UTC)
The major factor for those spaces is the technical limitation to remove the prefixing space form the interpuncts. In some cases (but not all) I could remove the trailing space, which would result in "(see also House of Ogedei )", but that looks even worse. That is why I opted for all interpuncts to have the same spacing. — Edokter (talk) — 10:07, 14 February 2012 (UTC)
Is there any reason why that particular syntax needs to be used? I changed it to:
* [[Chagatai Khanate]] (see also [[House of Ogedei]])
and it seemed just fine. (Just previewed; didn't save the changes yet in case there is some reason for it that I'm not seeing.) 86.177.105.189 (talk) 14:09, 14 February 2012 (UTC)
That's probably an acceptable work-around in this case; but when there are more items in parentheses, less so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:30, 14 February 2012 (UTC)
What is the problem with extending it to several items? The following seems to work for me:
* [[Chagatai Khanate]] (item 1 · item 2 · item 1)
Unless there is some other compelling reason to use the "**" format, I don't think we should be doing so. You can argue that it's a minor cosmetic issue, but nevertheless it's wrong, it looks bad, and we shouldn't have it propagating throughout Wikipedia. 86.177.105.189 (talk) 15:00, 14 February 2012 (UTC)
The problem is that that's not a semantically marked-up, nor accessible, list. That's why we have hlist in the first place; as discussed above and in the archives. And those are compelling arguments. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:25, 25 February 2012 (UTC)
This has been discussed before; on this page or an archive of it. As Edokter has said, it's a limitation of the whole system, and it was agreed to allow it. The proper use of list structure is important for wp:accessibility and page scraping. Sure you weren't the IPs in those talks? Alarbus (talk) 15:07, 14 February 2012 (UTC)
Don't be a pest about it. Alarbus (talk) 15:13, 14 February 2012 (UTC)
I remember some discussion about the navboxes not working in IE, but I have not previously discussed, nor even been aware of, this particular spacing issue. By the way, your use of "pest" is unnecessary and not appreciated. A change was made that spectacularly broke the layout in some versions of IE. Lots of people complained, and rightly so. 86.177.105.189 (talk) 18:21, 14 February 2012 (UTC)
It looks awful however, and even worse when a bracket is left on a different line to the text within as happens quite often. I agree with the IP, this is a significant drawback of the move to the new format. It would be helpful if possible solutions could be discussed, rather than simply trying to close down discussion of a real issue. Rangoon11 (talk) 16:54, 14 February 2012 (UTC)
I should add that, in my view at least, the brackets being larger than the bracketed text is also visually clumsy. Is that a connected issue? Rangoon11 (talk) 16:56, 14 February 2012 (UTC)
you can always just use commas to delimit the list, like this (item1, item2, item3). Frietjes (talk) 17:38, 14 February 2012 (UTC)
Brackets are regular brackets; they are always larger then the text in that they reach from ascender to descender: (hop) — Edokter (talk) — 17:58, 14 February 2012 (UTC)
I am open to suggestions on how to show sublists (different symbols? square brackets? arrows?). Just keep in mind that some interpunct is needed, and that the spacing cannot be changed. — Edokter (talk) — 18:01, 14 February 2012 (UTC)
Apologies I was unclear above in terms of the bracket/text size. I personally much preferred what was the most common approach - although far from universal I concede - pre-hlist, which was for the bracket and text within to both be small size, with no spacing. To give an example, the below template shows subsidiaries of Philips in the new standard format, and percentage ownership of joint ventures in the prior style. It seems that there is no way to present the subsidiaries in the same way as the percentages?Rangoon11 (talk) 18:31, 14 February 2012 (UTC)
Correct; the size of the brackets cannot be controlled. As a sidenote: using smaller fonts inside a navbox is highly discouraged, as it is next to unredable in default fontsizes. — Edokter (talk) — 18:52, 14 February 2012 (UTC)
I agree that small is highly inappropriate. Is that discouragement written up anywhere? It would be a useful edit summary link. Perhaps a css rule to limit the effect of small in navboxes (and possibly everywhere)? Alarbus (talk) 11:49, 16 February 2012 (UTC)
If small text is an accessibility issue, I would like a reference. WP:ACCESS does not mention it and non of the accessibility standards seem to cover it. ---— Gadget850 (Ed) talk 13:03, 16 February 2012 (UTC)
So would I. If a user has impaired vision they can - and are likely to - use zoom to view pages anyway. Wikipeida has vast amounts of text which is the same size as text in navboxes shown as small. Rangoon11 (talk) 15:06, 16 February 2012 (UTC)
It's not really an accessibility issue, i.e. an issue for a minority. The default text size is too small for everyone and 'small' tags make it absurdly small. This is an issue of low-res displays and hi-res displays. The default size was set when typical displays had much lower resolution. with a modern hi-res display everything is tiny. I typically run 2 or three steps zoomed and my vision is fine. Alarbus (talk) 15:23, 16 February 2012 (UTC)
It's not the default fontsize (88%; 11px at default settings) of navboxes I'm worried about; it is the use of <small> inside navboxes that produces unreadable text (9px), as shown in the example above. I regard anything under 11px illegible, and some people even find that too small. It would be a good idea to make a note in WP:ACCESS about font sizes. — Edokter (talk) — 15:26, 16 February 2012 (UTC)
I agree. When accessibility is brought up regarding font size, I would like a source. ---— Gadget850 (Ed) talk 15:30, 16 February 2012 (UTC)
I agree that it's all the worse in navboxes; time to add a css rule to inherit the font size for small tags in navboxes; just make it so. Alarbus (talk) 16:09, 16 February 2012 (UTC)
I strongly oppose such a move and see no justification in policy. You say 'The default text size is too small for everyone'. No it is not, and you don't speak for the 7+ billion people in the world. Text defined as small in a navbox is around the same size as a great deal of other text used in WP, and larger than much (for example the wording 'Briefly describe the changes you have made' and 'If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here.... ') which is currently on my screen. Rangoon11 (talk) 19:38, 16 February 2012 (UTC)
Here is a proposal for a new guideline that does object to small text and says that Wikipedia's font size is already too small ("Reducing text size (for example, to 75%) causes usability and accessibility issues"). De728631 (talk) 18:13, 26 February 2012 (UTC)

Since some people do not like the space before and after the parenthesis causing potential line breaks, I thought I would suggest using a non-breaking space or adding style to it to force the whitespace to not break at that point. I am not sure how well that would work or lack thereof as the list delimiters are stuffed between the HTML list markup via CSS. I hope this helps. 50.53.15.51 (talk) 17:02, 8 March 2012 (UTC)

Capital V, T, E

Has a change been made to capital letters for V, T, E. It looks - well - wrong. I prefer lower case. -- Alan Liefting (talk - contribs) 20:36, 24 February 2012 (UTC)

the change was made in {{navbar}}, you may want to complain there as well. I agree that the lower case is better, but I don't feel that strongly about it. Frietjes (talk) 21:03, 24 February 2012 (UTC)
see Wikipedia:Village pump (proposals)#Changing the "d" to "t" in templates. Frietjes (talk) 21:04, 24 February 2012 (UTC)
I can't find that discussion...is there an updated link available? 71.197.244.119 (talk) 07:49, 8 March 2012 (UTC)
Discussion now in VP (proposals) Archive 85. -DePiep (talk) 09:40, 8 March 2012 (UTC)
You can add the following to your own css page to make it lowercase again. -- WOSlinker (talk) 21:26, 24 February 2012 (UTC)
.navbar.mini li span { font-variant: normal; }
I also prefer the lowercase. Beyond My Ken (talk) 05:58, 27 February 2012 (UTC)
Make a proposal on WP:VPR to reverse the change (I would support it). — Edokter (talk) — 17:36, 27 February 2012 (UTC)
Me too. Moi aussi. Ich auch.
This article is still using v • d • e in its descriptions. Varlaam (talk) 17:24, 2 March 2012 (UTC)
Seems pretty unanimous... Rich Farmbrough, 09:33, 5 March 2012 (UTC).
I actually prefer the caps in this case, solely due to them providing a larger target for the mouse to click. 71.197.244.119 (talk) 07:49, 8 March 2012 (UTC)
If this ends up at VP Proposals, I'll add this: get rid of the T and E links alltogether in mainspace. It is for editors (main argument: "I'm lazy"), only template-involved editors at that, and what we do not do with anything else on a reader page. Not even that, also abbreviations are used. I think this is the only editors-only-jargon on an article page. And having to discuss fonts by the pixel is a bad route anyway.
And on top of this, I'll propose the next functional change: when "edit" (not e or E) is present on an article page template, it means and should do: open the template for editing as it is used on that page. Like we can Edit sections (ah, would't that be nice for reference templates too?). Now let's see which editors can stand a change. -DePiep (talk) 10:02, 8 March 2012 (UTC)
I can. Good call. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:36, 8 March 2012 (UTC)
With my final sentence, I just meant to poke the "lazy" editors of course. -DePiep (talk) 13:50, 8 March 2012 (UTC)

I also think the uppercase letters are too attention-grabbing. The lowercase worked much better, though we might also be able to reduce the font size to achieve a similar effect. Maybe. As for the edit links in article-space, I don't see much alternative. The minor confusion it might cause for non-editors is far outweighed by the convenience of editors; without the link, finding and editing the template is a multi-step process. Powers T 13:03, 9 March 2012 (UTC)

As for the "finding": that is what the remaining "view" link keeps doing. And yes, start editing or talking a different page than the page you are on, is "multi-step". As with every wikilink on a page. -DePiep (talk) 13:54, 9 March 2012 (UTC)
Well if you keep the V link, I don't see what's wrong with the E link. We already have edit links on each section heading, having an edit link on templates is little different. Powers T 20:00, 9 March 2012 (UTC)
The "e/E" link does not open the template as it is used on the page (while the Section [Edit] does). -DePiep (talk) 22:40, 9 March 2012 (UTC)
I don't see a distinction here. Just as parameters might be coded into the template code that affect what appears on the screen, so too can templates be coded into a section that affect what appears on the screen; in neither case can the data be edited directly. Powers T 19:14, 10 March 2012 (UTC)

I've searched the Talk archives and the Help files to no avail, so I'm hoping someone here can help... I've recently created the navbox {{Knots}}, to tie together (pun intended) articles on specific knots. However, articles with the template transcluded onto them (so far, that's only Adjustable bend and Albright special) now appear on the "What links here" list for all articles in the template. I've been asked if it's possible to prevent this from happening - as far as I can tell, it isn't, but this is the first time I've created a template and I'm very inexperienced with the markup elements used. Does anyone know of a way to prevent articles with a navbox template from showing up in the WLH list of every article in the navbox? Yunshui 雲‍水 09:13, 1 March 2012 (UTC)

No, because, er, they all now link to each other. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:54, 1 March 2012 (UTC)
It's an annoying noise feature of navboxes. Others include polluting the rankings for "most wanted articles". Rich Farmbrough, 09:32, 5 March 2012 (UTC).
Exemplifying why it's important to keep the number of navigation templates on an article to a minimum. Powers T 19:17, 10 March 2012 (UTC)

Maxed out?

This edit appears to have caused the 2011 winners not to display. They're the 21st group; I'm guessing there's a 20-group limit. Is there a work-around? The issue will affect more such navboxes, as the years progress. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:38, 26 March 2012 (UTC)

Simple, just add another Navbox subgroup. -- WOSlinker (talk) 21:45, 26 March 2012 (UTC)
See "Please read before posting" at the top. IMO most navboxes that hit the limit of 20 are probably much too large anyway. It's better to present the information in a more condensed form or direct readers to a list or article instead. The template you used as an example 1) has way too much wasted whitespace on my screen and 2) will become totally unmanageable in 1 or 2 decades even if {{navbox}} supported the additional rows. —Ruud 21:46, 26 March 2012 (UTC)

Overriding the state

Someone recently created a new navbox, Template:WikiProject Albums navbox. When used on some pages it's initially expanded, but on some other pages it starts out collapsed. I believe this is because a navbox defaults to state=autocollapsed, and the pages where it starts out collapsed have other collapsible tables. But I thought I could override that in an individual article by specifying state=uncollapsed when I use the navbox. I tried this at Wikipedia:WikiProject Albums/Album article style guide, but the navbox still starts out collapsed. What am I doing wrong? I tried changing the navbox itself to say state=autocollapsed, instead of letting it default to that, but, perhaps unsurprisingly, that didn't seem to make any difference. Thanks in advance for any help. P.S. If it makes any difference, I'm using Windows 7 and Firefox 11. — Mudwater (Talk) 02:07, 29 March 2012 (UTC)

You need to pass the parameter through to the child template. See my edit there. --Izno (talk) 04:25, 29 March 2012 (UTC)
Excellent. Thanks! — Mudwater (Talk) 09:23, 29 March 2012 (UTC)

Is it possible to change the color of the hyperlinks in the title without having to resort to a span tag? TheBigJagielka (talk) 17:00, 9 March 2012 (UTC)

No. — Edokter (talk) — 17:28, 9 March 2012 (UTC)
Adding: even worse. In this, <span> only works outside of wikilinks. Example: {{New York Yankees}} (white font on black bg). When using <span> like: |title=&lt;span style="color:white&gt;[[New York Yankees]]&lt;/span&gt;, the color is not as intended (see sandbox [1]). However, since the template uses |title=&lt;font color=white"&gt;[[New York Yankees]]&lt;/font&gt;, the desired color is present, both in wikilink as in selflink situations. Note: shouldn't this be in the documentation somehow, near "titlestyle" and "groupstyle"? -DePiep (talk) 10:14, 19 April 2012 (UTC) Put on hold. Needs more research. -DePiep (talk) 13:27, 19 April 2012 (UTC)

Converting

Hello. Is it possible to re-create this template for other Wikipedias? E.g. the German Wikipedia, this template would be very useful. Because this is a very complex template, I'm really not able to do it by myself. – weltforce™ | ☣ Talk 12:35, 2 May 2012 (UTC)

Please see the message box at the top of the page. ---— Gadget850 (Ed) talk 14:14, 2 May 2012 (UTC)

I copied the Navbox and Navbar now into a German Wikipedia's sandbox and linked Navbar correctly to Navbox. But when I test the template, no navbox is coming up. Maybe class="navbox-group" is missing? Is is able to copy it? Thanks in advance – weltforce™ | ☣ Talk 16:09, 6 May 2012 (UTC)

You will probably need to either (1) add the classes in en:MediaWiki:Common.css to de:MediaWiki:Common.css, (2) translate the class names, or (3) change the class statements to the equivalent style statements. Plastikspork ―Œ(talk) 17:33, 6 May 2012 (UTC)

Thanks a lot! Now working correctly. – weltforce™ | ☣ Talk 10:21, 7 May 2012 (UTC)

hlist and footnote groups

When bodyclass=hlist, the cite link labels do not work:

Markup Renders as 
{{Navbox
| name= name
| group1 = Group1
| list1  = <ref group=lower-alpha>reference</ref>
| belowclass =
| below = {{reflist|group=lower-alpha}}}}
 
{{Navbox
| name= name
| bodyclass = hlist
| group1 = Group1
| list1  = <ref group=lower-alpha>reference2</ref>
| belowclass =
| below = {{reflist|group=lower-alpha}}}}

---— Gadget850 (Ed) talk 22:45, 11 May 2012 (UTC)

It's somewhat puzzling to me why someone would have references in a navbox. What's the specific use case? --Izno (talk) 23:12, 11 May 2012 (UTC)
re Izno. In templates I prefer to contain refs both in text and footnote (that is: the template be self-containing). When I write a template, I can never be sure there is a reference tag or template in the receiving article. That is why, and it is a pity you (Izno) are puzzled about that. -DePiep (talk) 23:22, 11 May 2012 (UTC)
A pity? I was just looking for the use case. Personally, I don't see why one should need to leave references in a navigation box. The box's perceived use should be such that any links in it are obviously linked to the article in which the navbox is present. Is that not the case when you find yourself using references, and is it desirable if that is not the case? I would say that, no, it is not desirable. Your opinion seems to differ. --Izno (talk) 02:38, 12 May 2012 (UTC)
A real (rather than hypothetical) example would be useful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:07, 12 May 2012 (UTC)
listclass = hlist will work. The reason is that the references are a list as well, so can't use the hlist class. -- WOSlinker (talk) 06:43, 12 May 2012 (UTC)
I was trying to update an infobox that used some vintage reference markup. Since the styling did not work, I did not commit the edit and now I can't find it again. Regardless, I added this issue to WP:CITELABEL. ---— Gadget850 (Ed) talk 12:24, 12 May 2012 (UTC)

Among interlinks, you should add it:Template:Navbox generic.--Mauro Tozzi (talk) 07:57, 5 June 2012 (UTC)

hlist

Hello! I wonder how the feature "hlist" works. If I'm not wrong, "hlist" converts lists like this 

* List1
* List2
* List3

into

List1 • List2 • List3

My question is: how does that work? Thanks!--Weltforce (talk) 19:31, 16 June 2012 (UTC)

Cascading Style Sheets ("display: inline" and other). See specifically MediaWiki:Common.css (ctrl + f 'hlist'). --Izno (talk) 20:29, 16 June 2012 (UTC)
Yeah, that would be a solution but is it able to do it with equivalent style statements? --weltforce (talk) 20:34, 16 June 2012 (UTC)
What do you mean by "equivalent style statements"? --Izno (talk) 06:20, 17 June 2012 (UTC)
<div style="..."></div>, which don't need customisation of the .css file. --weltforce (talk) 07:54, 17 June 2012 (UTC)
You wouldn't be able to use wikicode then. It would be something of the sort <ul style="display:inline;"><li style="blahblahblah">...</li><li style="blahblahblah">...</li><li style="blahblahblah">...</li></ul>. Fairly quickly the styling on the li's would bloat the html so much as to be prohibitive. Hence the use of a stylesheet (you should really read up on why stylesheets exist; 'to separate presentation from content' :^). --Izno (talk) 13:49, 17 June 2012 (UTC)

Space between preceding text and top of template

This is a minor style issue but many (well ok I know of three!) editors like to place a blank line between the footer templates and the text above it. Is it feasible to add a bit of code into the template that gives the option of placing a half or full line space above the template? It will give a slight improvement in readability. Mobile devices will have to be treated separately. There has been at least one silly debate and edit war about it. See Talk:Reach for the Sky. If is is technically feasible I will bring it up as a WP:MOS discussion. -- Alan Liefting (talk - contribs) 23:05, 16 June 2012 (UTC)

This is a good idea. Personally I always add a blank space above navboxes as I think it looks far more professional.Rangoon11 (talk) 23:32, 16 June 2012 (UTC)
I would personally not support such a change (though it could be done simply by default in CSS). Programming it would adds any amount of silly and extra complexity to an already complex template for what is, imo, an undesirable effect (and one which was likely undesirable when this meta template was first put together). On top of that, it introduces not a small amount of inconsistency to what I feel is already an unnecessarily flexible [read: inconsistently used] template. --Izno (talk) 06:23, 17 June 2012 (UTC)

Collapsed as default

I'm having difficulty getting a box to be collapsed by default. Is it enough to write "state=collapsed", or is something more needed? SlimVirgin (talk) 21:53, 17 June 2012 (UTC)

Sorry, strike that, I've fixed it. The "state=" parameter was on the template twice, with collapsed the first time and autocollapse the second. SlimVirgin (talk) 22:03, 17 June 2012 (UTC)

Maxed out? (continued)

First read #Maxed out? above

I am ready to add a 21st list, or frankly go up to 30. {{MARepresentatives}} could really use it. A very simple addition to the code which would have no harm. Please advise.—GoldRingChip 12:48, 29 June 2012 (UTC)

I've updated {{MARepresentatives}} to work with 21 groups & also converted it to use the hlist format as well. -- WOSlinker (talk) 12:59, 29 June 2012 (UTC)
Hey. Nicely done! Looks like hlist replaces navbox?—GoldRingChip 13:22, 29 June 2012 (UTC)
Hlist format just changes the • between items into a list format. So in the template code
a • b • c

becomes 

* a
* b
* c

but the output still looks the same. Makes it easier to edit lists, especially if you want to sort them. -- WOSlinker (talk) 14:28, 29 June 2012 (UTC)

Language parameters

For templates like {{MNAC}}, whose title is not in English, it would be useful to have a |title_lang=, to take a two-letter ISO code for the relevant language, with output comparable to |native_name_lang= in {{Infobox person}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:31, 17 July 2012 (UTC)

I would think including a span would be smarter in this case. While a class structure may have a very univeral use in infoboxes, adding a lang paramter is going to be few and far between. --Izno (talk) 22:31, 17 July 2012 (UTC)

Importing to other wikis

Two things here: First, Tidy isn't required if someone wants to import this template to another wiki; I have successfully imported and used {{Navbox}} on several wikis without Tidy, without having to modify the template at all, so the notices stating that Tidy is required should probably be removed (this does not require an admin, and is therefore not part of the edit request; I'm just looking for consensus or caveats that I'm unaware of).

Second (and, I suppose, actually a counterpoint to my first comment =D ), if Navbox is used together with the hlist class on wikis without Tidy, it has some caveats that must be worked around (bugzilla:39066). While I still haven't figured out the wrapping bug (would anyone more familiar with the CSS for Navbox and hlists like to have a crack at that one?), the broken HTML can be fixed by closing tags on the line following the {{{listN}}} markup instead of on the same line, as seen here. This change doesn't have any adverse side effects as far as I can tell, so could it be done here on Wikipedia as well, so other reusers won't have to worry about this? 「ディノ奴千？！」? · ☎ Dinoguy1000 21:45, 6 August 2012 (UTC)

Spacing things in this template can cause unnecessary paragraph tags to show up, so that would be something to double check. The other thing that could be a problem is all of this in context of the family of navbox templates (with columns, subgroup, etc.).

On Tidy, that can be edited via template:navbox/doc per the usual editing process. I've turned off the notice until those other test cases are checked and there's a consensus. --Izno (talk) 23:03, 6 August 2012 (UTC)

You're right, adding the spacing to {{{above}}} (and, therefore, probably also {{{below}}}) causes a paragraph tag to be added, which changes the padding and line-height. I wouldn't be surprised if paragraph tags are also being added to the listN's, but if so, they're not changing anything visually. They also don't seem to affect child navboxes; the first navbox here uses child navboxes to display the subheaders and subsequent groups/lists, with no change in padding or spacing (except the previously noted above. 「ディノ奴千？！」? · ☎ Dinoguy1000 23:17, 6 August 2012 (UTC)
You are right that Tidy is not required for navbox per se, but as you point out, hlist still requires Tidy, at least until the parsing bugs you point out (there are more bugs open abut this) are fixed. See also MediaWiki talk:Common.css#hlist class and infobox wrapping. — Edokter (talk) — 09:13, 16 September 2012 (UTC)

Years after films in navboxes

People keep putting release years in brackets following films in navboxes – an example:

This strikes me as being curious and unnecessary. Dates aren't put after albums, books, etc. in navboxes, so why should this be an exception? I think it would be good if we could come to a consensus on this.

On another note, I also think these group classings are unnecessary, given that there are only six films here, and that it would look neater and simpler without them. Lachlan Foley (talk) 00:34, 16 September 2012 (UTC)

The bracketed years are useful, what would be gained by removing them? The films are generally ordered in date order and not in alpha order also, the year is relevant and when a film is written in text it generally has the years afterwards. Many book templates do also have years included BTW.
I agree that the grouping by decaded in the above example is unnecessary however. Rangoon11 (talk) 00:42, 16 September 2012 (UTC)
I agree. Decades are not needed, but years are OK. ---— Gadget850 (Ed) talk 01:29, 16 September 2012 (UTC)
Ditto Gadget and Rangoon. I'm going to boldly edit the template, and remove the decades. —Quiddity (talk) 03:11, 16 September 2012 (UTC)
This has been discussed a few times at WP:FILM. There has been no consensus reached and it's been quite infected at times. Here is one discussion I participated in: Wikipedia_talk:WikiProject_Film/Archive_35#Director_navigation_templates. In short, I agree completely with Lachlan Foley. Smetanahue (talk) 22:01, 22 September 2012 (UTC)

Query re template width

Does anyone know why this template is expanding beyond the width of the page? Thanks.Rangoon11 (talk) 18:26, 21 September 2012 (UTC)

It looks fine for me. But, I know of other pages which have had layout problems, including (but not limited to) overwide navbox templates, see Wikipedia:Village pump (technical)/Archive 103#NAVBOXes extending far to the right of the browser window. These are usually caused by a fault in the HTML Tidy feature of MediaWiki.
If the navbox still shows the problem, I would like you to check something. Go to the page where the problem shows, and use the "View page source" feature of your browser - usually obtained by right-clicking on some plain text and selecting "View source" or "View page source" (or similar) from the menu. In the resultant page, which will look like hundreds of lines of computer code, go to the very bottom, where you should find something like this -
<!-- Served by mw28 in 0.137 secs. --></body></html>
possibly split over two or three lines. Please copy all the text from "Served by" up to "secs.", and paste it below. Then I can add the relevant server code to the bug report at bugzilla:38273. Thanks. --Redrose64 (talk) 18:53, 21 September 2012 (UTC)
It's rather odd that IE9 didn't wrap properly if all the list items began with an image. This edit seems to have fix it for me. Is it working for you? -- WOSlinker (talk) 18:55, 21 September 2012 (UTC)
Yes its working fine for me now. Thanks for both your replies and for that fix, much appreciated. Rangoon11 (talk) 19:04, 21 September 2012 (UTC)
I though I had got rid of that beast! Too bad... Anyway, this is not related to bugzilla:38273, which affects all browsers. This issue only affects IE 8 and 9 (and probably 10), and it happens whenever a) a hlist is embedded in a table, and b) the list items start with an image. Why a non-breaking space fixes it, I don't know. All I know is that this is a an IE bug, and I have no fix for it, short of disabling no-wrap in hlist for IE. — Edokter (talk) — 20:10, 21 September 2012 (UTC)
does the same thing happen with {{flagicon}} or does the <span class="flagicon"> fix it? if so, perhaps we could create something analogous to {{flagicon image}} which would set the height of the image, and wrap it in a span. Frietjes (talk) 17:18, 23 September 2012 (UTC)
It doesn't matter how the image is inserted or how it is encapsulated. Its presence (without the &nbsp;) is enough to trigger the error. — Edokter (talk) — 18:23, 23 September 2012 (UTC)

Validation

With HTML5 enabled, this template now generates two validation errors due to the use of cellspacing . See [2], which is a validation of the sandbox without the doc page (which generates a lot of errors due to other templates). ---— Gadget850 (Ed) talk 12:20, 24 September 2012 (UTC)

On my todo list... — Edokter (talk) — 17:48, 24 September 2012 (UTC)

Bullets separating last item from nothing.

Sorry if this has been brought up, but I just noticed hlist navboxes have an extra, pointless dot after the final item. Now that I've noticed it, I can't unnotice it. I think it might drive me insane. Even if it doesn't, it looks bad. Is there a good reason for it? If not, it should be fixed. Thanks. InedibleHulk (talk) 02:22, 25 October 2012 (UTC)

Which browser? If you are using Internet Explorer, make sure you don't have javascript disabled. See MediaWiki talk:Common.css#Trailing bullets with hlist. Thanks! Plastikspork ―Œ(talk) 04:01, 25 October 2012 (UTC)
Playstation 3, the undisputed king of irritating incompatibilities. I almost always disable Javascript, but enabling it doesn't help in this case. Thanks, anyway. It's already becoming less annoying; my sanity is probably safe for now. InedibleHulk (talk) 18:54, 25 October 2012 (UTC)

Table in a navbox

I could ask a long, complicated question about this, but it would be simpler to ask whether what I am trying to do at User:Rrius/Userboxes can work. -Rrius (talk) 00:35, 15 November 2012 (UTC)

Template:Collapse will do it better. If you want to do it using T:Navbox, you can, but the catch is probably that you need to do it with html rather than with wiki-text table. Don't quite me that it will work, though. --Izno (talk) 00:51, 15 November 2012 (UTC)
I was using {{Collapse}}, but I wanted a cleaner edit window. Anyway, the html-ing mostly worked, but for some reason a userbox with long link text is causing trouble. On my userpage, there is a userbox with a link whose display text is "fundamental interconnectedness of all things". At the template's page and my userpage, it breaks after "interconnectedness". For some reason, it won't break at all with the html code I've used at the navbox (linked to in my original contribution). Is there some code I can use to let it break either in the table code or in the template style code? -Rrius (talk) 02:29, 15 November 2012 (UTC)
And thanks, by the way. I have been very good at remembering the niceties today, here or IRL. -Rrius (talk) 02:32, 15 November 2012 (UTC)
If it helps, I tried 
<td style="width: 238px;">
(the width specified in the userbox's code), and it didn't work. -Rrius (talk) 02:36, 15 November 2012 (UTC)

Groupstyle

Is there any special way to set the groupstyle? Please see the recent edit history of Template:Middle-earth films where the group boxes did not accept the intended background colour. I've also experienced this problem last night when playing around with {{Authority control}} in my user sandbox. It seems that contrary to what the documentation tells us, |groupstyle = background: foo; doesn't work. De728631 (talk) 16:30, 18 November 2012 (UTC)

Groupstyle seems to work fine, but you need to set the groupstyle for the subgroup navbox separately. — Edokter (talk) — 19:30, 18 November 2012 (UTC)
I see, thanks a lot. On another note, does groupstyle accept an if-clause? Yesterday I tried to set a switch for the main group of a navbox like | groupstyle = {{#if|{{{embed|yes}}|background: white;}}} but that didn't work, while I could easily set |listclass that way. De728631 (talk) 20:51, 18 November 2012 (UTC)

Mismatching delimiters all over the place. {{#if:{{{embed|yes}}}|background: white;}}. Alternatively, you may be looking for {{#ifeq:{{{embed|yes}}}|yes|background: white;}}. Not sure.

That said, you should really avoid setting colors per WP:COLOR. (I would tend to argue the more extreme position that styling should not be allowed except widths, and even that only at the navbox level.) --Izno (talk) 20:58, 18 November 2012 (UTC)

Thanks. I've now found a solution that works for me. And in this special case I was trying to make a navbox match the style of another template, hence the changing of colour. De728631 (talk) 00:30, 19 November 2012 (UTC)

What is relation of navbox to navbar and sidebar?

Answers to the above are not explicit on Template:Navbox, although "navbar" appears 6 times in Template:Navbox with the 1st mention saying what a navbar parameter does. "See also" is does not say explicitly what the distinction is between navbar and sidebar either or what the respective links do. IMO they should be worked into a separate an earlier section, not concealed in "See also". Thanks. --Thomasmeeks (talk) 03:30, 8 December 2012 (UTC)

What exactly are you looking for? Is it not obvious what the other two templates are simply from browsing to them? We should seek not to duplicate description here where a link will do... --Izno (talk) 18:28, 9 December 2012 (UTC)
I've amended my last sentence above for clarity. A link to WP:NAVBOX link for 'navbar' would help. But the terms are so close-sounding that a several-word gloss would help, esp. for a term used repeatedly (per above) and easily confused with the more general usage of "navigation bar". Thank you. --Thomasmeeks (talk) 21:00, 9 December 2012 (UTC)
OK, a blind alley I now see. Sorry about that. I'll delete this section in a day (unless otherwise advised) so that no one else will be distracted by this section. --Thomasmeeks (talk) 16:19, 10 December 2012 (UTC)
Per WP:TPG, you should not usually delete comments made on a talk page. --Izno (talk) 16:46, 10 December 2012 (UTC)
OK. I now see that if I had come up with a useful Edit per above, I could have done so, not at Admin-only Template:Navbox, but at Template:Navbox/doc. One side benefit of this exchange was stumbling across Template:Sidebar/doc. I put both these links in WP:NAVBOX. So, possibly not a total waste of time after all. --Thomasmeeks (talk) 22:02, 10 December 2012 (UTC)

height:2px blank rows

I noticed that this template creates 2px height blank rows to create gaps between the rows. this works, in most cases, but I have noticed a quirk, if you compare the following:

if you look, the second version has a spurious 2px gap at the top of the subgroups. of course, the easy solution for this is to simply not use high numbered group/list values without the low numbered ones. however, if you do DePiep will quickly revert your changes. so, it appears the only solution is to change this template. it would be nice to have the padding set using style statements, rather than blank rows, but I understand this is difficult to do with CSS (see, e.g., this thread)? I understand that we want to avoid introducing a bunch of new #if statements like we have for the first couple rows. any ideas? Frietjes (talk) 17:22, 23 December 2012 (UTC)

Strange, Frietjes: you solved it two days earlier nicely, using correct settings [3] (note the evenodd = swap), but today here you do not mention that and you propose to change the navbox template? -DePiep (talk) 19:28, 23 December 2012 (UTC)
it's quite clear why I proposed a change since you appeared unwilling to have the numbering start at 1. Frietjes (talk) 17:27, 24 December 2012 (UTC)
Frietjes, another personal judgement, not clarifying to the issue. While below, but earlier, I described what really went on,and why. -DePiep (talk) 08:14, 26 December 2012 (UTC)
yet another "interesting but not needed" comment. Frietjes (talk) 16:23, 26 December 2012 (UTC)
Sure, a reference to another one of your non-substantial personal remarks you think not needed. -DePiep (talk) 01:11, 27 December 2012 (UTC)
Note: appearantly I just self reverted {{Suez Canal}} in this [4]; that is a recognotion of Frietjes' comment here (I mixed it up with that other template I'm working on, {{Panama Canal}} -- more on that below).
1. The gap Frietjes mentions is visual. The edit I reverted "quickly" (what is wrong with being quick btw?), did not refer to the visual thing: to me it looked like an internal renumbering of a navbox (a "gap" in numbers only).
2. So the visible gap appears when a (sub-)template does not start with #1: group1=... | list1=....
3. So the correct thing is: start every (sub-)template with group1.
4. BUT: the numbering cannot be maintained everywhere, because the even/odd numbering determins the bg color: odds are grey. It should alternate over the navbox, whether sub or not, to keep visual legibility.
5. Now this is when the problem arises: if a sub-navbox follows an 'odd group (1, 3, ...), it should start with an even group (2, 4, ...) to get the grey bg color.
6. example: Frietjes' numbering (always start with group1} going wrong
7. Solution: subnavbox can start with "group1" and use option "alternate bg colors". IIRC, this option exists (I did not research for now).
-DePiep (talk) 18:14, 23 December 2012 (UTC)
The rule of thumb is to use proper group/list numbering to prevent these gap glitches. But Navbox does allow some leeway; you may safely start with group2/list2 to correct the odd/even striping (group2 does check for content before applying the empty row). — Edokter (talk) — 18:19, 23 December 2012 (UTC)
right, which is why I said the "first couple rows". so, is it still the case that this gap cannot be easily produced using css, and empty rows is the only solution? Frietjes (talk) 18:35, 23 December 2012 (UTC)
I've tried generating the gap between rows using CSS, but that makes it impossible for nested navboxes to exists. Such is the nature of tables. So they are a necessary evil. — Edokter (talk) — 18:37, 23 December 2012 (UTC)
And next to starting with the second row, there is also the option | evenodd = swap. — Edokter (talk) — 18:38, 23 December 2012 (UTC)
(edit conflict)To me, Edokter describes the better solution: start subnavbox with either group1 or group2 (not group11 as I did).
1. The option to switch bg grey/transparent is in the navbox documentation saying (by CSS style). Default:
oddstyle = background: transparent
evenstyle = background: #f7f7f7;
[...and in the editconflict Edokter already described the option better ... once again ;-) ]
One can alter (switch) these two settings (more elaborate than Edokter's point, but hey it exists and is consistent).
Oops, I promised to mention: {{Panama Canal}} has or had these even/odd issues.
Al fine. Adjust documentation? -DePiep (talk) 18:56, 23 December 2012 (UTC)
The evenodd parameter is already well documented. — Preceding unsigned comment added by Edokter (talk • contribs) 19:53, 23 December 2012‎
Yes. But not the advice/solution to start with "group1" or "group2" always. -DePiep (talk) 20:24, 23 December 2012 (UTC)
I fail to see why it is necessary to do that - there are twenty pairs of |groupn=|listn= and none of these pairs are mandatory; nor is it required to use consecutive numbers (I have constructed navboxes that used rows 1-6 and 11-14, because the groupings fell into two distinct categories). I also fail to see why you would need to mess around with |oddstyle=|evenstyle= when we have |evenodd=swap. --Redrose64 (talk) 21:49, 23 December 2012 (UTC)
1. why ... mess around with |oddstyle=|evenstyle= - I agree. I just mentioned it to show the option, and I already noted that others had pointed to a better option. Still, it is a correct coding, documented and CSS & template consistent.
2. So you fail to see why to use the mandatory pairs: |groupn=|listn=. I cannot help or correct your failing. Edokter has explained and demonstrated, in this thread, that using "group1" or "group2" solves the issue of: BOTH alternating grey/transparent bg AND prevent top padding 2px (gap).
3. Really, Redrose64 is a serious editor, so I think this is an occasional sideway. -DePiep (talk) 22:27, 23 December 2012 (UTC)
No, you misunderstand. When I put "I fail to see why it is necessary to do that", I was referring to the comment immediately above 'But not the advice/solution to start with "group1" or "group2" always'. My point is this: why should advice be offered when it does not matter where the sequence starts? --Redrose64 (talk) 22:52, 23 December 2012 (UTC)
As I understand it: only starting a sub navbox with group1 or group2 prevents the 2px gap appearing. First group in a (sub)navbox template group3 or higher does introduce the 2px gap. Using n=1 or n=2 also allows steering the even/odd (transparent/grey) bg. All fine. So, acrtually it does matter where the sequence starts (1 and 2 good, 3 and up bad). That is what this thread is about. Other remarks (e.g. about setting a bg color) are illustratative or alternatives, interesting but not needed. -DePiep (talk) 23:05, 23 December 2012 (UTC)

Please take a look at Wikipedia:Village pump (technical)#Navboxes and touch devices. Thanks, — This, that, and the other (talk) 09:28, 2 January 2013 (UTC)

a fork

Can someone help fix {{Yugoslavia timeline}} so that it actually supports a {{collapsible option}}? I tried the basic conversion, put all the content in navbox list1, but I get nothing rendered that way. See Template:Yugoslavia timeline/sandbox. --Joy [shallot] (talk) 10:28, 6 January 2013 (UTC)

 Done with this -- WOSlinker (talk) 12:29, 6 January 2013 (UTC)
Is it possible to unfork it further? --Joy [shallot] (talk) 13:37, 6 January 2013 (UTC)
Could use the navbox template but then would also need to change the wiki table into a html table, so not sure if it's worth doing. -- WOSlinker (talk) 15:18, 6 January 2013 (UTC)
That template is a monstrosity. The only way to fix it would be to delete it or strip it down to the actually important links. Navboxes are supposed to a summary of see also type links, not whole graphical schemes... --Izno (talk) 01:52, 7 January 2013 (UTC)
...and it just got rewritten once again, with more intricate table syntax :) --Joy [shallot] (talk) 10:14, 8 January 2013 (UTC)
  • I was keen to strip it down (at least, insofar as moving all the small text to footnotes) but this didn't meet with approval. 10:56, 8 January 2013 (UTC)
PS I don't understand this "fork" business..? CsDix (talk) 10:57, 8 January 2013 (UTC)
Presumably the template equivalent of a content fork - an existing template doesn't do exactly what is required, so instead of amending it so that it does, a second template is created as a variant of the first. Forked templates don't usually survive long at WP:TFD. --Redrose64 (talk) 20:07, 8 January 2013 (UTC)
Cf. fork (software development). --Joy [shallot] (talk) 20:29, 8 January 2013 (UTC)
  • Oh, I see, I think... except I'd say a sandbox seems more like a side-plate than a fork (and perhaps WP:TFD is where a fork goes to meet a knife?). Thanks, CsDix (talk) 09:48, 9 January 2013 (UTC)
No, the relationship between {{navbox}} and {{Yugoslavia timeline}} is that the latter is a fork of the former. --Joy [shallot] (talk) 14:44, 9 January 2013 (UTC)

Edit request on 13 February 2013

Please replace the following line of the template's code (line 8) 

 --><table cellspacing="0" class="nowraplinks {{{bodyclass|}}} {{#if:{{{title|}}}|{{#switch:{{{state|}}}|<!--

... with ... 

 --><table cellspacing="0" class="nowraplinks {{{bodyclass|{{{class|}}}}}} {{#if:{{{title|}}}|{{#switch:{{{state|}}}|<!--

... in order to provide the alterative name class for the bodyclass parameter (complementing the style/bodystyle parameter; and as implemented in the Sidebar templates).

CsDix (talk) 13:44, 13 February 2013 (UTC)

What are the supposed advanatges of this change? How would the new parameter be used? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 13 February 2013 (UTC)
In the same way as style is already offered here as an alternative to bodystyle and class/bodyclass is already in use in Sidebars. Apologies if the above didn't make that sufficiently clear. CsDix (talk) 14:17, 13 February 2013 (UTC)
I still dont see the immediate benefit. Shouldn't the goal be to remove these redundant parameters? — Edokter (talk) — 20:18, 13 February 2013 (UTC)
Okay, forget it – it's nothing major. For the sake of consistency, though, you may wish to remove bodystyle's alternative name (style). CsDix (talk) 22:37, 13 February 2013 (UTC)
PS Incidentally, just to be sure, I'm assuming you mean "redundant parameter names" rather than "redundant parameters"..?
Not done: please establish a consensus for this alteration before using the {{edit protected}} template. --Redrose64 (talk) 21:30, 13 February 2013 (UTC)

Edit request on 25 February 2013

Please replace the line...

--><tr><td class="navbox-abovebelow {{{belowclass|}}}" style="{{{basestyle|}}};{{{belowstyle|}}}" <!--

...near the end of the code (in the "---Below---" section) with...

--><tr><td class="{{#ifeq:{{{belowclass|}}}|navbox-title | |navbox-abovebelow}} {{{belowclass|}}}" style="{{{basestyle|}}};{{{belowstyle|}}}" <!--

...to allow |belowclass=navbox-title to override the default "navbox-abovebelow" class setting. (I believe – hope – this is simply an omission rather than something that requires consensus harvesting.)

CsDix (talk) 00:57, 25 February 2013 (UTC)

Per WP:TESTCASES this should really be sandboxed and tested first. I've applied your change to Template:Navbox/sandbox, which appears to also have an outstanding change put in there by Edokter about two weeks ago. --Redrose64 (talk) 11:51, 25 February 2013 (UTC)
 Not done. There is never a need to 'override' a class; any style associated with a class followig the base class takes precedence. And it is not a good idead to discard a base style associated with the base class. — Edokter (talk) — 21:20, 25 February 2013 (UTC)
  • "There is never a need to 'override' a class..."
Well, I believe I've found one (otherwise why would I've made the request?). It's to allow the "below" section in the following circum Never mind, I'll try to work something else out. CsDix (talk) 00:10, 26 February 2013 (UTC)

hlist hnum

Using "listclass=hlist hnum", numbered list appears on only list1. Is this an intent function? And if I want to show numbered list for all list2, list3, ..., what should I do? — Preceding unsigned comment added by Nullzero (talk • contribs) 11:55, 24 February 2013 (UTC)

Hnum should work on all lists. The example on your sandbox seems to expose a parser bug, where # is interpreted as an unordered list, but I don't know what's causing it. — Edokter (talk) — 12:32, 24 February 2013 (UTC)
I found the bug. consider the following two examples
  • without newline at the end of html td cell
  1. item 1a
  2. item 2a
  3. item 3a
  • item 1b
  • item 2b
  • item 3b
    • with newline at the end of html td cell
    1. item 1a
    2. item 2a
    3. item 3a
    1. item 1b
    2. item 2b
    3. item 3b
    since our table cells are lined with divs, we may be able to fix it by just inserting a newline before the closing div. Frietjes (talk) 00:41, 26 February 2013 (UTC)
    Interesting. You can remove the hlist and hnum and see the issue with these two simple examples
    In the second example, I added a nowiki at the end of the first list to force the newline between the lists. We should definitely try to fix this. Thanks for finding the bug! Plastikspork ―Œ(talk) 03:15, 26 February 2013 (UTC)
    For reference: bugzilla:40274. — Edokter (talk) — 18:11, 26 February 2013 (UTC)
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Navbox/Archive_16&oldid=1101487131"