Template talk:Navbox

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Template:Navbox page.
Please sign and date your posts by typing four tildes (~~~~). Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Ask questions, get answers.	Be polite Assume good faith No personal attacks Be welcoming
Archives: 1, 2, 3, 4, 5

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 See Template talk:Navbox generic for previous discussion.

About archives

Contents 1 Incorporating improved linewrap handling code 2 Templates with nowrap problems 3 Show / Hide 4 Change Color 5 Defaults for infoboxes under discussion 6 Does anyone know... 7 Template colours 8 Show on specified article 9 Problem with using imageleft option 10 padding for list 11 Standardise navigation templates colours? 12 Title 13 Crash on Firefox 14 Ported to outside Wiki - Problem if no image defined 15 State: has something changed? 16 {{High-use}} insted of {{intricate}} 17 border-left color of th 18 Possible code change? 19 Autocollapse disabled? 20 Requirements To Import To Another Wiki 21 float issue 22 Why is View Discuss Edit on the left, instead of the right? 23 Titlebar problem

[edit] Incorporating improved linewrap handling code

Due to frustrating situations such as this (point 2) and this, I'd incorporate a nowrap = on parameter in this template (well, its /core) that would frame each list with a the code from the {{nowrap begin}} and {{nowrap end}} templates. Unfortunately, however, I'm only able to view the source code, so would somebody with access please make this amendment. Thank you! Sardanaphalus (talk) 05:35, 25 March 2008 (UTC)

Hi Sardanaphalus. As you might know I am the one who coded the {{nowraplinks}} template + class that is used inside {{navbox}} which fixes most of the wrapping problems in the lists inside the navboxes. And then I coded the {{nowrap begin}} for those cases where {{nowraplinks}} failed. That is, to handle the Firefox expand outside the box bug.

1: I think I disagree with your suggestion that {{nowrap begin}} should be added as default in {{navbox}}, since {{nowrap begin}} is only needed in some lists. Although I can see the advantage of forcing people to always use the {{·wrap}} or {{·w}} or one of the other {{?wrap}} templates. (They would be forced to use them, since if they didn't use {{?wrap}} then their lists would not wrap at all.) But I think we then would get a more serious problem: Editors are lazy and if an editor sees that his list fits in the window he might not bother to add wraps in it. Problem is that then it will REALLY flow outside the "box" for those users who read at a lower screen resolution. Much worse than the Firefox bug.

2: I have noticed you are having lengthy arguments with User:Emerson7. I think you both should carefully (re)read Wikipedia:Line break handling.

3: I have noticed you are on a quest to stop people from using <div> tags around lists. I disagree with you on that. (For others that might read this: We use the DIVs so we can put each list item on a separate line in the code.) The DIVs make the lists much easier to see in the code and reduces the human errors a lot. And the DIVs do not interfere with cell backgrounds and text styles etc, the only thing they "cause" is a slightly wider top and bottom margin around the list. By the way, when one uses {{nowrap begin}} and {{nowrap end}} then one doesn't need the DIVs since one can use {{nowrap begin}} and {{nowrap end}} in the same way as the DIVs. (See Wikipedia:Line break handling#nowrap begin for a code example.)

--David Göthberg (talk) 09:07, 25 March 2008 (UTC)

4:And especially for emerson7: Even though I do not recommend that you use {{nowrap}} in lists, but instead use {{nowrap begin}} + {{·w}} etc, here's an advice: The way you do it slightly break it for Firefox users. (Well, you don't break it more than {{nowraplinks}} already does, but you can do it better.) You do like this:

{{nowrap|[[Andrew Grove]] (1997)}}{{·}}

But I suggest you do like this instead:

{{nowrap|[[Andrew Grove]] (1997){{·}}}}

The difference is that the end braces for {{nowrap}} should come after the {{·}}. Then you should not get the Firefox problem. (You of course need some kind of white space after all that, like a space or a new line, or else your list will not wrap.)

But as I said in my previous message, you really should carefully (re)read Wikipedia:Line break handling.

And note, {{nowrap begin}} is not really "esoteric" or "non-standard", internally it uses the same code as {{nowrap}}. It is completely W3C standards compliant and works in all web browsers that can handle {{nowrap}}. (Even works in my old MS Internet Explorer from 2001 that I use for compatibility testing.)

--David Göthberg (talk) 09:38, 25 March 2008 (UTC)

• Thanks for your counsel, David, and the time it must've taken to compile. Having reread Wikipedia:Line break handling, the key statement still seems to me to be "Thus {{nowrap begin}} + {{·wrap}} + {{nowrap end}} can (and should) be used on lines in the standard navboxes that fail due to the nowraplinks problems.", coming right at the end, like a climax. It's saying to me that 'if you want to avoid the problems outlined above, use {{nowrap begin}} + {{·w}} + {{nowrap end}}'. Hence my using it for template lists and encouraging emerson7 to do the same -- or at least not undo it.

Hence also my suggestion that the {{nowrap begin}} and {{nowrap end}} code be incorporated in the Navbox template, but as an optional switch ("nowrap = on"). Editors who aren't already aware of what "nowrap = on" would mean could still create templates that use {{·}} or other dividers without then wondering why they weren't wrapping. Similarly, editors who tried to amend a template already using "nowrap = on" and {{·w}} would see that {{·w}} is the divider to use. I've already seen a few examples of this in templates I've revisited after sorting out their linewrapping.

So, it doesn't sound to me as if you're counseling against the use of {{nowrap begin}} + {{·w}} + {{nowrap end}} or, bearing in mind its optional nature, the possibility of a "nowrap = on" Navbox parameter. Am I misunderstanding something?

Finally, as regards <div>s within templates, I hope you'll be glad to hear that I've already realized this should be no problem, as I pointed out to emerson7 here.

Thanks again for all your input. Sardanaphalus (talk) 10:17, 25 March 2008 (UTC)

• Instead of adding a new optional nowrap parameter to the template, we could just advise users to put in "liststyle = white-space:nowrap;", which would (I think) accomplish the same thing as putting {{nowrap begin}}...{{nowrap end}} around all of the lists. This doesn't fix the DIV issue, but it does eliminate having to retype "nowrap begin" and "nowrap end" for each list. --CapitalR (talk) 13:47, 25 March 2008 (UTC)

Now I am back from my two hour ski tour. We finally did get some decent snow! :))

1: CapitalR: I have not tested it, but I think that using "liststyle = white-space:nowrap;" will cause the entire lists to not wrap at all, even if one inserts {{·w}}. So I don't think that would work.

And here's my long response for Sardanaphalus:

2: No worries, that response didn't take that much time to type up. And this is important stuff since navboxes are so widely used so it is good if we discuss these things thoroughly on this talk page. By the way, {{navbox}} is used on 567000 pages! (CapitalR, you should be proud!)

