Template talk:Navbox/Archive 12

Archive 5

←

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

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)

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://wiki.riteme.site/wiki/Template_talk:Navbox

along with

http://wiki.riteme.site/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://wiki.riteme.site/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://wiki.riteme.site/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)

Question about article layout

Do navboxes go on the very bottom of an article? What about the stub templates? Which goes on top? Just wondering if there is a standard.--Breandán MacAmhlaidh (talk) 09:41, 26 September 2009 (UTC)

OK, i guess the stub templates go at the end, according to this Wikipedia:Stub#How_to_mark_an_article_as_a_stub.--Breandán MacAmhlaidh (talk) 09:43, 26 September 2009 (UTC)

My personal rule of thumb is that navboxes always go directly above any categories or DEFAULTSORT on a page. I have no idea if there are any actual recommendations, though. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:04, 26 September 2009 (UTC)

That is the rule I think. It's probably jotted down 'somewhere' in one of our many Manual of Style guidelines. —TheDJ (talk • contribs) 10:57, 28 September 2009 (UTC)

ru intervik

Шаблон:Navbox --JukoFF (talk) 07:45, 7 October 2009 (UTC)

 Done. Note that you can edit the documentation yourself to add interwiki links. =) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:55, 7 October 2009 (UTC)

:) JukoFF (talk) 14:14, 9 October 2009 (UTC)

Show/Hide not showing in IE on Afrikaans Wikipedia

I've requested and guided an administrator of the Afrikaans Wikipedia at af.wikipedia.org to add the necessary styles and functions to Common.css and Common.js respectively. Navbox show/hide now works on the Afrikaans Wiki in Safari 3.2.1, Opera 9.6.4, Google Crome 3.0.195.27, and others, EXCEPT on INTERNET EXPLORER (show/hide not visible). You may test my example here: Navbox Example on af.wikipedia.org. Is it possible that the problem might be with /* Scripts specific to Internet Explorer */ being absent from the Afrikaans Common.js, or is it due to another problem? I’ll appreciate anyone’s help to get the IE Navbox show/hide problem solved at af.wikipedia.org. Best regards. --Wordscape 21:00, 22 October 2009 (UTC) —Preceding unsigned comment added by Wordscape (talk • contribs)

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 there is an important mistake to fix. Blind users cannot use the show/hide button with the keyboard. It is important to fix it, because users like Graham87 would not have access to the content of the navbox with this new script. 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) 15:46, 7 November 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)

25 users took part in the pool, and they all agreed on our proposal (100% support). A french accessibility expert should improve the script before deployment, since it is not keyboard accessible. It's taking time... sight! But it's overall going well, and hopefully deployment will come one day. :D Dodoïste (talk) 13:22, 14 October 2009 (UTC)

Listpadding

Okay maybe this is a beginner's question but I typed "listpadding" into search and turned up next to nothing. My question is how does one pad or introduce spacing on the level of the list in a navbox? I think I understand the titlestyle, abovestyle, and belowstyle padding-left:1em; padding-right:1em; switches but I don't get the listpadding switch. Is there an example of how it is properly used? —Preceding unsigned comment added by Lambanog (talk • contribs) 21:25, 27 October 2009 (UTC)

Listpadding controls the padding around the text in the lists of the navbox. It is only there to enable padding, as the liststyle has trouble applying padding to the list cells. So put any CSS styling in liststyle, except padding; put that in listpadding. — Edokter • Talk • 00:15, 28 October 2009 (UTC)

Could you refer me to an example of a template that clearly shows how it is used? I tried experimenting with it but on my own but cannot seem to get it to work the way I want. Thank you. Lambanog (talk) 10:01, 28 October 2009 (UTC)

(←) I don't know of any navbox that actually uses it, but here's a demo (hit edit to see the source):

— Edokter • Talk • 12:56, 28 October 2009 (UTC)

Thank you very much for the example. Listpadding seems to affect the padding from all sides: left, right, top, and bottom so is unsuitable for what I had in mind. I think I have found a way to do want with the "col" switch so I'll look further into that. Thanks again. —Preceding unsigned comment added by Lambanog (talk • contribs) 10:10, 29 October 2009 (UTC)

