Wikipedia:Template talk:Navbox

From Global Warming Art

Please read before posting These are responses for some frequently asked questions. If they don't help, please feel free to post with your question anyways. Additional rows will not be added to {{Navbox}}. There are only 20 rows available because the vast majority of navboxes have no need for more than 20 rows (only about 25 out of 55,000+ require it), and because additional rows add nontrivial server processing time to the template. Navboxes can be nested inside each other; if you need help correctly nesting them, feel free to ask. The v•d•e links are produced by {{Navbar}}. If you have a question pertaining to them, it is probably best to ask at Template talk:Navbar. If you are trying to copy {{Navbox}} to your local wiki, there are several other things that must be installed or copied over as well: {{Navbar}} requires MediaWiki 1.15.0 (r46662) at minimum, due to the use of {{PAGENAME:page}} functionality. Trying to use a lower version will result in the display of stuff like [[Template:FULLPAGENAME: Navigation templates|view]]. ParserFunctions must be installed. Without it, you'll probably just see lots of stuff like {{#if:{{#switch:| when trying to use it. HTML Tidy must be installed and enabled for Navbox to display properly. There is a version of Navbox which does not require Tidy at Wikipedia:WikiProject Transwiki/Template:Navbox. {{Navbar}} must also be copied. There is a version ready for transwikiing at Wikipedia:WikiProject Transwiki/Template:Tnavbar. Navbox uses several styles in MediaWiki:Common.css and the collapsible table code from MediaWiki:Common.js; these must also be copied.

Archives
Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 See Template talk:Navbox generic for previous discussion.

Edit protect

{{editprotect}} Can someone revert the last edit backto the last one, the new edit does not remove redundant code, it affects the {{Navbox with columns}}. See difference down below on the coloumns which gets padded in instead lining up with the groups and title — CHANDLER#10 — 02:13, 1 March 2009 (UTC)

Old code

New code

• Y Done Yes, you are correct that the edit did mess up the Navbox with columns templates. I've reverted the edit and all should be back to normal now. The strange code gives the option to remove the padding altogether from wrapping the lists, which prevents odd html quirks from adding extra pixels of spacing to the left and right in certain cases (such as the Navbox with columns case). --CapitalR (talk) 11:14, 1 March 2009 (UTC)

I can see no difference at all at the examples given above, possibly due to the revert. Excatly what code caused the problem? Then that code should be commented as required. Not all changes could possibly be responsible for the adverse effects. — Edokter • Talk • 19:24, 1 March 2009 (UTC)

OK, stripping the list1padding was the mistake. All other changes had nothing to do with this issue. So I would like to reinstate the other fixes (and comment the list1padding parameter) if there are no objections. — Edokter • Talk • 20:33, 1 March 2009 (UTC)

Yeah, I took a look through other templates dependent on Navbox and think that list1padding is the only required one. Removing the other ones should be perfectly fine. --CapitalR (talk) 22:40, 1 March 2009 (UTC)

Autocollapse modification

Now there are so many template that each article will have 2 template. But due to autocollapse both are collapsed, and novice wiki users(not editors) dont see template at all. Also this hampers navigation by search engines too.

So when multiple templates are there in an article, autocollapse should expand first of the multiple templates included in that page. Which template appears first is determined by editors of the article. This modification will not call for large scale modification of many articles, instead just the modification of wiki rendering software. Cited third page (talk) 07:01, 2 March 2009 (UTC)

This request should be made on MediaWiki talk:Common.js, since {{Navbox}} itself doesn't and can't automatically control collapsing on articles with multiple navboxes. And IIRC, the autocollapse is not triggered unless there are more than two collapsible elements on the same page (which is why navboxes on most anime and manga series articles are collapsed by default, even if they only transclude one navbox), and trying to keep track of exactly what is being made collapsible (is it navboxes, or some part of the infobox, or something else, and how many instances of each) would unnecessarily complicate an already complicated piece of Javascript. A far simpler solution for your problem would be to define |state={{{state|}}} in the individual navbox in question, which can then be expanded by default on articles simply by calling {{Name of navbox|state=expanded}}. 「ダイノガイ千？！」^{(Dinoguy1000)} 19:42, 2 March 2009 (UTC)

Why two tables?

Is there any particular reason for using a table embedded in another table to display the box? --Tgr (talk) 14:17, 4 March 2009 (UTC)

Mostly styling issues, but I think collapsability is also one reason. — Edokter • Talk • 16:46, 4 March 2009 (UTC)

Something like that, I'm sure. CapitalR did a lot of testing to get to the current code, and if there was any satisfactory layout that only required one table, he would've found and used it. 「ダイノガイ千？！」^{(Dinoguy1000)} 20:20, 4 March 2009 (UTC)

Does it have anything to do with the "child" function which I guess is 1 table, but when it's outside the navbox like below, the title moves when you click on show/hide? (at least in my Firefox, Safari, Chrome and Opera, but stays in the middle with IE7) ch¹⁰ · 21:19, 4 March 2009 (UTC)

title
list

That is due to the float conatining the "hide"/"show" text changing size. I'm not sure why it doesn't happen in the double table version (probably some CSS rule that is normally inherited from the outer table is missing), but you can fix it easily by giving .collapseButton a fixed width. --Tgr (talk) 11:45, 5 March 2009 (UTC)

Hmn, the code I added for .collapseButton in MediaWiki:Common.css does give it a fixed width inside the "navbox" class, which was supposed to prevent precisely this issue (and balance the vde links on the other side). Is that class not given in the single table version? Happy‑melon 18:44, 9 March 2009 (UTC)

Collapsibility works perfectly well with only one table (though I didn't test it in all browsers). I'll ask CapitalR then. --Tgr (talk) 11:45, 5 March 2009 (UTC)

It's been a few years since I wrote the Navbox code, but I do recall that doing it with two tables was the only way to get proper display for nested Navboxes in all browsers (I think IE6/7 were the offenders that made that necessary). Without nested Navboxes, it wouldn't be necessary for the two table system, but with them (i.e. {{Navbox subgroup}}, {{Navbox with columns}}, and {{Navbox with collapsible groups}}), the two table solution was needed. In order to keep the code the same in all of these templates (and to allow nesting directly into {{Navbox}} lists), I had to use the two table solution for Navbox. If I recall correctly, it will be possible for me to do a major code rewrite and go to the one table method once mw:Extension:StringFunctions are implemented (see bugzilla:6455). Also, with StringFunctions, I would be able to fix the odd way the spaces are drawn between the table cells (again, necessary due to browser support). However, I've been waiting on that bug for years now, so don't count on the code rewrite any time soon (unfortunately). Also, it may be possible to eliminate the two table solution in favor of one table if support for IE6 is dropped (though don't hold me to that, as IE7 has much of the same weirdness/bugs as IE6). Perhaps someone else can try to do it with one table, but I will say that I tried very hard and couldn't do it successfully (and I spent in excess of 200 hours developing the Navbox code). --CapitalR (talk) 12:40, 5 March 2009 (UTC)

I would also love to see StringFunctions implemented, but none of us are devs, and none of the devs seem to want to spend time on it (something about "more important things to work on" =) ), so I'll have to be content with voting for it for now. 「ダイノガイ千？！」^{(Dinoguy1000)} 20:34, 5 March 2009 (UTC)

Wrapping text around an image

Is it possible to wrap the text around an image, such as in this template. --Geronimo20 (talk) 03:26, 12 March 2009 (UTC)

I don't think it's possible, unless you were to float the image inside one of the lists off to the right side (which would probably look funny unless the image was small). --CapitalR (talk) 04:11, 12 March 2009 (UTC)

Missing Template:FULLPAGENAME: Error

Greetings! I am importing this template into my person wiki and keep getting a missing template error. I used the Special:Export feature to export Navbox and all associated templates. It appears as though all is well with the exception of a few templates which look to be associated with the "v • d • e" functions. The templates missing are as follows:

Template:FULLPAGENAME: Former French colonies in Africa and the Indian Ocean
Template:FULLPAGENAME: Former French colonies in Asia and Oceania
Template:FULLPAGENAME: Former French colonies in the Americas
Template:FULLPAGENAME: Navbox/doc
Template:FULLPAGENAME: Navigation templates
Template:NAMESPACE: Former French colonies in Africa and the Indian Ocean
Template:NAMESPACE: Former French colonies in Asia and Oceania
Template:NAMESPACE: Former French colonies in the Americas
Template:NAMESPACE: Navbox/doc
Template:NAMESPACE: Navigation templates

The rendering of "v • d • e" on my wiki looks like this:

[[Template:FULLPAGENAME: Navigation templates|view]] • [[{{TALKPAGENAME:Template:FULLPAGENAME: Navigation templates}}|talk]] •  [{{fullurl:Template:FULLPAGENAME: Navigation templates|action=edit}}edit]

While the output lists a few specific templates I'm not concerned about (such as Former French colonies), I am interested in getting the Template:FULLPAGENAME and Template:NAMESPACE. These templates appear not to exist. Can someone tell me where to find these templates or what I should change in Template:Navbox or Template:Navbox/doc to solve the "v • d • e" rendering errors. I appologize if I have misdirected or miscategorized this question. Thanks! aszymanik speak! 01:59, 20 March 2009 (UTC)

{{FULLPAGENAME}} and {{NAMESPACE}} are magic words (manual) that produce The full page name and the name space ("Template talk:Navbox" and "Template talk") Personally I don't know how one would do to copy them... You can perhaps ask on MediaWiki's help page, Wikipedia's help page or something (unless someone here knows) chandler · 02:07, 20 March 2009 (UTC)

there is no need to copy the magic words, they exist in every MediaWiki installation. In any case, it sounds like something got accidentally substituted when you transwikid the templates, aszymanik. Could you provide a link to them on your wiki, please? 「ダイノガイ千？！」^{(Dinoguy1000)} 17:20, 20 March 2009 (UTC)

Did anyone figure out this problem? This happened to my wiki as well and all the templates are freaking out. Kristinpedia (talk) 18:53, 6 May 2009 (UTC)

Once again, please provide a link to one of the problem pages on your wiki so we can see exactly what's going on. 「ダイノガイ千？！」^{(Dinoguy1000)} 04:55, 7 May 2009 (UTC)

Only from MetaWiki version 1.15 onwards,the FULLPAGENAME magicword can be used to refer a namespace —Preceding unsigned comment added by 203.200.20.98 (talk) 12:28, 19 May 2009 (UTC)

Sure. http://sunshinereview.org/index.php/Template:State_sunshine_laws. Kristinpedia —Preceding unsigned comment added by 98.223.170.149 (talk) 19:22, 8 July 2009 (UTC)

Whatever the problem was, it seems to have been fixed. If you encounter any pages where the problem remains, you should be able to fix it simply by purging the server cache of the page. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:54, 8 July 2009 (UTC)

More than 20 groups

{{editprotected}} Could we get more than 20 groups? Needed for {{Street newspapers}}, for all the countries in Europe. --Apoc2400 (talk) 12:10, 21 March 2009 (UTC)

N Not done You can nest Navboxes to get as many groups as you wish. I'll take a look at the template in question for you. --CapitalR (talk) 13:00, 21 March 2009 (UTC)

There you go, should be all fixed now; you can keep adding more groups to the new child navbox I added. --CapitalR (talk) 13:03, 21 March 2009 (UTC)

Thank you. Is there any reason for the 20-group limit? Also, would it be possible to have the template display a warning message if there are too many groups? --Apoc2400 (talk) 13:40, 21 March 2009 (UTC)

Basically, the more groups there are the longer it takes the servers to render pages with Navboxes. I did some testing when I wrote the Navbox code and found that each additional group's code does add non-trivial render time, so capping the groups at 20 keeps it at a reasonable level (my original plan was 16 groups, but I bumped it to 20 at the last minute). Also, of the 55,000 or so templates using Navbox, only about 25 require more than 20 groups, so it's really not worth adding more do to the increased render cost on all other pages. --CapitalR (talk) 21:20, 21 March 2009 (UTC)

I have ported this template to my own wiki and am using it for a textbook. Unfortunately the textbook has 22 chapters. I tried to go in and extend the template to 24 groups to no avail. Is there something I'm missing? Is there a better way of navigation? This seems to be the perfect navigation between subchapters, so I would think extending this template would be the way to go. Any comments would be appreciated (http://wiki.chemprime.chemeddl.org - an online living chemistry textbook). Jshorb (talk) 16:42, 10 April 2009 (UTC)

Taking a quick look, it seems you have group19/list19 twice in the template code and forgot group21/list21. Also, you need to make sure that all of the even/odd code is correct. To fix this, I recommend starting over and copying and pasting rows 17-20 again to convert them into 21-24. This will ensure proper even/odd-ness. Then convert all the 17s to 21s, all the 18s, to 22s, etc. --CapitalR (talk) 20:43, 10 April 2009 (UTC)

Excellent. I hadn't noticed the even/odd requirement. That fixed everything. Thanks for the help. Jshorb (talk) 18:16, 5 May 2009 (UTC)

How about creating a Template:Navbox-long with many more groups that can be used when needed? --Apoc2400 (talk) 21:39, 10 April 2009 (UTC)

I just created {{Navbox long}} which supports up to 38 groups/lists. It performs the nesting automatically making it easy to get that many groups. Note that it is unable to determine the group width properly between the first 18 groups and the subsequent groups (due to technical reasons that are not possible to overcome). Thus, you must manually specify the group width for this to work. This can be done by adding the parameters groupstyle = width:XXXem; and liststyle = width:auto; which should make it work (where XXX is the desired group width). Let me know if it works for you; if it seems to do the trick and my further testing does well, I'll add it to the {{Navbox suite}} list. --CapitalR (talk) 01:06, 12 April 2009 (UTC)

Nice! Is it because of the nesting that you have to set the group width? --Apoc2400 (talk) 08:45, 12 April 2009 (UTC)

Yup, that's the reason. We could, of course, make a version without the nesting in it by copying the Navbox code and adding more groups, but then we run into maintenance problems because any change on {{Navbox}} needs to be copied into {{Navbox long}} (which is likely to be overlooked occasionally). Considering how few templates need more than 20 groups (it's about 35 out of 55,000), I don't think it's too much to ask to specify the group width on those to avoid the duplicate code problem. --CapitalR (talk) 10:08, 12 April 2009 (UTC)

Question???

What is the code for the view • discussion • edit in the title space? I can't seem to figure it out. (Tigerghost (talk) 13:32, 23 March 2009 (UTC))

{{tnavbar}}. 「ダイノガイ千？！」^{(Dinoguy1000)} 19:35, 23 March 2009 (UTC)

I was wondering about this. I there any way we can make those links show up only to logged in users? For readers they are just a distraction. --Apoc2400 (talk) 10:18, 12 April 2009 (UTC)

IPs can edit and discuss templates too. They're no different then the section edit links. — Edokter • Talk • 17:54, 12 April 2009 (UTC)

And section edit links aren't visible to IPs. They are much less likely to want to edit templates, and it distracts from reading. --Apoc2400 (talk) 18:12, 12 April 2009 (UTC)

They are very visible to everyone, including IPs. Why would we want to hide them from the templates and keep up the notion of an encyclopedia that anyone can edit? — Edokter • Talk • 21:10, 12 April 2009 (UTC)

You are right. I must have confused it. --Apoc2400 (talk) 19:43, 13 April 2009 (UTC)

I frequently edit while logged out; section edit links are definitely visible to me, and hiding those links (and the v-d-e links) from anonymous users would be a huge disservice to myself and others (it's annoying enough when I'm looking at talk page archives and don't see the section edit links, even while logged in). 「ダイノガイ千？！」^{(Dinoguy1000)} 19:23, 13 April 2009 (UTC)

←Section edit links aren't available to IPs on semi-protected articles (which is quite a few), but are still available to registered users. Maybe that was the confusion, Apoc...? --64.85.222.57 (talk) 12:07, 29 April 2009 (UTC)

True. But then again, it is the article that is protected, not the navbox. For protected navboxes, navbar has a noedit=1 option. There is (currently) no way to automatically hide the edit link for protected navbox templates. — Edokter • Talk • 12:37, 29 April 2009 (UTC)

Transcluding Issue

Hi, I'm attempting to transclude this template to a personal wiki. However, even after installing MediaWiki:Common.css and MediaWiki:Common.js, I'm still getting strings of code like "+1}}{{#if:|+1}}{{#if:|-1}}}} class="navbox-title" | {{#if:{{#switch:|plain|off=1}} {{#if:" when I view the template. I'm using this version of Navbox, and this version of Tnavbar. Somebody mind helping me out? Here's an image, if it helps. Thanks,  Aaron  ►  04:07, 9 April 2009 (UTC)

It looks like you need to install the ParserFunctions extension. 「ダイノガイ千？！」^{(Dinoguy1000)} 17:45, 11 April 2009 (UTC)

You are now my own personal Jesus Christ. But now it looks like I have to update my installation of MediaWiki; I'm still on 1.9.. Thanks!  Aaron  ►  23:58, 11 April 2009 (UTC)

Navbox rendering problem

Does Wikipedia have a limitation that you can't 2 of {{Navbox with collapsible groups. If so please remove it.

Because Template:Computer Science (this version) is having the problem and I don't know how to fix it. --75.154.186.241 (talk) 22:58, 17 April 2009 (UTC)

No, you simply forgot a 'group1 =' and 'list1 ='. — Edokter • Talk • 00:05, 18 April 2009 (UTC)

Oh thanks. Was too distracted by the "spacing" = Quotation rather than seeing the overall errors. --75.154.186.241 (talk) 05:08, 18 April 2009 (UTC)

Transferring this to Wikia

Hi! I'm a Wikia user, and currently, our Navboxs are too big. Text is too big. I noticed the text on this Navbox template is small, and more compact, and I was wondering if it's possible to transfer this code to Wikia, while not losing any functionality? If it is, please, leave a message on my talk page at the Castle Crashers Wikia. Thanks! 24.226.33.10 (talk) 03:11, 21 April 2009 (UTC)

Err, I figured out that we have a "style1", "style2", etc feature, and I've figured out, using "font-size:90%;" how to make the gtitle stuff smaller, but I can't figure out how to make the group area's bluish background width smaller, or how to make the group text smaller either. Again, if anyone can help, a link to my wikia talk page is above, leave me a message and we can talk. 24.226.33.10 (talk) 03:20, 21 April 2009 (UTC)

It sounds like you may not have the correct styles copied to your wiki. Compare your styles in your local Common.css file with those here (you should be looking for the various .navbox rules). 「ダイノガイ千？！」^{(Dinoguy1000)} 02:09, 22 April 2009 (UTC)

I have different question about transferring this template to Wikia: How do you turn on HTML Tidy? It seems to me that this software is a simple I/O program that runs on a computer, rather than a Wiki - not to mention that it has no easily accessible option to be turned on. Hue03 (talk) 19:16, 21 July 2009 (UTC)

If Tidy isn't already running on the Wikia you're trying to copy this to, you'll need to get in touch with a Wikia staffer to see about enabling it. In the meantime, there is a version of Navbox that doesn't require Tidy; see the box at the top of the page for a link. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 21:27, 21 July 2009 (UTC)

Tnavbar --> Navbar

The next time an admin edits this template, could you please also change Tnavbar to Navbar? {{Tnavbar}} has been moved to {{Navbar}} since its functionality was expanded to work in all namespaces, and {{Navbox}} is by far the cause of most of its usages. 「ダイノガイ千？！」^{(Dinoguy1000)} 02:04, 22 April 2009 (UTC)

Aah, never mind, it seems Happy-melon already took care of it. 「ダイノガイ千？！」^{(Dinoguy1000)} 02:32, 22 April 2009 (UTC)

Top margin

Just in case anyone's curious, an adjustment was just made to MediaWiki:Common.css to improve the margin on navbox stacks – discussion was here. —Werson (talk) 18:44, 26 April 2009 (UTC)

wikiclass

I think the Template:Navbox with columns should be transformed to class=" ". They are used more commonly as tables.

• Can you make the colfooter expandable

(not expandable as a collapsible group, rather just have a "show / hide" button.)

I would imagine a lot of footer are used for extra information (relevant topics) instead of below=, which provided additional information (meaning one product having 2 properties).

• class="wikitable sortable" able to be sortable.

Template:Deadliest_tornadoes_by_state can be transformed to a Navbox for easier maintainance. Also they really should have class="wikitable sortable" feature added.

• when making the colheader expandable, make it as the following

groupcol1-12header = {{class="";style=""; padding="" line-height:0em; width:0em; text-align:center;font-weight:normal;}}

• I think Template:Navbox Year should also be also be changed into a class also.

--75.154.186.241 (talk) 23:04, 8 May 2009 (UTC)

I really have no idea what you're asking. Other editors: please note that this IP was blocked for being a probable sock puppet. --CapitalR (talk) 23:41, 13 May 2009 (UTC)

Line break headache

My template seems to be acting up. When I place each entry to a list on a separate line (As opposed to having every entry on the same line separated by a space, as they are now), the result is for the most part satisfactory... Except that the first and last entries are on individual separate lines! What am I doing wrong? -- ʄɭoʏɗiaɲ ^τ _¢ 09:11, 14 July 2009 (UTC)

I think I can fix it for you, but I don't see why you are using {{!}} to insert pipes; bullets are used in many more navboxes and are much easier to read. Also I don't really understand why you used {{nowrap}} over and over; {{nowrap begin}} and {{nowrap end}} are superior in this case. → ROUX ₪ 09:17, 14 July 2009 (UTC)

Y Done I have less than no idea as to why it was doing that, had to try several different things before it would actually work. → ROUX ₪ 09:46, 14 July 2009 (UTC)

I'll be honest. I stole it from Jefferson County, Ohio. Thank you! :) ʄɭoʏɗiaɲ ^τ _¢ 15:32, 14 July 2009 (UTC)

Heh. Off to fix that one now.. → ROUX ₪ 17:47, 14 July 2009 (UTC)

Actually, there's no point in using any of the {{nowrap}} family with navboxes unless you are trying to keep something other than links from wrapping; all navboxes which use {{Navbox}} already have class="nowraplinks" which prevents links from wrapping. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:52, 14 July 2009 (UTC)

Please add "class" parameters

{{editprotected}} In order to facilitate the addition of microformats, please will someone with the necessary skill and knowledge add "titleclass" and "bodyclass" parameters, like those on {{Infobox}}? That will remove the need for this workaround I made after forgetting that the parameters are not already available. Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:39, 23 July 2009 (UTC)

Sandbox updated with what should work, if you'd care to test. Chris Cunningham (not at work) - talk 21:32, 28 July 2009 (UTC)

Thank you. I had to make one tweak, and it's now working. Please see if you're happy with that, or wish to make further changes, or implement it. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:54, 28 July 2009 (UTC)

Looks okay to me, though obviously it would be good to wait for further input before this is rolled out. Chris Cunningham (not at work) - talk 22:00, 28 July 2009 (UTC)

Ok. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:06, 28 July 2009 (UTC)

No comments, so I think we should go ahead, now. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:30, 30 July 2009 (UTC)

Y Done. Would one of you update the documentation please? — Martin (MSGJ · talk) 09:52, 30 July 2009 (UTC)

Thank you. Documentation updated. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:52, 30 July 2009 (UTC)

Semantic markup

I suggest to correct the semantic markup of the navbox tables. The groups should be marked up with th and the scrope attribute scope="row" as they function as heading for the lists. Also the empty rows which are only there for display reasons should be removed. Instead use the correct css styling (border-spacing). —Preceding unsigned comment added by 77.186.117.84 (talk) 22:54, 29 July 2009 (UTC)

Oh we stopped caring about semantic markup around the time we transitioned from div based navboxes back to tables (tables were easier to use). — Dispenser 23:02, 29 July 2009 (UTC)

I can't decide if this is supposed to be sarcastic or not. =/ At any rate, User:CapitalR is probably the go-to guy for modifications as drastic as what is proposed, as he developed the current navbox. More than likely, though, the proposed changes would require an extensive rewrite to avoid breaking anything and to maintain current functionality, and IIRC CapitalR has previously stated that he's not up to such work again. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 05:29, 30 July 2009 (UTC)

Using css-border spacing would be ideal, except that it doesn't work properly in all browsers (i.e. IE). I think there is now a way to get special css for just IE browsers for Wiki pages, but I don't have the time to go through and redesign the Navbox template to make use of this feature (though I'd be interested to see if anyone else can make it work). As for the th/td for groups, does it really matter? That could be fixed (with some corresponding changes to the default group css) if you want to do it. --CapitalR (talk) 18:33, 10 August 2009 (UTC)

Collapse in NAVBOX

I would like see if my idea is possible first of all, and then if anyone thinks it would be worthwhile. I find that many users mis-understand the collapsing and most just ignore it all together, so that very few use the state variable in order to make one navbox uncollapsed and just let the rest autocollapse (collapsed if there is more than one).

So this brings me to my point, could you make it work such that, if anyone sets the state variable to a certain "reserved word", that it would make the state be the code below? The code below is useful also, because it makes the state of the navbox uncollapsed when you view it directly (go to the template page itself).

My reasoning is that, then, a user can take any navbox transclusion and define the state (i.e. {{NASA navbox|state=uncollapsed}} won't work unless Template:NASA navbox defines state.) So, at least to make my life easier and I'm sure others, maybe the below could either be:

1. the default for state if it is not defined in a transclusion of navbox
2. if you set state to be 1, then it becomes the code below

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

I know this may seem unclear, but I am trying to describe it the best I know how. Please comment.

  Jonverve  ^{Talk  Contrib}  22:59, 29 July 2009 (UTC)

So you're asking for something like

{{navbox
| name  = Foo
| title = Foo
| state = 1
| ...
}}

where "state=1" is automatically expanded into state={{{state|<includeonly>autocollapse</includeonly><noinclude>uncollapsed</noinclude>}}}? Unfortunately, that isn't possible (except maybe with some subst coding that would be so convoluted as to not be worth the trouble). The only thing you can do is to manually add the specified code to each navbox as the need arises. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 05:33, 30 July 2009 (UTC)

Color usage

Has there ever been a color scheme for Navbox that isn't the ugly purple-blue that everyone uses? Or is that the only one people have bothered with? —harej (talk) 01:54, 10 August 2009 (UTC)

Template:Canada topics doesn't use it, largely because the default is so insipidly hideous. → ROUX ₪ 03:42, 10 August 2009 (UTC)

Canada topics looks terrible. /bashmore. Suggest less ugly coloration; I would personally like to see the greys of wikitables and the blues of Vector skin used. --Izno (talk) 03:51, 10 August 2009 (UTC)

Template:Canada topics indeed has egregious inconsistency (and poor color matching in general). I personally don't like gray. —harej (talk) 04:13, 10 August 2009 (UTC)

Egregious inconsistency? What on earth are you talking about? There are a total of two colours in the template--red and grey. The colour scheme was hammered out at WT:CANADA, so you can take the discussion there if you want it changed. → ROUX ₪ 14:49, 10 August 2009 (UTC)

Also white. Oh, it just looked inconsistent because of the alternating levels of indentation used. —harej (talk) 16:48, 10 August 2009 (UTC)

And those custom colours also lead to brilliant palettes such as at Interior Plateau#Further reading. But maybe we should choose a new colour scheme when move to the new Vector skin. I like the simple lines on white used by the Canada navbox, just replace the red with a more neutral dark grey. —Ruud 18:40, 10 August 2009 (UTC)

White doesn't provide enough contrast against the rest of the page, which is perhaps the (largest) problem with Canada topics (note that I do realize why [duh] those colors are used). --Izno (talk) 19:05, 10 August 2009 (UTC)

But should they contrast with the rest of the article? I'd say navigational boxes are secondary to the real article content. —Ruud 19:13, 10 August 2009 (UTC)

All that matters is that they're different from the article's intent. It's a matter of emphasis; we want to emphasize that the navbox is different from article content. This is why there's that subtle blue on non-mainspace pages and why the navigation is in grey... so on and so forth. --Izno (talk) 19:18, 10 August 2009 (UTC)

All this being said, are there other examples of the navbox not using the standard color scheme? —harej (talk) 19:33, 10 August 2009 (UTC)

I've seen quite a lot of them, usually when they are related to a country, television show, sports team or university. —Ruud 19:46, 10 August 2009 (UTC)

I am migrating some of my Wikipedia:Coordination listings over to Navbox, and I would like to know what good examples there are. —harej (talk) 20:05, 10 August 2009 (UTC)

(remains silent) —Ruud 20:19, 10 August 2009 (UTC)

Milhist has nice coloring to me, which is standard within the Milhist project. --Izno (talk) 23:46, 10 August 2009 (UTC)

Please don't migrate navbox templates en masse to custom colour schemes. if the move to the Vector theme means a rethink of our default colours then that would be excellent - they should not, however, be arbitrarily overridden because someone thinks the defaults are ugly. Chris Cunningham (not at work) - talk 11:51, 11 August 2009 (UTC)

To be sure, I want to be clear that that was not my intent at all. —harej (talk) 13:05, 11 August 2009 (UTC)

This drives straight to the main issue here: different people have different views on aesthetics. Personally, I quite like the current navbox color scheme, even though I do find it a tad dry/bland. I also find that most alternate schemes I see on individual navboxes are quite horrible, though I do spend a lot of time around anime/manga articles, where such color schemes tend to be eye-bleedingly bad anyways. I wouldn't be opposed to the development of a new, Vector-esque scheme, though, once Vector goes default. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:59, 11 August 2009 (UTC)

OMG, You idiot! They're not purple, they're blue! j/k See Template talk:Navbox/Archive 11#Get rid of purple. Also, I was working on a couple of test versions that have a different style: 1, 2, 3. Never got around to finishing them. SharkD (talk) 04:15, 12 August 2009 (UTC)

Vandalism?

All boxes on Wikipedia which previous had the ability to collapse are now open (including on talkpages) with the collapse capability disapeared? I tried to follow the trail and led back to here but there hasn't been an edit to this since July. Could somebody find out what has happened and fix it? - Yorkshirian (talk) 20:44, 22 August 2009 (UTC)

Probably due to a little screw-up in Common.js... should be fixed now. — Edokter • Talk • 22:29, 22 August 2009 (UTC)

Usability and Accessibility

Some testing by User:Dodoïste has opened up interesting aspects of the the navbox system (earlier discussion here and here).

I am currently setting up a fully functional demo of an improved navbox according to the suggestions below in my user space. It is almost working, I am just trying to figure out some details about the best way to import the new box js and css files. Cacycle (talk) 18:07, 23 August 2009 (UTC)

Please see a live demo with several of the suggested changes implemented under User:Cacycle/navbox demo. Please see the top of that demo page for installation instructions. This is just a demo and is meant to serve as a test bed to improve the Navbox template and to see the effects of proposed changes. Cacycle (talk) 21:07, 23 August 2009 (UTC)

I've dropped a note at Template talk:Navbar#Proposed navbox changes inviting anyone watching that template but not this one to come by and participate - just thought I'd keep everyone on the same page. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:53, 25 August 2009 (UTC)

I have just updated the User:Cacycle/navbox demo with suggestions from the discussions below. It is now possible for experienced users to always display all three edit links, the arrow is hidden from screen readers, some redundant tooltip text has been removed, and some styling and browser issues have been fixed. Cacycle (talk) 03:42, 31 August 2009 (UTC)

MS IE 8 does not display the arrow, I will fix this later :-( Cacycle (talk) 04:21, 31 August 2009 (UTC)

I have fixed the issue and will update the demo tonight or tomorrow. Cacycle (talk) 13:17, 2 September 2009 (UTC)

The fixed demo is now online, please update with Shift-Reload. Cacycle (talk) 01:26, 3 September 2009 (UTC)

vde

Personally I'm particularly concerned about the vde links and their position in the template. I think that the small test by Dodoiste is a clear indication that those should be moved from the top left to either top right, or should be hidden by default, because they are confusing novice editors, and that any usability accessibility improvement should start with this.

I have made a quick demo which shows the inverse of the show/hide and vde links: you can visit User:TheDJ/Navboxtest with importScript('User:TheDJ/Navboxtest.js') in your monobook script, and it will show this simple "inverse" of the two elements navigational elements. —TheDJ (talk • contribs) 15:28, 23 August 2009 (UTC)

I would think this would be best, though making that adjustment on our part would be strange, to say the least. --Izno (talk) 17:10, 23 August 2009 (UTC)

I suggest to have "view template · discuss template · edit template" at the bottom the Navbox, in uncollapsed mode. It feels logical to read the template before attempting to view, discuss or edit it. Dodoïste (talk) 22:31, 23 August 2009 (UTC)

List of capital cities of the European Union show

List of capital cities of the European Union hide

Example of content: Amsterdam · Athens · Berlin · Bratislava · Brussels · Bucharest

View template · Discuss template · Edit template

The usability testing (as well as my own experience) show that the vde links are confusing and user (=newbee) unfriendly (just try to hit the one-letter links with your mouse to get the tooltop that explains their function...). Therefore I suggest to move the [edit] link to the right, exactly as the section edits links that are already on the articles.

The "d" (talk page) links and the "v" (view) links confuse the majority of editors and are mainly catering to a very small number of experienced navbox hackers. Since all they do is to save one mouse click, I think we should make them optional, e.g. with user scripts, or to move them to the bottomn of the boxes (which might be a bit tricky as there is currently no common bottom element for the boxes). Cacycle (talk) 12:59, 24 August 2009 (UTC)

I think your solution is a good one. Since moving the links at the bottom of the template seems to be difficult to do, I support your solution. Dodoïste (talk) 13:35, 24 August 2009 (UTC)

I do hope a user script (preferably gadget, but for such limited utility, you may have a hard time pushing one through) to restore original vde appearance would be created after this? I can certainly understand the usability arguments behind the change, and support it because of them, but I'm quite fond of the current links (location- and text-wise), and personally would rather have the current functionality. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:34, 24 August 2009 (UTC)

First I wasn't so sure about changing vde -> [edit], but I have to say. I hardly ever use those things I think. I use edit mostly, and I could use popups to navigate to the template or discussion pages. If you don't have popups, it's just edit + one more click to get where you need to be. I think this could be a good idea. —TheDJ (talk • contribs) 11:56, 25 August 2009 (UTC)

Using just [edit] or [edit template] would be good as it would be the same style as all the other [edit] items in the articles. -- WOSlinker (talk) 10:19, 29 August 2009 (UTC)

List of capital cities of the European Union hide

Example of content: Amsterdam · Athens · Berlin · Bratislava · Brussels · Bucharest

[edit template]

The word "this" is redundant ("view template" not "view this template", etc.). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:10, 24 August 2009 (UTC)

Fixed, thanks. :-) Dodoïste (talk) 13:35, 24 August 2009 (UTC)

In the updated User:Cacycle/navbox demo it is now possible to always show all three edit links as [view • talk • edit] or [v • d • e] by adding the following CSS code to User:YourUsername/monobook.css (or User:YourUsername/vector.css): .navbarEditLinks { display: inline; }. I have also removed the redundant "this" from the tooltips. Cacycle (talk) 03:42, 31 August 2009 (UTC)

Tooltip

The other thing that we can easily tackle and definitely should do, is to add tooltips to the show/hide widget. The question is what should they read ? "Show hidden content", "Show folded content" "Show collapsed content" ? —TheDJ (talk • contribs) 15:28, 23 August 2009 (UTC)

Agreed. --Izno (talk) 17:10, 23 August 2009 (UTC)

"collapsed" is a technical term, "folded" is quite unclear. I support "hidden", it's the most used word. Dodoïste (talk) 22:55, 23 August 2009 (UTC)

"Show hidden content" is the best of the three; but why not just "show content"? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:05, 23 August 2009 (UTC)

The updated User:Cacycle/navbox demo still says "Click to show hidden content" and "Click to hide content". I tend to think that the "click" and the "hidden" parts are important because the button is somewhat disguised as normal text and it might not be immediately obvious to a novice what to do with it and what its function is. Cacycle (talk) 03:42, 31 August 2009 (UTC)

Move show/hide to center

The problem is see here is that it would affect the centering of the title, unless we add an equal sized span to the left. Seems somewhat convoluted. Anyone any good ideas ? —TheDJ (talk • contribs) 15:28, 23 August 2009 (UTC)

After playing around with the demo I do not see this as a problem, it simply looks good with the title followed by the show/hide button right next to it. Cacycle (talk) 01:34, 24 August 2009 (UTC)

You don't ? I have this. —TheDJ (talk • contribs) 11:36, 24 August 2009 (UTC)

That looks messy indeed. I think the controls should be grouped together and the title centered. — Edokter • Talk • 11:40, 24 August 2009 (UTC)

What browser do you use? I use FF 3.0 with Windows, and it's working fine. Dodoïste (talk) 12:03, 24 August 2009 (UTC)

Safari/Chrome and Opera have this issue, and I believe IE has the same problem, though I cannot check on that. —TheDJ (talk • contribs) 12:18, 24 August 2009 (UTC)

I am not sure what the problem is, the demo and the screenshot look about right. The distance between title and show/hide buttom might be a bit too big (at least in some browsers) but that can be fixed. From a usability standpoint, the only valid place for the show hide button is right next to the box title. The [edit] link should be on the right as this is the format used everywhere else on Wikipedia articles. And the alignment of these elements looks visually balanced to me. Cacycle (talk) 12:39, 24 August 2009 (UTC)

I would note that moving the show/hide link (as well as the other tweaks suggested to it) are going to require modifying the collapsible tables code in MediaWiki:Common.js. However, there are quite a few other things that use this code, so the different functionality should be provided behind an additional class or something, to ensure that other current usages don't change unexpectedly or break outright when/if these changes get rolled out. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:31, 24 August 2009 (UTC)

Good point. Do know about a template or box that could break? The only relevant changes made are moving the edit link to the right and the show/hide button next to the title. Cacycle (talk) 18:22, 24 August 2009 (UTC)

Well I was thinking about the FAQ at the top of the Village Pumps for instance. Those would look really messy if the show/hide widget would immediately follow the title all of a sudden. Some talk pages with multiple wikiproject boxes might have the same issue. Perhaps a new class called "midcollapsible" might be best. —TheDJ (talk • contribs) 11:44, 25 August 2009 (UTC)

Australian Open men's singles champions show

Wimbledon (Open Era) Gentlemen's Singles champions show

US Open men's singles champions show

Association of Tennis Professionals (ATP) World No. 1 players show

Tennis at the Summer Olympics · Olympic Champions in men's doubles show

Year-end championships winners show

I'm just wondering about moving the show button to the middle. It would mean that they are no longer aligned when there is more than one navbox shown. -- WOSlinker (talk) 18:02, 25 August 2009 (UTC)

You are right, this does look rather messy, compared to this. —TheDJ (talk • contribs) 11:40, 26 August 2009 (UTC)

showAustralian Open men's singles champions

showWimbledon (Open Era) Gentlemen's Singles champions

showUS Open men's singles champions

showAssociation of Tennis Professionals (ATP) World No. 1 players

showTennis at the Summer Olympics · Olympic Champions in men's doubles

showYear-end championships winners

If you're going to move the button to the side, please move it to the right, so it's after the title. This is a logical order for people reading left to right. Dodoïste (talk) 12:37, 26 August 2009 (UTC)

Australian Open men's singles champions show

Wimbledon (Open Era) Gentlemen's Singles champions show

US Open men's singles champions show

Association of Tennis Professionals (ATP) World No. 1 players show

Tennis at the Summer Olympics · Olympic Champions in men's doubles show

Year-end championships winners show

When using a wide window on a higher-res screen the show/hide buttons would be out of the context of the text or title. After all, this button is the only clue that there is something hidden and it would be difficult for a newbee to realize that it is actually hidden content related to the title, and not some mysterious unimportant wiki thing. Also, moving the button to the sides would make it difficult to select the correct one out of several and it would need a rather large mouse move action. Therefore, from a usability standpoint the link should be next to the title. Cacycle (talk) 13:18, 26 August 2009 (UTC)

The updated User:Cacycle/navbox demo still has the show/hide buttons next to the navbox title. I still think that it is important to have the button right next to the title for usability reasons, even if it can look a bit untidy for a few navigation boxes - but form follows function... Cacycle (talk) 03:42, 31 August 2009 (UTC)

Add an arrow to show/hide

I have no particular opinion on this. On the one side it's easier for some people to understand, others will say it is redundant. Perhaps a "uncollapse" upon hovering the titlebar is an idea ? I think that will help people a lot quicker. —TheDJ (talk • contribs) 15:28, 23 August 2009 (UTC)

It has bee suggested to use images for the up/down arrows because screen readers supposedly cannot read the charachters ▼ and ▲. I find this hard to believe and if still true they should fix the screen readers. We do not need images for the alt message, the title ("popup") attributes do the same trick. Images are problematic because their color cannot be changed easily and it feels wrong to use images for non-image content.

Beside that, in general I like to have the arrows to distinguish these show/hide "buttons" for dynamic changes on the page from real links like the edit link that leave the page. Cacycle (talk) 21:32, 23 August 2009 (UTC)

Most of the screen readers will read a lot of Unicode characters as a question mark. They are fixing this issue in the course of time. But should a screen reader read "triangle", "arrow", "increase"...? You get the idea: it depends on the context. With an image, we can provide alt text relevant in this particular context. However, as I told you, I will not insist too much on the image thing since it's complicated to implement. To improve usability is good enough for now. :-)

I have no idea whether the title ("popup") attributes is accessible or not, I'll try to find it out. Dodoïste (talk) 22:49, 23 August 2009 (UTC)

I did some googling. Properly set up screen readers should read the characters ▼ and ▲ as "black down-pointing triangle" and "black up-pointing triangle", that is their Unicode name. Both characters are part of the WGL4 character set which has bee supported by Windows since Windows 95 as far as I can tell. So they are definitely not "some random Unicode characters". Cacycle (talk) 12:42, 25 August 2009 (UTC)

I'll ask graham. —TheDJ (talk • contribs) 13:15, 25 August 2009 (UTC)

Both of those characters read as question marks for me in JAWS 8.0, which is a fairly recent version of the most popular Windows screen reader. Graham87 13:32, 25 August 2009 (UTC)

I just tested Apple's voiceover, and they skip the characters. —TheDJ (talk • contribs) 14:39, 25 August 2009 (UTC)

Hey Graham, thanks for testing. Do the screen readers read the title attribute popups ("Click to hide content")? Or is it better to have an image with an alt attribute for that? If not, we could replace the triangles with CSS background images. Cacycle (talk) 17:43, 25 August 2009 (UTC)

As said earlier, images can be bad because they have a fixed colour and since the title bar colour can be altered, some colour schemes will look bad. -- WOSlinker (talk) 18:07, 25 August 2009 (UTC)

I think this is a yet another good argument for why you shouldn't override the colour scheme of navboxen ;) Seriously, though, using images for things like arrows seems to be the current accepted practice in web design, is done by the Vector skin, and in my humble opinion just plainly looks better. —Ruud 20:13, 25 August 2009 (UTC)

Screen readers won't read title attributes in links by default. In that respect, it's better to use an image, but I would make the alt text just "Hide content" or "Show content", rather than using click here. Graham87 00:45, 26 August 2009 (UTC)

I'm seeing all these previews of the idea behind it, and I have to say, the arrow is excessive, especially when stacked. It draws the eye downward, rather than to properly reading the link. --Izno (talk) 13:54, 26 August 2009 (UTC)

The updated User:Cacycle/navbox demo has now full support for images and html constructs. In its default configuration it still uses ▼ and ▲, but these arrows are now invisible to screen readers (it uses :before { content: "▼"; }. Users of screen readers will miss the tooltip ("Click to show hidden content"), but still have the button text ("show"). In my opinion opinion an arrow is essential as the button itself is diguised as normal text and the arrow is the only obvious indicator that there is hidden content. Cacycle (talk) 03:42, 31 August 2009 (UTC)

I have just figured out that MS-IE 8 in MS-IE 7 mode does not support :before and therefore does not display the arrows. I will fix this during the next week. Cacycle (talk) 04:49, 31 August 2009 (UTC)

I have fixed the issue and will update the demo tonight or tomorrow. Cacycle (talk) 13:16, 2 September 2009 (UTC)

It's updated, it now uses a background image for the arrows. I have also added a button-style when hovering over show/hide to further clarify its function, I think this is better than simple underlining. Cacycle (talk) 01:26, 3 September 2009 (UTC)

First time I test this. IE6 throws a javascript error: "object doesn't support this property or method." Show/hide always shows with a border and the transparency doesn't work, possibly because it is generated after the IE6 transparency fix has run. All in all, I'm not so thrilled. — Edokter • Talk • 11:08, 3 September 2009 (UTC)

I have improved the compatibility for outdated MS-IE versions <= 6, please push Shift-Reload to update. I have fixed the border problem (span changed into anchor) and the transparency issue (MS-IE <= 6 now displays transparent gifs instead of png, with a bit more fiddling a transparency-fix png version can be created). I am not sure what triggers the javascript error, can anybody help out? Cacycle (talk) 19:14, 4 September 2009 (UTC)

Contrast

This really is a problem, but one that is much more difficult to fix I think. I suppose we best deal with this last. —TheDJ (talk • contribs) 15:28, 23 August 2009 (UTC)

What specifically needs addressing? "Contrast" is rather vague. --Izno (talk) 17:10, 23 August 2009 (UTC)

The background of the navboxes icw with the link and/or title colors can be an accessibility issue for those with visual impairments. Basically, more contrast is better, but there is a website that can help you qualify this. I just can't find it at this moment. —TheDJ (talk • contribs) 19:55, 23 August 2009 (UTC)

So you're specifically referring to the "th" colors (they aren't actually th's)? --Izno (talk) 20:11, 23 August 2009 (UTC)

Yes, specifically the HR elements background. For instance we have default background color #CCCCFF and the links (often the title itself is linked) within it have the blue color #3366BB . According to this calculator, this combination is not WCAG 2 AA compliant in smaller fontsizes and it is NEVER compliant with WCAG 2 AAA. And that is not a good thing. If the title is in black instead of being linked, then everything is fine. —TheDJ (talk • contribs) 20:17, 23 August 2009 (UTC)

I think this may be a case for CSS, as there's very little that will go with blue (in the range of Wikipedia's color palette) without the bg being white, which I think isn't enough of a contrast to the rest of the article. I don't think it would be a good idea to change the link color to black though... dark grey, maybe? Changing link colors is in itself a bad idea... ugh. --Izno (talk) 20:38, 23 August 2009 (UTC)

Finding an appropriate color for the backgroud is surely difficult to do. I don't think the Navbox needs some kind of contrast to the rest of the article. No good website does anything like that. On the contrary, they try to be as homogeneous as possible. I think we should do the same, and use as few colors as possible. But if you want to use color, why not changing the border then? Here are a few random ideas. Dodoïste (talk) 21:48, 25 August 2009 (UTC)

List of capital cities of the European Union show

List of capital cities of the European Union show

List of capital cities of the European Union show

I have no opposition to grey, but what you say is against the idea that the navbox is a navigation tool. Consider the categories bar... and the sidebar in Vector. Even in monobook, there is a very distinct separation of the sidebar from the main article content by a very thick background image (padding/margin, depending on viewpoint). I personally don't want to see the color change at all, but I for one agree that there is a need to change the current color for accessibility reasons. --Izno (talk) 21:58, 25 August 2009 (UTC)

Template:Canada topics is the best solution, IMO. Do not forget the Navbox is already a table and has a border, it makes already a lot of differences to the rest of the article. Adding more contrast would be overdoing, which is no good either. Dodoïste (talk) 10:21, 26 August 2009 (UTC)

We've already gone over canada topics before. It looks horrid. The current coloring of Navbox is fine, aside from usability reasons. --Izno (talk) 13:51, 26 August 2009 (UTC)

List of capital cities of the European Union show

List of capital cities of the European Union show

OK, here are the two things we need to do. The color used by Cacycle in his User:Cacycle/navbox.css is a lighter blue (#0645AD) than the usual blue of the links (#002BB8). First of all, we need to use the usual #002BB8. Then, in order to provide enough contrast with the rest of the article, but not too much either, I suggest #ECECFF background (WCAG 2 AAA Compliant, contrast ratio of 9.62) or #0F0F0F (WCAG 2 AAA Compliant, contrast ratio of 9.84). The second one, #0F0F0F, is the color chosen for boxes background by the Usability Initiative, as explained in the Babacco color scheme. Dodoïste (talk) 09:49, 29 August 2009 (UTC)

The button text color that is used by the User:Cacycle/navbox demo is the default link color of the vector skin,  #0645ad , which is actually darker than  #002bb8 , the color you suggest. Cacycle (talk) 03:42, 31 August 2009 (UTC)

What I actually meant is  #002bb8  shows a better contrast to the background than  #0645ad , according to the Color Contrast Analyser. Dodoïste (talk) 21:40, 31 August 2009 (UTC)

Lists

Many navboxes include lists, but without them being marked up as lists (often, they're just text, separated with bullets or other such characters). I created {{Flatlist}} as a first step toward resolving this, but more work - especially on the aesthetics - is needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:37, 23 August 2009 (UTC)

Updated JavaScript

I have partially rewritten the JavaScript code behind the collapsible tables a few weeks ago. See http://www.ruudkoot.nl/wiki/MediaWiki:Common.js . It also supports images, which may be preferable over using some random Unicode character as an ad-hoc arrow (might not be available on al browsers.) Is there any interest in this code? I'm very busy until next Friday, by I could finish/make requested changes the following week. Cheers, —Ruud 20:11, 24 August 2009 (UTC)

I will add the image support to the demo code as this might be an interesting styling/skinning option on other wikis. But ▼ and ▲ are not "some random Unicode characters", both characters are part of the WGL4 character set which has been supported by Windows since Windows 95 as far as I can tell. Please see also the discussion above. Cacycle (talk) 12:48, 25 August 2009 (UTC)

It might be a good idea to use the same arrow (image) that the Vector skin uses? —Ruud 14:09, 25 August 2009 (UTC)

The updated User:Cacycle/navbox demo has now full support for images and html constructs (it now uses the title attribute instead of the caption text to detect the button's state). Cacycle (talk) 03:42, 31 August 2009 (UTC)

Expand first when many

When 2 or 3 navboxes are stacked there with autocollapse, expanding the first template is best option. All being collapsed doesnt look good. The first template at top of the stack generally most suitable - expanding this would be appropriate. Wikicode already sees if more than 1 template is present and collapses it, so making only first expnaded with others collapsed should not be difficult to implement. Doorvery far (talk) 09:45, 25 August 2009 (UTC)

Which template should be on top of all will be decided by editors of individual articles. Doorvery far (talk) 09:46, 25 August 2009 (UTC)

I kinda like this idea, shouldn't be too difficult to implement I imagine. We have to check if the parent of a collapsible box is a navbox. Since we already might have to do some "special case" for navbox collapse code due to other issues, this might actually be pretty feasible. —TheDJ (talk • contribs) 11:38, 25 August 2009 (UTC)

Another option which we can consider (although I would probably oppose it myself) would be to uncollapse a navbox when hovering the mouse over the title bar. —Ruud 20:16, 25 August 2009 (UTC)

I would oppose that as well. I'm not terribly fond of mouseover effects in general, but at least most of them are limited to "cutesy" background highlighting or mildly annoying image changes. A user mousing over a navbox title and having the thing expand all the sudden, though, would be surprised (and arguably traumatized in a few, rare cases) by this highly unusual behavior. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:55, 25 August 2009 (UTC)

JavaScript's accessibility

A french accessibility expert had a look at this script, and said it was overall good. A detail should be fixed though : onclick should not be used with span img or div element, per W3C's WCAG 2.0 guideline. W3C explains what to do in SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons. Thanks Cacycle. :-) Dodoïste (talk) 22:42, 14 September 2009 (UTC)

We should keep on going forward

Although we disagree on several details, there is a clear consensus on the main ideas:

1. Be it an image or an Unicode character, the arrow before the button (show / hide) is really needed
2. The button should be next to the title
3. Replace "v d e" by "edit", and provide a gadget for those who like "v d e"

The other things are details that can be fixed later on, so I suggest to push forward. What is the next step ? Should we begin a straw poll, or some kind of vote ? Yours, Dodoïste (talk) 15:02, 2 September 2009 (UTC)

Um, I see no consensus on where we're moving the button, and no-one has said that the arrow is "really needed"; from what I can tell, it is simply a case of "if we're going to do that, then it needs to be this way" rather than "I prefer that we add/don't add an arrow". Similarly, I don't know that three editors deciding to change "v d e" to "edit" is a good idea given the extensive use of the style. I agree that this discussion should be advertised in a better format, as these are fairly large, different, and even numerous changes. The options need laying out with context from this discussion. --Izno (talk) 16:47, 2 September 2009 (UTC)

Okay. I suppose I was dreaming of a consensus so badly that I actually saw one. :D My mistake.

I am not familiar with the english-speaking wiki, I don't know where and how to continue the discussion. Could somebody do it for me ? Thanks a lot. :-) Dodoïste (talk) 21:58, 2 September 2009 (UTC)

There is no need to rush, let us discuss it a bit longer here and also use the time to get a working demo which may actually take some time. Cacycle (talk) 01:26, 3 September 2009 (UTC)

I love mouseover effect you recently added to the button. Well, the discussion seems to abandoned to me, it makes me sad. I am thinking about leaving a message at Wikipedia:Village pump (proposals), do you think it's a good idea ? Dodoïste (talk) 09:31, 12 September 2009 (UTC)

We have to make our homework if you don't want to see this dying a quick death... That means that we should have a fully functional and final demo, a summary why we need to change this (nobody will read through the whole text above before commenting), and an explanation what has changed and why. Before going public (e.g. by inviting people over from Wikipedia:Village pump (proposals) or discussing it there) we must have a detailed proposal and, in case a poll will be involved, fully worked out poll questions. We could work out these details on User_talk:Cacycle/navbox_demo with everybody who is interested as thas might be too spammy for this page. Cacycle (talk) 01:44, 15 September 2009 (UTC)

OK, we'll do it that way. :-)

Oh, did you see this comment about the JavaScript accessibility ? Because when you replied, you seem to have removed that comment. Yours, Dodoïste (talk) 08:11, 15 September 2009 (UTC)

Ooops, I must have edited an old version. It's now back. Cacycle (talk) 12:43, 15 September 2009 (UTC)

I've just started a pool on fr.wikipedia. It is going quite well until now. In about two weeks, you script may be running on fr.wiki. :-) Dodoïste (talk) 16:40, 21 September 2009 (UTC)

Child navbox bold groupname

Group headings in Template:Navbox#Child_navboxes should not be bold. It looks too much contrast both because it is in center of template and background is lighter compared to main navbox group name (which is bold but not intrusive). This hides current transcluded article link that is being bolded, so difficult to navigate. So it can be either un-bolded (best) or color can be changed to gray from black. Doorvery far (talk) 09:45, 25 August 2009 (UTC)

I disagree. Groups headers are table headers and should be bold. They alo have a blue background, so that should negate any confusion about the current page. — Edokter • Talk • 11:01, 25 August 2009 (UTC)

Background is light blue, not blue - so the contrast is high. So it should be light black that is gray, otherwise non-bold. 218.248.39.98 (talk) 11:25, 25 August 2009 (UTC)

Installation of Navvar

I've followed the above instructions but I am having no luck.

Im getting this displayed, here is a simple snippet: !--

Please do not edit without discussion first as this is a VERY complex template.

--table class=navbox cellspacing=0 !--

--style=;trtd style=padding:2px;!--

--table cellspacing=0 class=nowraplinks  ;;!--

Everything is installed accordingly. So I think.

I have followed http://en.wikipedia.org/wiki/Template_talk:Navbox

along with

http://en.wikipedia.org/wiki/Template_talk:Navbox/Archive_8

But both with no luck. Any help would be great? —Preceding unsigned comment added by Colinliu2009 (talk • contribs) 11:02, 26 August 2009 (UTC)

Hello Colinliu2009, could you provide a link to the copy of navbox you attempted to install? If I can see the problem in action, I should be able to better help you. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 16:42, 26 August 2009 (UTC)

Hi, Here is the link - http://www.fcoproto.com/basic_wiki/index.php/Template:Navbox. Thanks

All < and > characters have been stripped off! Copy and paste the templates from Wikipedia. Make sure there is no weird security filter in place. Cacycle (talk) 16:01, 27 August 2009 (UTC)

Don't copy and paste. Use the transwiki process to export an xml of {{navbox}} and make sure to check the box marked 'get all dependencies' (or whatever it says). → ROUX ₪ 16:12, 27 August 2009 (UTC)

I thought the GFDL was satisfied as long as a link to the page history was provided? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:33, 27 August 2009 (UTC)

I've done that, using transwiki, the urls being http://en.wikipedia.org/w/index.php?title=Special:Export&history=1&action=submit&pages=Template:Navbox to Export But it is not working. The HTML is not rendering correctly.

Are you guys using the link as it says or Special:Export?

Can I assume the article name is correct too? I notice the XML is different when u export it using the Special:Export compared to using the url approach. Colinliu2009 (talk) 16:29, 27 August 2009 (UTC)

Use the Special:Export system and download the XML file it gives you. Then on your own wiki, use the import function. → ROUX ₪ 16:32, 27 August 2009 (UTC)

I have done that. character entities appear in place of < > in all the <text xml:space="preserve"> I assume that is correct? Colinliu2009 (talk) 16:38, 27 August 2009 (UTC)

Did you select 'save as file' on the special:export page? → ROUX ₪ 16:41, 27 August 2009 (UTC)

Yes. An example of my file is: http://www.fcoproto.com/basic_wiki/Wikipedia-navbox.xml. Do I need to install and additional extentions of ParserFunction.php? Parser is 1.1.1 for WM 1.15.1. Colinliu2009 (talk) 16:47, 27 August 2009 (UTC)

And you imported the file using Special:Import on your own wiki? → ROUX ₪ 16:49, 27 August 2009 (UTC)

Yes. http://www.fcoproto.com/basic_wiki/index.php/Special:Import . Thanks for ur quick reply Roux. CSS, JS, Tbar, NavBox, exported, including all the ones mentioned, http://www.mwusers.com/forums/showthread.php?t=9166. Tidy enabled, JS enabled, Parser included......

Using -> http://en.wikipedia.org/wiki/Special:Export

Template:Tnavbar

Template:NavBox

MediaWiki:Common.css

MediaWiki:Common.js

Checked all three checkboxes and imported. Appreciate any more info Colinliu2009 (talk) 16:59, 27 August 2009 (UTC)

Anyone? I upload NavBox on another server and there were no errors, no xml_parse warnings, and importantly NavBox worked. With this server, NavBox XML displayed xml_parse errors. The import.php $parents variable had an empty value!!! Colinliu2009 (talk) 16:25, 28 August 2009 (UTC)

HTML5— cellspacing

With the push towards HTML5...

The attribute cellspacing is not allowed within table.[1] Just a plain {{navbox}} renders as:

<table class="navbox" cellspacing="0" style=";">
<tr>
<td style="padding:2px;">
<table cellspacing="0" class="nowraplinks" style="width:100%;background:transparent;color:inherit;;"></table>
</td>
</tr>
</table>

Which gives two validation errors. ---— Gadget850 (Ed) ^talk 17:22, 21 September 2009 (UTC)

With HTML5 still a draft, and no adequate CSS alternative, there's no rush remove them just yet. — Edokter • Talk • 22:44, 21 September 2009 (UTC)

HTML 5 may be labelled a "draft", but that's a technical nicety - it's ready for use on live websites. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:50, 21 September 2009 (UTC)

I'll echo with Pigs noted. You'll note that the MW devs are starting to move toward html5... --Izno (talk) 06:04, 22 September 2009 (UTC)