3: Haha yeah, kind of funny that you use a statement that I wrote "against me". And you are right, there is no disadvantage in "overusing" {{nowrap begin}}. But I don't like your "nowrap = on" suggestion, I think it will be confusing. That would mean that some templates would be using {{nowrap begin}} + {{·w}} + {{nowrap end}} while some would look like they were using only {{·w}}. Now that would be really confusing. Although I am going to contradict myself in a moment. (There is a very simple solution, an ugly one, perhaps too ugly to use. But I am getting to that in a moment.)

4: Here is some funny stats (or perhaps depressing): {{nowrap begin}} is used 37,264 times, but {{nowrap end}} is only used 36,151 times. That means that there is perhaps 1000 "faulty" link lists out there. (Some hundred uses of {{nowrap begin}} is of course when it is mentioned on talk pages like here, but 1113 more sounds a bit much.) But don't worry, see next section.

5: Here comes the ugly solution, or if you will the good news. (I have been thinking for some time now if I should reveal this or not, since this will cause really bad coding habits... But I guess sooner or later others will figure it out anyway.) I tested what happens when one uses {{·w}} without any surrounding {{nowrap begin}} and {{nowrap end}}, but still inside some kind of box like for instance a table cell. That is, I used the "view page source" function in my web browser to look at the XHTML source of the wiki page that MediaWiki outputs. And I tested how it wrapped. Guess what? MediaWiki is so smart that it fixes the problem! It adds the missing </span> tag at the end of the list (at the end of the surrounding box). That is the </span> tag that {{nowrap end}} should have added. And at the first occurrence of {{·w}} it cleans away the </span> tag that is in the beginning of {{·w}}. So the end result is clean XHTML and a perfectly wrapping list that only lacks nowrap protection around the first list item. But the first list item is almost always short enough to never wrap anyway. So the truth is that it doesn't matter if people forget {{nowrap begin}} and {{nowrap end}}. They can use {{·w}} alone. At least in the current version of MediaWiki. So we don't really need the "nowrap = on" option.

But note, I still think that we should use {{nowrap begin}} and {{nowrap end}} for several reasons:

• It is cleaner coding.
• We don't know if future versions of MediaWiki will be as good at fixing the code (although hopefully they won't make MediaWiki less good over time).
• In some cases even the first list item might need nowrap protection.
• {{nowrap begin}} and {{nowrap end}} works as a substitute for the DIV tags so one can put each list item on a separate line, thus greatly reducing human error when editing the list.

Now I guess I have to go into hiding for some days since I know about a zillion coders out there that would DDoS my computer for disclosing this kind of thing and "encouraging bad coding habits". I guess I have to claim "information wants to be free". :))

--David Göthberg (talk) 14:10, 25 March 2008 (UTC)

• Wow, yeah, I was definitely wrong there. I think it's still a little too early in the morning for me to be thinking about this problem. By the way, I'd appreciate comments and suggestions from both of you on my new navbox design, located at User:CapitalR/Navbox with a test page at User:CapitalR/Navbox/test. I worked on this about 6 months ago and left it unfinished, but finally got it in working condition last week, and am hoping to get the CSS and code into the live navbox within the next few weeks. Let me know what you think. --CapitalR (talk) 14:41, 25 March 2008 (UTC)

• Will do. But first:

• Don't worry, David, I won't tell anyone! -- More seriously, your MediaWiki discovery is intriguing. I've just been fiddling around with the {{nowrap begin}} and {{nowrap end}} tags and realized I'd overlooked this way of using them (I'm sure I must've tried this before, but found it not to work -- my mistake?):

v • d • e Navbox name for group 1 An item · Another item · Another item with a longer name · Another item · Yet another item · And another one · They keep coming · Here's another one · Should be linewrapping · by now · hopefully name for group 2 An item · Another item · Another item with a longer name · Another item · Yet another item · And another one · They keep coming · Here's another one · Should be linewrapping · by now · hopefully

emerson7 and I have just been exchanging messages and he seems happy with this simpler format. I just hope there isn't a problem with it lurking somewhere. Meanwhile, those curious stats you uncovered makes me think a bot should be comandeered to find those places without matching pairs of {{nowrap begin}} – {{nowrap end}} templates -- assuming that wouldn't be too great a hassle to set up. Sardanaphalus (talk) 17:16, 25 March 2008 (UTC)

CapitalR: Ah, so you also been on a six month wikibreak? I came back some week ago, mostly to see what happened with the templates I coded last summer. Got stuck answering questions about them (like here) and doing some updates to some of them since we learnt more since then. I'll try to squeeze in some time to look at your new navbox, don't know when though.

Sardanaphalus: I took a look at the code in your example box above, and yes, that is the best way to use {{nowrap begin}}. I have a guess what you might have done to see it "fail". You might have coded like this:

| list2 = {{nowrap begin}}[[item1]]{{·w}}
[[item2]]{{·w}}
[[item3]]{{·w}}
{{nowrap end}}

Just as with DIVs, if you put the first list item on the same line as the "list2 =" then you get an ugly rendering. Instead you should code like one of these two examples:

| list1 = {{nowrap begin}}
[[item1]]{{·w}}
[[item2]]{{·w}}
[[item3]]{{·w}}
{{nowrap end}}

| list2 = 
{{nowrap begin}}
[[item1]]{{·w}}
[[item2]]{{·w}}
[[item3]]{{·w}}
{{nowrap end}}

It doesn't matter if the {{nowrap begin}} is on the same line as the "list2 =" or not. Both works fine.

And I don't think you need to worry about any "lurking unknown problems" with {{nowrap begin}}. We have tested it for six months now, and as I told above it even mostly works correctly if you omit one or both of {{nowrap begin}} and {{nowrap end}}. There actually is one known problem with {{·w}}, as the "technical details" section in the docs at {{nowrap end}} says:

The {{·wrap}} causes problems if inside sections of bolded and/or italicised text. Do end the bold text before the {{·wrap}} and continue the bold text after it to avoid the problems. {{•wrap}} and the other helper templates only have this problem if the section is bolded and italicised at the same time.

You can see examples of what happens at Template talk:Nowrap begin#Testing with bold and italics.

By the way, I have recently come to a conclusion: Some of the templates I work with are used in so many places that the number of human editors that use them must be big. Thus it is important to document them properly, since we will never be able to talk with all the editors or correct their erroneous usage. And we need to show good examples on other pages. (I call that "marketing".) Like we should perhaps show {{nowrap begin}} usage in some of the examples in the documentation here at {{navbox}}? The reason I wrote Wikipedia:Line break handling and linked it from all relevant pages was exactly that, to spread the knowledge in a more efficient way. (As you might have seen, CapitalR wrote very nice documentation for {{navbox}}.) What I mean is that it is more important to add such examples here at the {{navbox}} than to actually fix the current errors out there in the templates. Since people will keep adding this to more and more templates in the future, faster than we can correct their errors.