You can set padding for each side, ie: padding-left: 1em;. — Edokter • Talk • 12:44, 29 October 2009 (UTC)

Sorry I don't quite get what you are saying in your previous comment. When referring to "padding-left: 1em;" are you saying that can be applied to the "list" area or when using "col"? What I want to do is to align the comments in the list section so that it is centered under the title heading. I know how to move the title over a centered "list" item but am unsure how to move the "list" item under a centered title. I've tried my interpretation of your instructions and it didn't do anything. I've commented it out in the example above. If it's very simple can you alter the above example to center the list item under the title? Thank you.Lambanog (talk) 14:11, 29 October 2009 (UTC)

Ack, forget about that. Perhaps you can try liststyle = padding-left: 20em;. But that won't guarantee absolute centering, so maybe liststyle = text-align: center; padding-right: 6em; will do the trick. However, the simplest way to center the list is by not using a group. — Edokter • Talk • 15:02, 29 October 2009 (UTC)

Okay so what I thought made sense earlier using liststyle does work at least in some cases. But the help section states:

"Due to complex technical reasons, simply setting "liststyle=padding:0.5em;" (or any other padding setting) will not work."

Hmmm... anyway... thanks again! In case I haven't said it enough.

A closer look and I notice strange things happening with the v d e on my title padded examples. Sigh. — Lambanog (talk) 16:53, 29 October 2009 (UTC)

Simply waaay too much padding there. — Edokter • Talk • 17:47, 29 October 2009 (UTC)

Inconsistent behaviour of listn parameters

{{editprotected}} I found out that if I want to use this template with every item in a list on its own line, it renders incorrectly, but not for list1. E.g.:

{{Navbox
|list1=
foo
bar
baz
|list2=
foo2
bar2
bar2b
baz2
}}

This is because there is a linebreak before and after {{{list1}}}, but those linebreaks aren't around the rest of listn parameters. For some reason, Mediawiki encloses all lines inside <div> inside a <p> except the lines that contain the starting <div> and the ending </div>. So, I request that all lines in the form of

 --><div style="padding:{{{listpadding|0em 0.25em}}}">{{{listn}}}</div></td></tr>}}<!--

to be changed to

 --><div style="padding:{{{listpadding|0em 0.25em}}}">
{{{listn}}}
</div></td></tr>}}<!--

where listn is from list2 to list20. Svick (talk) 16:00, 9 November 2009 (UTC)

See below. This fix would introduce linebreaks above and below the data, adding unwanted padding. I guess this is where the aforementioned "<span> hack" is rooted. Navboxes were not intended to contain lists, but if you must, use "*", ":" or "<br>" to format them. — Edokter • Talk • 02:40, 11 November 2009 (UTC)

That's not what I meant. I meant having the code formatted vertically, but the resulting HTML without linebreaks (the same way navbox is formatted usually). Svick (talk) 09:31, 11 November 2009 (UTC)

Request disabled, as it seems this is not 100% straightfroward and needs some discussion. — Martin (MSGJ · talk) 10:35, 11 November 2009 (UTC)

group1 height

I've noticed in the last few days that the height of group1 is more than the other groups when it wasn't before. I noticed there was an edit a few days ago that may have caused this but I don't want to revert it in case it was done for a good reason. Can anyone fix this? Thanks. AnemoneProjectors (talk) 01:00, 11 November 2009 (UTC)

MZMcBride added linebreaks in the template, causing empty lines above and below the text in the first list. I can only guess the reason why the linebreaks were introduced; his summary "to kill the <span> / <span /> hack" could use some explaining. I've reverted for now. — Edokter • Talk • 02:34, 11 November 2009 (UTC)

Is there an example of the line height issue? --MZMcBride (talk) 03:12, 11 November 2009 (UTC)

Never mind. I see what you're talking about. Templates like this one have a bad linebreak. {{{list1}}} needs to be evaluated on its own line because wiki-table syntax ({| class...) doesn't work if it's not at the beginning of the line. People have been using a <span/> hack to work around this, but that's not really the right answer. (It's invalid markup and people shouldn't be resorting to hacks.) Any objections to re-reverting? --MZMcBride (talk) 03:21, 11 November 2009 (UTC)