And about using bots to clean up {{nowrap begin}} usage: I just checked, {{nowrap begin}} is currently "only" used in 1260 templates. (The much higher number of pages that use it is probably mostly due to those templates being on so many pages. Of course, there might also be pages that use them directly.) And {{·w}} etc is used in a similar number of templates. (Was a bit harder to count since there are several helper templates and the short names redirect to the longer names thus messing up the "what links here" list.) It would be a pretty easy thing to get those "what links here" lists (cut and paste), sort them etc and compare them to see which templates use one of the helper templates but totally lacks {{nowrap begin}} or {{nowrap end}}. Of course, that doesn't give us the cases where they are used in some weird way. For that a bot is needed, or manually checking the 1300 or so templates. I have never used any "Wikipedia bots" so I don't know how well they can be programmed. You'll have to ask around among the bot owners.

--David Göthberg (talk) 20:05, 25 March 2008 (UTC)

Couldn't help myself. I compiled a list of the templates with obvious nowrap problems. See next section. --David Göthberg (talk) 07:39, 26 March 2008 (UTC)

[edit] Templates with nowrap problems

I have compiled a list of templates with obvious nowrap problems. (Mostly navboxes.) There are 228 templates in the list. Anyone that is in the mood is welcome to help out to fix them. See the list and read all about it at: List of templates with nowrap problems. That is in no way a complete list of the navboxes with nowrap problems, but those were the easiest to detect. They are likely to be the worst cases. If we fix those ones then other editors might learn from what they see.

--David Göthberg (talk) 07:39, 26 March 2008 (UTC)

[edit] Show / Hide

I want to simply have this [show] / [hide] function working but the template structure is too complicated. I cannot find the code that enables it. :( can somebody help me out? --Subfader (talk) 17:44, 26 March 2008 (UTC)

The show/hide function depends in CSS and javascript found in MediaWiki:Common.css (.navbox class) and MediaWiki:Common.js respectively. — Edokter • Talk • 18:04, 26 March 2008 (UTC)

ALso see http://meta.wikimedia.org/wiki/Help:Collapsing for the USA Today version for us slow people. Mikebar (talk) 13:29, 20 May 2008 (UTC)

[edit] Change Color

how can I change the Navbox color, you know how it's kinda purple how do I change it to ...say for example blue? —Preceding unsigned comment added by Markreidyhp (talk • contribs) 11:27, 30 March 2008 (UTC)

You can use titlestyle= and groupstyle=; see the documentation on the template page. — Edokter • Talk • 12:41, 30 March 2008 (UTC)

[edit] Defaults for infoboxes under discussion

A while back I reforged {{infobox}} in this template's image, and now that it's starting to see more widespread usage there's a discussion underway about what default styling should be used. I set the original defaults based directly off of the default styles used here in Navbox, since I presume they've undergone a very extensive debate and because I personally find them quite useful. However, there are a couple of editors who've requested that the default infobox to be colorless. I'm not deeply wedded to the current style but at the same time I'm reluctant to change it based on just a few people's requests so I'm canvassing here to see if anyone with more experience in interface usability and such would be willing to pop over to Template talk:Infobox to give some input. Bryan Derksen (talk) 16:45, 1 April 2008 (UTC)

[edit] Does anyone know...

Does anyone know why recently the text in "group" of Template:Navbox becomes smaller in appearance in some computers? --59.149.32.77 (talk) 23:06, 2 April 2008 (UTC)

New CSS code has been introduced in preparation for the new navbox code. This may cause some temporary font-size discrepancies due to caching latencies, which should ultimately correct itself after the navbox code goes live. — Edokter • Talk • 23:10, 2 April 2008 (UTC)

Thank you very much for your answering. I WAS worrying that is a problem of my computer. :) --59.149.32.77 (talk) 23:18, 2 April 2008 (UTC)

[edit] Template colours

Not sure if this is the best place to raise this issue but a certain user has been going around changing [1]all the navboxes to a new style he created apart from putting the wrong images into some of the navboxes he has also changed the main links to black see this template this makes wiki linked pages show as standard text meaning users will not think to click on this, what do other users think of this new style --Barryob (Contribs) (Talk) 17:24, 9 April 2008 (UTC)

Hi I'm the apparant a certain user Barryob feels the need to talk about first of all if you are going to talk about me at least use my name. Secondaly I have never used the wrong image you just don't like my choice of image usage, however both of those two issues are more personnal than related to the actual discussion. The blacking out of the links is as you might have noticed many users have already pointed out (although not on this talk page) is so that you can see the words written. Another discussion is taking place which I suggest Baryob you take part in deciding what bandcolour to use. When that has been decided I am perfectely willing to have all links returend to their normal standard colurs. Electrobe (talk) 14:44, 13 April 2008 (UTC)

This is not a technical problem, but one of style. Since it looks like those templates are under the purview of Wikipedia:WikiProject Caribbean, you should take this discussion to that talk page for a community consensus. --— Gadget850 (Ed) ^talk - 14:50, 13 April 2008 (UTC)

Yes I see we had better take this to a talk page however I don't believe that Carribean woudld be the correct one to take it too as it envolves all Commonweath Realm Pms, All British Goverment Offices and most other posistion in which the Queen has authority. Electrobe (talk) 15:00, 13 April 2008 (UTC)

[edit] Show on specified article

Hi, is there a way to show a template on a specified article when it's with other templates but keep its default state as autocollaped? See the Hong Kong article for an example, I'm trying to get the Hong Kong Topics template in the See also section to be expanded, while the other templates at the bottom of the page are hidden, but keeping the Hong Kong Topics template hidden on other pages it's transcluded onto. I tried something like this on the Hong Kong article but it didn't work:

==See also==
{{Hong Kong Topics|state=show}}

I'm not sure if that feature exists or not. Many thanks --Joowwww (talk) 18:28, 9 April 2008 (UTC)

You were on the right track, but the template itself needed the "state" parameter set up as follows:

|state = {{{state<includeonly>|autocollapse</includeonly>}}}

It works now. Rgrds. --Tombstone (talk) 18:52, 9 April 2008 (UTC)

Ah! Many thanks for that. --Joowwww (talk) 18:56, 9 April 2008 (UTC)

[edit] Problem with using imageleft option

I just saw {{JamaicaPMs}} which uses the imageleft option. The problem is that this image on the left overlaps with text in the box, or at least it does on my browser (currently using IE). Can anyone explain this? 52 Pickup (deal) 15:40, 14 April 2008 (UTC)

Which version of IE? I've tidied up the markup a bit and I can't reproduce this in IE7 or IE8. Chris Cunningham (not at work) - talk 16:24, 14 April 2008 (UTC)

The problem was a |left being used within a table, which causes this know bug in IE(6). Seems to be fixed now. — Edokter • Talk • 18:35, 14 April 2008 (UTC)

Yep, I was using IE6. After the "left" code was removed in this change, it's now fixed. 52 Pickup (deal) 06:30, 15 April 2008 (UTC)

[edit] padding for list

I would like to propose the following change:

• |es = width:100%;font-size:95%;background:#f7f7f7;{{{liststyle|}}}{{{evenstyle|}}}

to

• |es = width:100%;font-size:95%;background:#f7f7f7;padding:0 0.5em;{{{liststyle|}}}{{{evenstyle|}}}

This change provides a extra padding for the lists, making them easy to read. Also, it looks better in my opinion. eDenE 14:18, 17 April 2008 (UTC)

I don't see that much of a difference. In any event; while it may look better for text, other elements in a list, like images, may suffer from this change. — Edokter • Talk • 14:27, 17 April 2008 (UTC)

This change may not be so good for lists starting images as shown beside. However, as long as I checked so far, there aren't any templates like that. Although a better-look is not necessarily a good motive for some changes, I don't see any potential problems with it... eDenE 15:12, 17 April 2008 (UTC)

Default padding is already "1px". As your second example shows, 0.5em padding screws with the horizontal offset of the cell's content. By the way, navbox is about to be overhauled, so any changes would have a short-term effect. — Edokter • Talk • 15:25, 17 April 2008 (UTC)

Adding list padding won't really work as it would mess up all {{Navbox subgroup}} instances (used by a few hundred templates). The new version of the navbox code will take care of this problem and will add in a default left and right list padding that won't have an effect on the subgroups. --CapitalR (talk) 13:23, 18 April 2008 (UTC)

[edit] Standardise navigation templates colours?

Have a look at this version of Giovanni Trapattoni page, we have red,blue,black,white,purple and green ,basicly a rainbow of of colour here. Is it time to define a standard colour (most likely the pale blue,default colour) for nav boxes?Gnevin (talk) 20:33, 23 April 2008 (UTC)

I don't believe so. Trappatoni is an extreme example of the multicoloured navboxes. I think it's quite appropriate that navboxes for football clubs match the colours of the club. пﮟოьεԻ 57 22:12, 23 April 2008 (UTC)

I've ask this here Wikipedia:Village_pump_(policy)#Standardise navigation templates colours?, i will copy your reply over so we only have one discussion Gnevin (talk) 22:31, 23 April 2008 (UTC)

It gives a clear indication of who he has managed throughout his career. As above it is extreme as he has had such a long and travelled career, seemingly with a number of clubs with equally varied colours.Londo06 17:04, 2 May 2008 (UTC)

[edit] Title

Recent changes seem to have removed the title from {{Politics of Germany by state}} and I'm sure others. Cuold someone look into this please. Thx AndrewRT(Talk) 16:58, 2 May 2008 (UTC)

• All fixed; looks like it was some weird code in {{Germany States topic}}. --CapitalR (talk) 17:13, 2 May 2008 (UTC)

Many thanks!! AndrewRT(Talk) 18:50, 2 May 2008 (UTC)

[edit] Crash on Firefox

http://en.wikipedia.org/wiki/Template:Navbox crashes on FireFox (2.0.0.14). Some pages using Navbox also crash FireFox (for example, the current version of 2008 Stanley Cup Playoffs). (Chinissai (talk) 21:43, 6 May 2008 (UTC))

Not sure what is happening with your FireFox but its definately not crashing mine. -Djsasso (talk) 21:49, 6 May 2008 (UTC)

OK, the problem seems to originate from an add-on called Thai Words Separator. Disable that and crashes gone! Thanks. (Chinissai (talk) 22:22, 6 May 2008 (UTC))

[edit] Ported to outside Wiki - Problem if no image defined