A bit more info regarding the linebreak in Template:The X Factor:

foo<br>bar



bab
<br>hey

produces:

<p>foo<br />
bar</p>
<p><br /></p>
<p>bab<br />
hey</p>

--MZMcBride (talk) 03:30, 11 November 2009 (UTC)

Can we still test a bit more? I now understand the reason {{{listN}}} needs to start at a new line, but it needs to be done without introducing linebreaks in the html output. It's also clear that a linebreak after {{{listN}}} in not needed. I'm going to test some scenarios in the sandbox. — Edokter • Talk • 12:48, 11 November 2009 (UTC)

Also, can you point me to a template that uses the span hack? — Edokter • Talk • 12:54, 11 November 2009 (UTC)

I think that linebreaks have to be both before and after {{{listN}}}:

Wikicode in template	Expanded wikicode	HTML	Renders as
<div>{{{listN}}}</div>	<div>foo bar baz</div>	<div>foo <p>bar</p> baz</div>	foo bar baz
<div> {{{listN}}}</div>	<div> foo bar baz</div>	<div> <p>foo bar</p> baz</div>	foo bar baz
<div> {{{listN}}} </div>	<div> foo bar baz </div>	<div> <p>foo bar baz</p> </div>	foo bar baz

Only the last alternative renders correctly. But I don't understand what is the problem in Template:The X Factor. It seems to me that it doesn't matter wheter the <br> is on a new line or not, it renders the same in both cases, no? Or do the linebreaks cause problems in other cases? Svick (talk) 17:18, 11 November 2009 (UTC)

The above sample doesn't actually makes much sense... Technically, the first example should not have linebreaks. I am also very puzzled why <p> and </p> keeps being inserted. Having said that, I do not see a problem in {{The X Factor}}. Using <br> for a new line is correct use.

As for the <span/> hack, moving {{{listN}}} to the next line fixes that; there is no need for a trailing linebreak, as that is what was causing the unwanted <p> tags. So I moved all list parameters to the next line in the sandbox; the code is ready to be made live. — Edokter • Talk • 21:45, 11 November 2009 (UTC)

Right now, the unfixed version of Template:The X Factor (with <br> on a new line) does't work and I think it should (and I don't understand how could it not work with MZMcBride's version). Also, I think it is better to format long lists each item on its own line to make editing them little easier. This style is used e.g. in Template:Airlines of the United States and the list has to be enclosed in <div> to work properly. For this two things to work, line break newline after {{{listN}}} would have to be inserted and you are right that this would enclose all lists in <p>, but I don't think it would cause any problems. Svick (talk) 22:21, 11 November 2009 (UTC)

The unfixed version behaves as expected actually... adding a newline followed by a linebreak (<br>) will force a paragraph. Remember that within any block element, normal wikimarkup rules apply; one of them being that two linebreaks are converted to a paragraph. Now, {{Airlines of the United States}} actually shows a bug in Mediawiki, in which the entire list of newline-seperated items is wrapped in one paragraph, except the last line. Why this happens, I don't know. There's probably already a bugreport on this. Still, using newllines is not really the recommended way of formatting the source. And it certainly does not warrant adding linebreaks in navbox just to comply with bad formatting, as we've already seen that creates more problems then it solves. — Edokter • Talk • 02:18, 12 November 2009 (UTC)

That's not correct. In normal circumstances the code

foo
<br>bar

doesn't force a new paragraph, just a linebreak. Two newlines (not <br>s or newline and <br> ) do that. And the way Template:Airlines of the United States behave when you remove the <div>s is the same as in my table above in the second row, so it would be fixed by adding the newline. I finally understand now, what was AnemoneProjectors complaining about: the <p> causes bigger top and bottom margins for all lists, and this is the only problem I think this solution has. Svick (talk) 08:21, 12 November 2009 (UTC)

Sorry, I'm not going to add the linbreak for that reason. You've seen the extra margin being generated, and that is not acceptable. Whatever is causing the '<p> bug', it needs to be fixed somewhere else. Until then, you can very simply work around it by using <br> for formatting. — Edokter • Talk • 13:00, 12 November 2009 (UTC)

Okay. Svick (talk) 13:09, 12 November 2009 (UTC)