I have ported this template (both Navbox and Navbox/core) to a wiki not accessible from the internet (so this may be a bit difficult to diagnose). The template works fine if the image parameter is defined, but if it is not, the group cell widths are increased to fill up the whole width of the screen minus the list items cell width (which is squeezed to the smallest size possible while still allowing the text to be readable. I used the User:Ned Scott/Navbox/core version to fix some problems that this particular Wiki was showing with the template. I am content for now to just have an image on the Navbox, but if in the future we have something that doesn't need an image, it would be nice not to have to worry about it. If need be I can post some of the coding, but I will have to print it and copy it over long hand since the two networks do not touch and I am in a no removable media environment. Tigey (talk) 17:18, 8 May 2008 (UTC)

Well first, {{Navbox/core}} is now obsolete and is not used by this template anymore, so you don't need to port it. The {{Navbox}} code recently underwent a major revision, so be sure that you're using the most up to date code. Next, be sure you got all of the proper CSS classes for navbox in MediaWiki:Common.css and the collapsible table code from MediaWiki:Common.js (the CSS was recently updated too, so double check you have the newest code). In the CSS file there's about a dozen classes you need to copy (.navbox, .navbox-group, .navbox-title, etc). --CapitalR (talk) 17:21, 8 May 2008 (UTC)

Alright. I have copied over the code from the Navbox template, and added the necessary coding to the Common.css and Common.js files. However it did little to alleviate the problems we have been having with this template. Due to the insane styling screwups that were making the Template:Navbox page difficult to read (some of the output was displayed under the logo area at top left, and the Navigation tools where pushed all the way down to the bottom) I commented out the documentation call at the end so that I could get a handle on what was going on. Currently the Template page is seperated from the tabs at the top and all that displays is "". In a sandbox, I tried the following:

{{Navbox
|Name = Test Name
|title = [[Top Level Page]]
|image = [[Image:125px-picture.jpg]]

|group1 = [[Group 1]]
|list1 = [[List Item 1]] [[List Item 2]]
|group2 = [[Group 2]]
|list2 = [[List Item 3]] [[List Item 4]]

}}

What I go was:

<tr><th style=";" colspan"3" class="navbox-title">
view.talk.edit
Top Level Page</th></tr?,tr style=height:2px;"><td></td></tr><tr><td class="navbox-group" 
style=";;">Group 1</td><td style="text-align:left;border-left:2px solid #fdfdfd; width:100%;padding:0px;;;"
class="navbox-list navbox-odd">
List Item 1 List Item 2</div></td><td style=width:0%;padding:0px 0px 0px 2px;" 
rowspan="3">Image:125px-Picture.jpg</td></tr><tr style=height:2px"><td></td></tr><tr><td 
class = navbox-group" style=";;">Group2</td><td style="text-align:left;border-left:2px solid
#fdfdfd;width:100%;padding:0px;;;" class="navbox-list navbox-even">
List Item 3 List Item 4</div></td></tr>
</td></tr></table>

I figure I am intermediately wiki-savy, so this beats the heck out of me. I am having a hard time following this template, but I would really love to have it's functionality. Any hep would be appreciated. Unfortunately, the Wiki that I am using is not accessible from the Internet. All of the code above was transcribed by hand, so there may be some minor errors in there like missing "<>" or something. Any help would be greatly appreciated. Tigey (talk) 17:36, 12 May 2008 (UTC)

Hmmmm....looks like most of the internal code is working the way it should, except for the first line. Could you get me a screenshot of what the navbox looks like on your wiki (a shot of your entire browser), and another screenshot of the exact (and entire) output code for the whole page? That's probably the only way I'll be able to figure this out from afar. Also, this template depends on {{tnavbar}}, so you should make sure that one is fully up to date (and I believe that it also requires some CSS classes of its own, namely, "plainlinksneverexpand" and possibly others). Oh, and the "name" parameter is all lowercase, not "Name". --CapitalR (talk) 17:58, 12 May 2008 (UTC)

It would also be helpful if you could calculate checksums for the copied material, as they would immediately reveal if you had made a transcription mistake - at least then you would know there was a problem to look for. —Dinoguy1000 19:21, 12 May 2008 (UTC)

Here are a couple of screen captures. Image:IPed Screenshot.png Image:IPed Screenshot2.png Notice the separation from the tabs at the top, and the tendency for the text to run through items like the tNavbar output. On the Screenshot2 image, not the text behind the top/left logo. Unfortunately I have no way to generate checksums on the network to which I am porting this. When I copied over to the wiki that IS on the internet (Same setup) I copied the entirety of the page. Currently for the Navbox Template I have ported directly from Wikipedia/MediaWiki: Template:Navbox, Common.css(Just the navbox styles), Common.js (Just the collapsible table code). I will try porting the TNavbar (we have an older version, but a first look says that it is going to require some work to fix too. Specifically it leaves a after the links, and forces the title of the template on which it is called to be pushed down below the View.Edit.Talk links. Anything you can tell me will be of help. Thanks for your help!Tigey (talk 12:18, 13 May 2008 (UTC)

ZOMG it's the famous CIA wiki! 81.94.106.82 (talk) 19:28, 14 May 2008 (UTC)

It's the tidy problem. There's some option called "tidy" that we have that other installations of MediaWiki don't normally have, and that normally breaks things with templates being copied over. I explained it once on User talk:Ned Scott#Porting Template:Navbox to other wikis, and I've been meaning to make a better explanation on WP:TRAN (which is also starting to list already converted templates, as well as a copy of Commons.css and .js that will work well on other wikis). I'll probably give another stab at this myself tonight. -- Ned Scott 04:40, 14 May 2008 (UTC)

Yeah, I've been working with User:Tigey via email and chat and that's the conclusion we just came to also. Any help with it is greatly appreciated though, since I don't know much about the tidy feature or its configuration. --CapitalR (talk) 06:00, 14 May 2008 (UTC)

Really, what needs to be done is updating this template so that Tidy isn't necessary for proper rendering (and while we're at it, do something about erroneous trailing semicolons in style attributes... and empty style attributes (seriously, look at the source for a navbox and count the number of times you see style="...;;" or style=";", although this is a problem with most templates that let you define custom styles)). —Dinoguy1000 17:17, 14 May 2008 (UTC)

Well the template (as a whole) produces html code that is perfectly correct as far as I can tell. It appears to me that on the other wikis the tidy function is being called after each parser function, which is causing the problems (the output of a specific parser function gets prematurely tidied, instead of just the entire template output being tidied as a whole). English Wikipedia doesn't call the tidy function after each parser function, which is what it should do, but the other wikis are calling tidy. In English Wikipedia, like I said before, the total output is good html so the tidy function has no effect, so there is really no need to change the {{Navbox}} code. If other wikis want to use this code, they'll have to disable tidying after each parser function to get it to work. As far as removing the style="...;;;..." calls, why bother? That code is used to force semicolons between different styles, and is necessary for backward compatibility and to protect against users forgetting them. I don't think it's that big of a deal to have a few extra semicolons here and there. It's a feature with a purpose at the cost of probably an extra 25 bytes. --CapitalR (talk) 17:27, 14 May 2008 (UTC)

As a potential fix, could we take a look at the Tidy.conf file some how that Wikipedia uses and use that. If I can replicate the environment as close as possible to this one, I don't see why it would still generate errors. Is there a way to see the source for Tidy.conf similar to Common.css? It resides a couple directories lower in the file system, but you never know. Tigey (talk) 19:17, 14 May 2008 (UTC)

When I asked about this on Wikia they told me it was something a dev had to set. -- Ned Scott 06:35, 15 May 2008 (UTC)

Made a post to Village Pump (Technical) After some playing around on my own wiki environment I found that HTMLTidy did not seem to be enabled. I enabled it, pointed it to the Tidy.conf file, and nothing has changed. A reply in VillagePump was made that it may be one of the other extensions installed to Wikipedia that I do not have. I will try tonight to install some of the likely ones and see if that alleviates the problem. Tigey (talk) 17:07, 16 May 2008 (UTC)

What version is your wiki running? If it isn't at least 1.12 final, try upgrading to that to see if it works.--Izno (talk) 05:31, 18 May 2008 (UTC)

Aha! On your separate wiki environment (from your post at the VP), you're running 1.11. This may be part of the problem; with 1.12 (final) comes a new preprocessor, which may have dispatched that problem. --Izno (talk) 05:39, 18 May 2008 (UTC)

Lo and behold! It werks! I installed the 1.12 version and it is now, as they say, all good. Now the hard part... Getting the admins on the wiki that I am porting this to to upgrade.... Tigey (talk) 18:07, 18 May 2008 (UTC)

Also, in the release notes for ver 1.12 it alludes to a bug that was fixed Bug 5678 that affected Templates with variables in the Else portion of #If Parsers. This is also a likely cause of the problem since this template is chock full of em. Tigey (talk) 18:17, 21 May 2008 (UTC)

Hey, that's great news. Let me know if there's other stuff you'd like me to look at for you (and sorry I've been a little busy lately and haven't been much help). --CapitalR (talk) 05:07, 22 May 2008 (UTC)

[edit] State: has something changed?

An empty value of the state parameter always meant show, and I defined lots of templates on that assumption. Now it seems this no longer works - templates are being hidden where previously they weren't. Example: the "Pomeranian Voivodeship" template at the bottom of Chojnice County (and similarly with most other Polish "counties"). Is there some good reason for this? Any chance of it being changed back, or do I have to go round all these templates changing the default state from empty to something else?--Kotniski (talk) 10:21, 10 May 2008 (UTC)

There was a major code upgrade on May 2nd, but it should not have changed functionality. However, looking more closely at the code, a blank state= parameter now seems to be ignored and default to autocollapse, and the documenttation does not reflect this. In fact, we tried to make it backward compatible, but we seem to have missed this one. CapitalR, the current code's architect, can tell you more. I think the idea was to eliminate the blank state= paramter in the long run. So maybe it's best to include the following code in your templates

| state = {{{state<includeonly>|uncollapsed</includeonly>}}}

Hope that helps. — Edokter • Talk • 12:33, 10 May 2008 (UTC)

Yeah, sorry about that one, but I think it makes a lot more sense for a blank state parameter to autocollapse the template, which is the same as just not even including the state parameter. It just doesn't make sense for a blank parameter to do something different than not including the parameter at all. I can do a quick AWB run to fix those ones that were affected. --CapitalR (talk) 13:17, 10 May 2008 (UTC)

OK, that would be great. In the case of mine it would be a case of replacing

| state = {{{state|}}}

(possibly with different spacing) with Edokter's code as given above. Thanks,--Kotniski (talk) 13:24, 10 May 2008 (UTC)

There we go, should be all taken care of now. --CapitalR (talk) 14:22, 10 May 2008 (UTC)

I was under the impression that backward compatibility was built in, but I like it better this way anyway; I've corrected the documentation accordingly. — Edokter • Talk • 14:34, 10 May 2008 (UTC)

Yeah, this is how I thought it worked originally; I didn't realize until just before I deployed the new version that I had changed the functionality, but I decided this way made more sense. Since there haven't been too many complaints, I think it was a good idea. --CapitalR (talk) 14:43, 10 May 2008 (UTC)

Thanks for doing the conversion. Could you do those in Category:Poland province (voivodeship) templates as well, as they seem to have been missed? Or if it's not convenient, I can do them by hand (should only be 16 of them).--Kotniski (talk) 08:17, 11 May 2008 (UTC)

All taken care of. --CapitalR (talk) 08:26, 11 May 2008 (UTC)

Great, thanks:)--Kotniski (talk) 08:46, 11 May 2008 (UTC)

[edit] {{High-use}} insted of {{intricate}}

Currently at the top of the documentation this template uses the {{intricate}} warning. I intend to change that to the {{high-use}} warning instead.

I have always felt that {{intricate}} doesn't really fit for high-risk / high-use templates, since it mostly talks about the code being intricate. That {{navbox}} is intricate is pretty obvious when one looks at the code or documentation, no need to tell that. What is not obvious from just looking at navbox is that it is used on 652,000 pages. So the {{high-use}} template is a way of telling that.

Also, I have noticed that many admins are sloppy and don't use sandboxes, instead they try things out directly on protected widely used high-risk templates. Edit comments like "just testing" on templates used on 100,000 pages or more are all too common. The {{high-use}} template points them to the /sandbox and /testcases instead.

I intend to add this code:

{{high-use| 600,000+}}

Which will render like this:

This template is used on 600,000+ pages To avoid any disruptions and to save server load, any changes should first be tested in this template's /sandbox or /testcases subpage, or in your own user space. The tested changes can then be added in one single edit to this template. As a courtesy to other users, please discuss any changes at the talk page before implementing them.

Any comments? Oh, and any suggestions for improvements of the {{high-use}} template are welcome.

--David Göthberg (talk) 16:43, 15 May 2008 (UTC)

• Add the high-usage, but leave the intricate template, because the navbox is intricate after all. — Edokter • Talk • 20:29, 15 May 2008 (UTC)

[edit] border-left color of th

I was wondering why <th style="border-left:2px solid #fdfdfd;width:100%;|<th style="}};" is the way it is, with regard to the color of "border-left". Why isn't it transparent, and/or not declared to begin with? This question also applies to the twenty other instances of this as well, for each row's th. The only class which takes this color for border-left in common.css is .navbox-list, and the other two classes — .navbox and .navbox-subgroup — which take this color refer to background. --Izno (talk) 01:56, 16 May 2008 (UTC)

This is because the 2px gap between the groups and lists has to be drawn with a border instead of a spacing between the cells (this is done in order to make the navbox nest-able inside of itself). Thus, the border color is set to match the background color of the navbox as a whole. I recently added that CSS to MediaWiki:Common.css, so in a few more weeks (after common.css propagates to all users) we'll be able to remove it from the Navbox code again. It's a strange way of rendering cells, but it's the only way possible to make them perfectly nestable (believe me, I spend many many hours trying to do it another way). The downside is that if someone wants to use a different background color than the default, "liststyle = border-color:#xxxxx;" must be used to ensure the 2px gap matches it. Fortunately, I did a database scan and of the 35k templates using Navbox, only 2 used a different background color (not counting templates that used a white background, which is close enough). The other side effect is that if anyone wants to put borders around the list cells, they lose the gap between the lists and groups; again, a database scan showed that of the 35k templates, 0 used borders around the whole list area, so it's not a problem. I wish we could use a transparent border, but IE and Firefox don't agree on what transparent means. --CapitalR (talk) 02:18, 16 May 2008 (UTC)

Unfortunate how browsers can be inconsistent (I blame IE, but to each their own). So, after the CSS is done propagating, what will the final code be for any given th? I'm asking as I'm copy-pasting to an external wiki; presumably, the same, except for <th class="navbox-list" style="border-left: 2px solid; width: 100%;? --Izno (talk) 04:41, 16 May 2008 (UTC)

The final code will not contain any of the border-left statements in any of the cells. There is a parameter called "border"; be sure not to delete that (it's unrelated and coincidentally named border also). Just delete all "border-left:...;" and it should work. --CapitalR (talk) 05:20, 16 May 2008 (UTC)

Excellent; thank you for the aid. That also means that <th class="navbox-list" style="width: 100%; is correct? --Izno (talk) 05:41, 16 May 2008 (UTC)

Yup. Just make sure you've got all the latest CSS from MediaWiki:Common.css. --CapitalR (talk) 05:58, 16 May 2008 (UTC)

[edit] Possible code change?

Is it possible to remove the <td></td> and <tr></tr> stuff and replace them with other code?--Richard (Talk - Contribs) 22:42, 16 May 2008 (UTC)

No. The template uses raw HTML tables instead of wikitables in order to minimize conflicts with parser functions. — Edokter • Talk • 22:56, 16 May 2008 (UTC)

Yeah, the code would be much longer and more complicated using wikitables, and frankly I'm not sure it's even possible at all. --CapitalR (talk) 00:29, 17 May 2008 (UTC)

It's completely possible, and isn't always that much more complicated. I've done a bunch of these kinds of conversions myself, and am currently doing one for a copy of Navbox now for other wikis. From a compatibility standpoint (reuse is one of our goals), I support doing this, but I understand if others have objections. It's hard to get people to change when there's not a lot of incentive for Wikipedia's own use. -- Ned Scott 04:36, 18 May 2008 (UTC)

And on another note, this really is a mess of a template. It would have made far more sense to just enforce a MOS guideline and keep the vast majority of these templates simple in their code. We have Wikitable code, parser functions, and the like, specifically for these reasons. -- Ned Scott 04:37, 18 May 2008 (UTC)

(Warning: Answer isn't very focused but should cover all of your points, also, outdent) Wikitable code is an editor's friend; the way this template is coded is obviously for presentation purposes, and nothing else, and thus I see little purpose in recoding it simply for the editor's eyes. Following from that point, this template is used on thousands of pages, and as such does not need to be friendly to an editor's eyes, as it will rarely if ever be changed. As well, I believe (read: am unsure) it's easier on the parser to have this coded in straight html rather than the corresponding wikicode. From a compatibility standpoint, the only difference between compatible for this wiki and compatible for most wikis is simply setting UseTidy to true (alternatively, it may be the 1.12 final preprocessor; I'm not sure of which anymore).
Yes, it is possible, but I would disagree that it is only a degree more difficult, as I myself went through this in its pre-May update form and coded it using wiki-tml, which required that I use templates to call the correct characters to create a wiki table (such as {{!}}), as well as eliminate (possibly) desired functionality in {{Tnavbar}}. Not fun, and definitely not worth sacrificing other functionality.
No, that's not the reason we have parsers. We have parserfunctions because they are definitely easier for the parsers to handle, as compared to something like a template (ie, {{qif}}) which duplicated the functionality of current parsers but was not only subjected to template limitations, but also "kill the wiki" limitations. As for wikitable code, it's a presentation based code, which keeps it simple for editors. Obviously, the people who maintain navbox know the corresponding html and thus design in that to get around those other issues (which they have specified).
MoS guideline... simple? Huh? I don't understand what you're saying. --Izno (talk) 05:25, 18 May 2008 (UTC)

I think you mixed up my two replies, or rather, I wasn't very clear in my two replies. In my second reply I was saying it would be better to not rely on a mother template like this to keep things standardized. Sure, it limits things from a technical standpoint, but it's always struck me as a sloppy way of enforcing standardization. I'm not commenting on the use of HTML vs wikitable code when I say that we have parsers and such. That comment was directed at the use of individual templates that don't require a mother template.

The reason I think it's a good idea to use Wikitable code doesn't have to do with parsers or to make it easier for editors to edit the template. The reason is for compatibility with other sites that use MediaWiki. Sorry I wasn't very clear. -- Ned Scott 05:22, 22 May 2008 (UTC)

You would see it as sloppy; I would see it as a rather neat solution to standardization issues. I think it especially applies to meta-templates, as it ensures users (editors) stick with the program. This template is by itself used on several thousand other templates; can you imagine the logistical nightmare associated if there were a need to change how such templates were displayed without a meta template? Now imagine that nightmare without automated editing programs. Yeah...

Other sites which use MediaWiki should keep up-to-date; iirc, 1.12 final was released in November, some 6 months ago, which if they aren't using 1.12 by now (or 1.13a), that's their problem. This template is first and foremost for use by WikiMedia wikis, and from my perspective (no, WikiMedia wikis aren't my main focus), any trickle-down to Wikia or otherwise is a benefit of the MediaWiki system, rather than something that should be (or "is") done with purpose from the top down. --Izno (talk) 06:04, 22 May 2008 (UTC)

Because navbox allows customization options, the only way to standardize them is to still edit each and every template. You're not gaining anything from the current system here. That is the reality here, and my watchlist can back this up. In some cases the template actually generates more characters than using a direct table. Font sizes, table widths, and colors can easily be controlled by CSS classes, which would take care of most of the constancy issues.

Being up to date with MediaWiki has nothing to do with compatibility, because the issue is with the Tidy settings. This attitude of "fuck you, you're not wikipedia, so we're going to make it harder for you" is the kind of isolationist thinking we can do without. It wouldn't make anything harder, at all, to make this template work with pure wikitable code. You've said yourself that the template doesn't get edited often anyways, and won't look pretty to editors. Excuse me if a one time conversion that would greatly benefit others wishing to reuse our content (which has always been a core goal of Wikipedia) seems like a good idea. -- Ned Scott 06:55, 22 May 2008 (UTC)

True, but enforcing navbox prevents users from going off on wild tangents; the customization options are allowed, but discouraged (it says so on the template). I never said navbox was smaller, so I don't know why you would bring that up.

Incorrect: See here. Navbox works correctly on MW 1.12 final without Tidy changed (and if it requires tidy, then I'm reading that whole conversation incorrectly, which I shouldn't be, as I provided the correct solution). If I had meant "Fuck them", I would have said "fuck them". In truth, it sounds like part of the issue you're having is troubleshooting, and that is something to be left for IRC or this talk page; there are numerous occasions as can be seen on both this active page and in the archives. I did not say Wikipedia was going to make it harder by not changing it, I said that it is up to them to take initiative. If the people like how navbox is constructed, they can easily c+p the code here, or convert the code on their side. If they don't like how it is constructed, they can take other options available to them, such as designing their own table or eliminating functionality of their choosing. Furthermore, if Wikipedia were to change how Navbox is designed, it would require that we use templates embedded in this one, a la {{!}}. It would not be an option, but required. Blame ParserFunctions.

You seem to have the mistaken assumption that I'm doing arguing my side maliciously. I'm not. I don't normally edit Wikipedia, instead editing a Wikia of my choosing, as it both suits my interests and allows me much more flexibility policy-wise. I've successfully ported navbox using the code provided here, and properly skinned it for both a dark and light version. In the end, I will again state that it is the other people's initiative to engage in figuring this template out. --Izno (talk) 21:18, 22 May 2008 (UTC)

"I used the User:Ned Scott/Navbox/core version to fix some problems that this particular Wiki was showing with the template.", which converts the template from HTML table code to Wikitable code via {{!}}, etc. So yes, the tidy option does break the template, and I know first hand what is involved for converting the template. I personally am not having any troubleshooting issues (though I am dragging my feet about re-converting the newer version of navbox for use on some other Wikis I work with), so I'm not sure what you mean by that comment.

However, it seems I have misunderstood the bulk of your comments and I completely apologies. Re-reading it now I can see you didn't mean things the way I assumed. -- Ned Scott 04:23, 25 May 2008 (UTC)

Heh, it's alright. And I ended up wrong about tidy; you need both 1.12 and Tidy to fix it... Sigh. --Izno (talk) 17:39, 25 May 2008 (UTC)

[edit] Autocollapse disabled?

I am viewing this on Opera, and on a number of pages with the Navbox used that I look at, the autocollapse has been disabled. Is it possible to reactivate it, because it is making pages look very unwieldy. --AEMoreira042281 (talk) 04:53, 22 May 2008 (UTC)

Can you give some examples of pages with this problem so I can take a look in Opera? --CapitalR (talk) 05:05, 22 May 2008 (UTC)

For starters, you can look at articles such as SEPTA, and any article under the WP:NYCPT WikiProject, where navboxes are employed in almost if not every article in the WikiProject.--AEMoreira042281 (talk) 14:56, 22 May 2008 (UTC)

It's not disabled here... Is JavaScript turned on? Autocollapse depends on it. — Edokter • Talk • 15:05, 22 May 2008 (UTC)

I will have to check here. I am also having problems with Twinkle...again, using Opera. --AEMoreira042281 (talk) 15:24, 22 May 2008 (UTC)

[edit] Requirements To Import To Another Wiki

I ran into some trouble trying to figure out how to import the Navbox template into my own wiki. More importantly I spent more time that I should have needed to figuring it out. The core content can be easily exported and imported using the special pages. Remaining requirements (as I found) are two extensions, ImageMap and ParserFunctions. I think it would be beneficial to others if a small amount of documentation was written on How To Enable Navbox On Your Own Wiki or something of that nature. Here is a start

• goto http://en.wikipedia.org/wiki/Special:Export
• enter the following into the text area (leave the Add pages from category input blank):

Template:Navbox
MediaWiki:Common.js
MediaWiki:Common.css

• make sure all three check boxes are checked
• hit export and save the xml file to disk
• goto the Special:Import page on your own wiki
• browse to the file and hit upload
• goto http://www.mediawiki.org/wiki/Extension:ParserFunctions and follow installation instructions
• goto http://www.chekmate.org/wiki/index.php/MW:_ImageMap_Extension and follow installation instructions
• head to the Template:Navbox/doc page on your own wiki to see that everything installed ok

144.223.18.102 (talk) 21:51, 22 May 2008 (UTC)

I'll be sure to add this to WP:TRAN, a slow, but growing technical help guide for reusing English Wikipedia content. -- Ned Scott 23:00, 22 May 2008 (UTC)

[edit] float issue

See User:Izno/Sandbox#New VG navbox. Quite clearly, I have the template code set to float, but it is not doing so.

I can obviously override it by placing it in a <div>, but as it's a workaround rather than desired implementation, thought I'd drop a note. --Izno (talk) 00:01, 8 June 2008 (UTC)

It's floating for me... (IE6) — Edokter • Talk • 13:00, 8 June 2008 (UTC)

Not for me. Here is a test with "style= width:22em; float:right;" it is centered in FF2. --—— Gadget850 (Ed) ^talk - 13:26, 8 June 2008 (UTC)

v • d • e Test1 Test3

But it does float right in IE7 and FF3. --—— Gadget850 (Ed) ^talk - 13:28, 8 June 2008 (UTC)

Eep, yes. I'm using FF2 also. --Izno (talk) 17:09, 8 June 2008 (UTC)

Try setting "margin-left:0em;margin-right:0em;" also (or to whatever em value you want, probably 0em on the right and 1em on the left), which might work. The default "margin-left:auto;margin-right:auto;" sometimes messes with floats. --CapitalR (talk) 18:50, 8 June 2008 (UTC)

Perfect, thank you capital. Someone may want to add that to the /doc page, which suggest that floating is as easy as floating anything else. :) --Izno (talk) 19:03, 8 June 2008 (UTC)

Glad to hear that worked. I just added a comment at the bottom of the doc page about using navbox as a float. --CapitalR (talk) 01:53, 9 June 2008 (UTC)

[edit] Why is View Discuss Edit on the left, instead of the right?

v • d • e Example everyone expects article-section-[edit] links to be over here. ↑ left-to-right readers (us) will tend to look over here ← first. can we switch them?

1. The article-section-[edit] links are site-wide on the right.
2. Yet, the navbox v · d · e links are on the left.
3. Our readers are more likely to want to [show] the collapsed navboxes, than to edit them - but the [show/hide] is currently on the right (where a left-to-right reader will look last).

• Also - the article-section-[edit] links and the [show/hide] links are all 4 letters long and surrounded by [square brackets] (easy to confuse at a glance) - But, one pops-opens a navbox, and the other changes to a new page!

Is there a reason that these are so confusing? Can we just swap them around? Seems obvious enough that I must be missing something... Thanks :) -- Quiddity (talk) 21:05, 10 June 2008 (UTC) and edited at 23:19, 12 June 2008 (UTC)

This is because the collapsible tables script automatically inserts the [show/hide] link to the right. There's no way to change this without changing the script, and this would affect hundreds of thousands of other uses across Wikipedia. —Dinoguy1000 21:09, 10 June 2008 (UTC)

Yes, it would obviously be a large scale change.

• Are you saying that I'm asking in the wrong place?
• If so, where should I be asking?
• and would you agree that the order should be switched, so that the vde/edit links are all on the right of the screen and the show/hide link is on the left (at the beginning of the line, where the reader's eye first looks)? thanks, -- Quiddity (talk) 22:44, 12 June 2008 (UTC)

I think it would be better too keep them as they are, the "view discussion edit" is probably there in that order because that's how it is at the top of the page. |Template|Discussion|View source| for this template. ← chandler 23:50, 12 June 2008 (UTC)

Since Quiddity asked me to come here and comment:

Too me from a visual point of view it doesn't matter which object is on which side, I have no problem to see them all. But since I mostly use the mouse to pull the scroll bar the mouse pointer tends to be on the right side of the screen. Thus considering that [show/hide] is the more common thing to click then having it on the right side means a shorter mouse movement. So the current position is perhaps the slightly better one. But doesn't matter much.

Of course, since I do use the scroll bar (instead of a scroll wheel or other slower means of moving the page) and have my mouse speed set properly I have no problem to scroll past long sections of boxes. Thus I find hidden (collapsed) boxes very annoying since they mean unnecessary information hiding and unnecessary clicks for me. I rather see it all and simply scroll past it. But it seems other people have trouble scrolling pages thus they want to hide things. When will people learn to scroll properly? Do they have a lack of motor skills or what? :((

--David Göthberg (talk) 04:24, 13 June 2008 (UTC)

I personally hate really long scrollbars. But that's just me. ^^ --Izno (talk) 05:20, 13 June 2008 (UTC)

Personally, I seriously doubt that concensus for swapping the VDE/show-hide links could be achieved, considering the order is largely a matter of personal preference, and an actual change would require checking each of the hundreds of thousands of uses of both features beyond navboxes to ensure that nothing breaks, and to update things when they *do* break. —Dinoguy1000 16:44, 13 June 2008 (UTC)

I see it as a matter of usability (specifically Web usability), not personal preference. I've tried to explain that above, but noone seems to understand. Whatever. Consider it dropped. -- Quiddity (talk) 18:56, 13 June 2008 (UTC)

[edit] Titlebar problem

There is a problem with the titlebar in Template:Video RPG. The controls are broken onto a new line hovering above the template title. Could someone please fix it? Thanks! SharkD (talk) 17:16, 13 June 2008 (UTC)

The template is simply too narrow for the title and the controls to fit on one line. — Edokter • Talk • 17:18, 13 June 2008 (UTC)

I've tried widening it to 300px, yet the titlebar is still placed on a new line. SharkD (talk) 17:23, 13 June 2008 (UTC)

try 28em, but that gets very wide. — Edokter • Talk • 17:47, 13 June 2008 (UTC)

I think I managed to get it to a satisfactory state. SharkD (talk) 20:31, 13 June 2008 (UTC)

It's probably because of the forced padding to center the title which offsets the [hide] button. I've had a similar issue redesigning a small template myself. --Izno (talk) 21:23, 13 June 2008 (UTC)

Part of the problem is also trying to make it look like an infobox; wouldn't it make more sense to just use the standard formatting using groups? — Edokter • Talk • 23:52, 13 June 2008 (UTC)