Template talk:Navigation

From Wikipedia, the free encyclopedia

Add issues below as you see fit, sign with ~~~~

Contents 1 Using {{PAGENAME}} 2 "templateName" 3 Header not centered...? 4 Triangle? 5 What were these edits for? 6 Protected 7 Question 8 Header background 9 Survey: Titlebar's default background colour 9.1 The current faint grey (#eee) 9.2 Previous/original light blue (#ccccff) 9.3 Something else (suggestions?) 9.3.1 Some colors from Tango Desktop Project [4] 10 [Show]/[Hide] 11 Show as default 12 Doesn't work in classic skin 13 Changes to protected template 14 Is there any decency? 15 v-d-e 15.1 Tnavbar 15.2 [hide] link attached to header, and proposed layout change 16 autocollapse 17 LEAVE THE TEMPLATE ALONE!!! 18 Request unprotection 19 Custom background colours 20 Please allow the state= parameter. 21 cat(egory) parameter

[edit] Using {{PAGENAME}}

Unfortunately, as per the discussion on Template talk:Tnavbar#Propose to remove the parameter, you cannot put "{{PAGENAME}}" directly on this template either. As of now, if you go to an article where this template is transcluded and click on the "e" link on the template, you will find that the article's title would come up instead. Therefore, I will have to add some sort of TemplateName parameter here like Template:Tnavbar and those other similar templates. Zzyzx11 (Talk) 06:46, 5 August 2006 (UTC)

[edit] "templateName"

Might a friendly bot owner be asked to replace all instances of "templateName" with "name"...?  Lengthwise, "name" resembles the other parameters, i.e.

{{Navigation
|name   = 
|header =
|body   =

Hopefully, David Kernow (talk) 00:47, 31 October 2006 (UTC)

Perhaps. For now I recommend a dual solution. Both name and templatename will do the same thing. --Cat out 16:12, 31 October 2006 (UTC)

"name" as an alternative looks an ideal accommodation – thanks! David (talk) 02:04, 1 November 2006 (UTC)

[edit] Header not centered...?

Despite the "float:left;" style, the header does not appear to be centered; cf, for example:
{{Nordic Council}}
Assistance, please...? Thanks, David Kernow (talk) 13:19, 31 October 2006 (UTC)

Please do not use images on the top bar like you have. It causes more problems than its worth. --Cat out 16:15, 31 October 2006 (UTC)

But images in the titlebar don't seem to be the cause of this problem, e.g. the title in the template above still doesn't appear to be centered...? David (talk) 02:07, 1 November 2006 (UTC)

How about a split header: left 10% v·d·e, center 80% Title, right 10% [Hide]? ~ trialsanderrors 20:02, 1 November 2006 (UTC)

Sounds a reasonable approach to me; I'd try to implement it myself, except I'm wary of messing up the call made {{Tnavbar}}. Can you implement it...? (Cool Cat...?) Regards, David (talk) 05:16, 3 November 2006 (UTC)

From what I've tried the coding for the [Hide] box is in the CSS class "navbox collapsible autocollapse", and I don't know where that is being edited. ~ trialsanderrors 05:51, 3 November 2006 (UTC)

Yes, what I've just deduced before returning here... Maybe there's some clue in MediaWiki:Common.css...? David (talk) 06:02, 3 November 2006 (UTC)

Yeah, although it's actually at MediaWiki:Monobook.js (Search for "Hide"). No programmer listed, so I guess I have to take my complaint to the village pump. ~ trialsanderrors 06:16, 3 November 2006 (UTC)

What you have to do is set the position property of the container to relative, and set the position of the aligned child absolutely. e.g.

Left-aligned text Centered inline text

Lorem ipsum dolor sit amet · The quick brown fox jumps over the lazy dog · asdf

Cheers. --DavidHOzAu 10:59, 3 November 2006 (UTC)

Actually to me (using IE6) the centered inline text is superimposed on the left-aligned text. ~ trialsanderrors 18:10, 3 November 2006 (UTC)

Thanks for your example, DavidH; I've copied it to my user page for future reference if/when required. Meanwhile, the {{Navigation}} header now seems to be cent/ered correctly here (PC, WinXP, old Firefox (1.0.7)). Regards, David (talk) 22:46, 3 November 2006 (UTC)

Fixed. The first div in the header needed to be set to 100% width. Should work on all browsers now. --DavidHOzAu 06:04, 4 November 2006 (UTC)

Note that this fix may introduce unwanted sideeffects (double height header) using the current classes of the table. --DavidHOzAu 06:20, 4 November 2006 (UTC)

Note that toccolours is not subject to this bug. --DavidHOzAu 06:21, 4 November 2006 (UTC)

[Reset indent] Works here now. Btw, the problems with the collapse function seems pretty endemic. See e.g. the navboxes at the bottom of Marie Curie. I get to header lines, but now [Show] tag or ∆ to open them. ~ trialsanderrors 06:42, 4 November 2006 (UTC)

Perhaps because Marie Curie and related articles do not use this template? Just a thought. :D --DavidHOzAu 08:16, 4 November 2006 (UTC)

Oops, yes, I figured out that the problem was with the encoding in the article, not the templates. Fixed. ~ trialsanderrors 19:25, 4 November 2006 (UTC)

[edit] Triangle?

Why do we have an ugly triangle instead of the links? --Cat out 21:05, 4 November 2006 (UTC)

I'm not happy with it but I think it's better than the [Hide]/[Show] boxes right next to the header. But there should least be an alt-tag labeling the up triangle as Hide and the down triangle as Show. I don't think they are self-explanatory. ~ trialsanderrors 21:24, 4 November 2006 (UTC)

It's an interim solution until I find a way to get the show/hide button displayed on the right-hand side on both Internet Explorer and other browsers (everything I tried o far resulted in either the show/hide button being displayed left of the caption in IE or on a separate line on other browsers.) Browser detection would work but I'd rather work out a more elegant solution. —Ruud 20:48, 5 November 2006 (UTC)

The problem is that the button is a span tag that's floated to the right. This produces all sorts of problems, such as shifting the heading text slightly to the left in Mozilla and appearing first in IE. Ideally, the javascript should do something like this:

var Button     = document.createElement( "span" );
var ButtonLink = document.createElement( "a" );
var ButtonText = document.createTextNode( collapseCaption );

Button.setAttribute( "style", "position: absolute; right: 0.5em" );   // instead of "float: right"
ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );
ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );
 
ButtonLink.appendChild( ButtonText );
Button.appendChild( ButtonLink );
 
var Header = Tables[i].getElementsByTagName( "tr" )[0].getElementsByTagName( "th" )[0];
Header.style.display = "block";        //new code
Header.style.position = "relative";    //new code
Header.insertBefore( Button, Header.childNodes[0] );

I'm not sure if I should also set the display style of the span tag to block; haven't tested this yet. Anyway, until the code can be fixed, this will probably work in the meantime:

Note that this is work-around is horrible kludge as it forces the table's header cell to align itself absolutely, thus taking it outside of the normal table flow so that the float won't bother us. Also, because IE doesn't seem to respect the padding style in this table, the somewhat odd (high) position of the triangle cannot be lowered to the absolutely correct position. --DavidHOzAu 23:23, 5 November 2006 (UTC)

N.B: The position problem can be fixed by setting the padding-top style of the table to 0px. --DavidHOzAu 23:29, 5 November 2006 (UTC)

A little too dirty if you ask me... (causes several minor display glitches on FF2.) I think the problem with IE lies in the fact that the span is not correctly insertBefore'd, as manually coding a table works fine under IE:

[but is this placed right under IE?]works under firefox/opera/...
body

Well it looks ok to me on FF2, although there are those two spaces to the side that could probably be eliminated by choosing a different table class. As for the example immediately above, the text does appear on the right, but the center text is woefully off center in both browsers. --DavidHOzAu 00:12, 6 November 2006 (UTC)

Get the header centered is another story :) I'll experiment with IE a bit more tomorrow to find out what goes wrong. Else I'll modify the script to generate different HTML for IE and other. —Ruud 00:18, 6 November 2006 (UTC)

My two cents - I think it is quite important to use "[show}/[hide]" instead of the triangle. We don't want to introduce a new and unique user interface element. WP readers are familiar with [show]/[hide] from the table of contents box, so that is what we should emulate. So, with that in mind, I propose that until a solution can be found for the [show]/[hide] placement on the right hand side (like the way [edit] is rendered), why not put it immediately after the nav box title (in a slightly smaller font), similar to the way the TOC box is rendered? To me, that is a better interim solution than the triangle before the nav box title. Andrwsc 17:15, 6 November 2006 (UTC)

By saying "triangle before the nav box title", I take it you are using IE. No worries, you can expect correct operation pretty soon. [patch]

Anyway, I can think of several reasons why shrinking tables might be better:

1. A triangle is understandable in any language. (this makes it easier to translate.)
2. The navbox hiding thingy wraps everything inside divs to arrange content,[1] yet pages MUST degrade gracefully in older browsers, and still look intelligent if one goes "View->Page Style->No Style" in their browser.[2]
3. The navbox hiding thingy uses border-collapse, which can give unpredictable results in IE and Opera.[3]

Any one of these reasons should be good enough reason to deprecate NavFrame, NavHead and NavContent, but I don't think we're going to do that just yet. --DavidHOzAu 06:12, 7 November 2006 (UTC)

[edit] What were these edits for?

diff

• CSS class names were changed. Is this just the wave of the future, or is there some reason behind it?
• The edit link etc. were removed. Why?
• A table has been used instead of a div. Did the div cause problems?

Just out of curiosity. Shinobu 02:22, 8 November 2006 (UTC)

Note the addition of the state parameter so that we can prevent a particular box from autocollapsing on the page load. For example, we can set tables of data to display by default, and set (possibly large) navigational boxes to hide by default. Also, WAI states (implies?) that it is better to use a plain old table if possible instead of wrapping content in div, since divs don't degrage well on cut-down browsers, such as those you'll find on PDAs. So yeah, you could say that it is the wave of the future. --DavidHOzAu 03:59, 8 November 2006 (UTC)

Actually, WAI states the opposite, I quote: "Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables")." Also considering the way divs are used for navboxes, they will probably degrade okay. I imagine modern PDA browsers and other cut-down browsers do support divs. I also note the v-d-e links are back, but now they take up their own line in IE, while running through the text in Firefox. Why? The original version,

worked fine in both. Shinobu 05:01, 11 November 2006 (UTC)

Note in passing: As of 06:21, 11 November 2006 (UTC), "Lorem | Ipsum | Dolor | Sit" isn't center-aligned with "Caption" on my screen (PC, WinXP, Firefox). Regards, David Kernow (talk)

Same as David. I changed the ccaption and body to make this even more obvious. ~ trialsanderrors 06:46, 11 November 2006 (UTC)

Compared to the deficiencies of the new template that is a minor issue. I appreciate that you try to solve this problem, but you shouldn't have done so with "production code", i.e. a template that is actually in use. The new template breaks in lots of articles, and therefore I will revert the changes for now. If you want to experiment, may I suggest {{navigation/Sandbox}}? When everything works satisfactorily (in Firefox, IE, Konqueror...) then copy the modified version here. That way the fallout of trial and error adjustments doesn't spread over all those articles. Shinobu 09:26, 11 November 2006 (UTC)

I also note that while the old version (posted above) works fine in IE and Firefox, the new one not only doesn't work properly in both, it even borks differently in both! Shinobu 05:07, 11 November 2006 (UTC)

One way to fix this is to set the floats to some specific width and set their external margins to fall inside the floats. Here, we have set the width of the left and right floats to 5em and set their margin-right and margin-left properties to -5em respectively:

v • d • e [show] ... · ... · ... · ... · ... · ...
... · ... · ... · ... · ... · ...

Again, this time without the left-hand float:

[show] ... · ... · ... · ... · ... · ...
... · ... · ... · ... · ... · ...

Tada!! For another example of this positioning trick, look at the top right box on my user page.

Alternatively, if you can guarantee that width of the float added by the collapsible tables code is small, it won't offset the text too much. Or you can just set both the left float and the right float to the same width and not care about having boxes with negative margins. However, I personally would use the negative margin trick in Monobook.js because we can't guarantee that there will be a float on the left.

Cheers, DavidHOzAu 09:52, 13 November 2006 (UTC)

David, if you can fix [this template / similar templates / navbox / navhead / whatever] to show, cross-browsers and cross-platforms, the:

1. v · d · e links on the LH-side of the titlebar;
2. [hide]/[show] option on the RH-side of the titlebar;
3. the title centered in relation to the whole width of the titlebar;

then:

a. Thank you!!

b. Let me know how/what you did, as I'll be sorely tempted to protect one or more pages for the sake of some stability. (I'd unprotect on any subsequent reports of instability.)

Yours hopefully, David (talk) 15:21, 13 November 2006 (UTC)

PS When used within Navbox templates – perhaps in other templates too – the space in the linewrap-sensitive "{{·}} " seems to disappear here – (1) do you see this; (2) any idea why/what to tweak (apart from {{·}}, which seems fine elsewhere)...? Thanks.

[edit] Protected

I've just managed (so it appears) to've restored the [hide]/[show] option on the titlebar produced by this template, so have protected it as a stable version. I'm aware though that:

1. The title in the titlebar still isn't properly centered – can anyone solve this reliably...?
2. These templates probably not always collapsed after pages loaded. The class="NavFrame autocollapse", however, seemed to be part of the problem. Again, if anyone knows a reliable solution, please post here (or implement if an admin).

If this protection is more than inconvenient for some reason that hasn't occurred to me, (1) apologies! (2) leave me and/or another admin a message and I/we'll (try to) address your concern and/or unprotect the template. Hope all this acceptable. Best wishes, David Kernow (talk) 02:42, 14 November 2006 (UTC)

I'm trying to figure out how the collapsing works. As far as I can tell, if there is just one nav template on a page it displays expanded; if there are two or more, they collapse. I'm not sure how practical this functionality is - why not have them start their display expanded, but use a cookie to allow users to collapse them? ericg ✈ 17:46, 14 November 2006 (UTC)

Hi David, I removed the {{protected}} because the article isn't actually protected from editing. Semi or full protection needs to be requested at WP:RFP. -/- Warren 10:52, 16 November 2006 (UTC)

Thanks for spotting, Warren – I inserted the templates but forgot I hadn't actually protected the pages! Both should now be protected. Best wishes, David (talk) 14:37, 16 November 2006 (UTC)

There's a version with correct centering at User:R. Koot/Sandbox9. I suggest adding the edit button using javascript (and a CSS class "editable"_ as well. Any reason we are not using a table-based version, except for the fact that someone broke it? Templates like {{MediaCompression}} really should degrade to a table in old/text-based/nonvisual browsers. —Ruud 16:51, 16 November 2006 (UTC)

The W3C says people shouldn't use layout tables. Tables should contain tabular information (see also one of the posts I made above). Shinobu 05:11, 17 November 2006 (UTC)

I just tested the new centering in IE and Firefox and it works in both. My thanks. Shinobu 05:15, 17 November 2006 (UTC)

[edit] Question

See Template:Ayumi Hamasaki albums. Originally this contained a table based approach, so I converted it to an HTML table to be able to use this template.

Note however that there is nothing table-like about the contents, essentially they're just headings and paragraphs. Is there a standard way to do headings in navboxes? Shinobu 07:38, 17 November 2006 (UTC)

[edit] Header background

The current default colour is UGLY. Don't you see it yourself? and btw, David, what user request were you talking about? could you please give a link to diff and explain why someone's request sufficient to make change in protected template w/o discussion? -- tasc ^words_deeds 20:01, 17 November 2006 (UTC)

Hi tasc! The request was linked in the edit summary; from that and its reference to {{Navigation}}'s history I trust you'll retrieve the context.

Meanwhile, I've returned the default colo/ur to #eee per here and have set up the survey below to find any consensus. Regards, David Kernow (talk) 04:54, 18 November 2006 (UTC)

Hi David, i trust if you'll retrieve the context I'll note that your request was mislinked. I'm not going to run across wp to find out what you meant. So, I'd suggest you check your deeds before your words. Cheers, -- tasc ^words_deeds 08:35, 18 November 2006 (UTC)

Oops, yes; it's meant to be User talk:David Kernow#Template:Navigation, not User:David Kernow#Template:Navigation. Apologies for typo! David (talk) 15:00, 18 November 2006 (UTC)

[edit] Survey: Titlebar's default background colour

Per the above thread and here, the default background colour for this template's titlebar is currently #eee (a faint grey) but previously/originally was #ccccff (a light blue). Please indicate your preference/s below; thanks! David Kernow (talk) 04:54, 18 November 2006 (UTC)

[edit] Some colors from Tango Desktop Project [4]

For the purpose of comparison, here are some colors used in the icons of most open source programs. With the exception of aluminium, they are at 50% transparency (with white) because Wikipedia's default color scheme errs on the side of brightness. --DavidHOzAu 10:52, 20 November 2006 (UTC)

fef5a8: 50% Butter 1 / 50% White

c5f19a: 50% Chameleon 1 / 50% White

ffd8a0: 50% Orange 1 / 50% White

f5ddb7: 50% Chocolate 1 / 50% White

b9d0e8: 50% Sky Blue 1 / 50% White

d6bfd4: 50% Plum 1 / 50% White

f79494: 50% Scarlet Red 1 / 50% White

d3d7cf: Aluminium 2

Thanks for the above, David; can't resist suggesting that "chocolate" flavo/ur is probably even more dodgy than the colo/ur of Hershey's factory floors... Chuckle, David Kernow (talk) 01:54, 21 November 2006 (UTC)

That's because the original colors are darker, i.e. the page background is a bit more soothing to look at on Tango's wiki. Anyway, I'd like to know if people with bright laptop screens can see Aluminium 2 or 50% Sky Blue when used as a background, and if they can make out the text when it is linked. --DavidHOzAu 03:28, 21 November 2006 (UTC)

PS All the above except "50% Scarlet Red 1 / 50% White" look fine here (on 22" desktop monitor and laptop screen). Regards, David (talk) 22:26, 22 November 2006 (UTC)

Right; it's been stricken from the list. --DavidHOzAu 12:57, 23 November 2006 (UTC)

• I like all of them, but I think they're too colorful. This is an internet encyclopedia, not a candy factory. wikipeep 494

[edit] [Show]/[Hide]

Here's another request: Can the [Show]/[Hide] tags be set to [SHOW] and [HIDE] in fixed width font? This way the size of the tag doesn't change when clicking on it. ~ trialsanderrors 10:25, 19 November 2006 (UTC)

That would look worse than the changing size... please don't! ericg ✈ 17:00, 19 November 2006 (UTC)

I actually preferred the arrow/triangle. --DavidHOzAu 10:53, 20 November 2006 (UTC)

I liked the triangles too, although they might be too non-obvious for casual users. ~ trialsanderrors 19:32, 20 November 2006 (UTC)

I disagree. The familiar Table of Contents box uses "[show]" and "[hide]", and I think consistency is the most important thing here. The triangles represent a newly introduced user interface element, different from what most users are familiar with. Andrwsc 19:39, 20 November 2006 (UTC)

• That wouldn't match with the rest of the words because it has a different font. Maybe just putting it in bold? wikipeep 494

[edit] Show as default

How can you have it so that the template is set to Show as default and then the button is there to hide it?Chris_huh^talk 15:22, 21 November 2006 (UTC)

Remove the first div and one closing div tag. Lcarsdata (Talk) 18:13, 21 November 2006 (UTC)

[edit] Doesn't work in classic skin

This template does not currently work in Safari on a Mac OS X. Any other browsers have any difficulty with it? -- Rick Block (talk) 21:45, 22 November 2006 (UTC)

Or maybe it's the skin (classic). Looks OK in Firefox in Monobook, but messed up in Firefox in classic. -- Rick Block (talk) 21:54, 22 November 2006 (UTC)

Also OK in monobook in Safari on Mac OS X, but messed up in classic. -- Rick Block (talk) 22:42, 22 November 2006 (UTC)

The issues seem to be

1. the NavFrame style is only defined in MediaWiki:Monobook.css, not MediaWiki:Common.css (so if you're not using monobook there's no frame at all)
2. the absolute positioning of the Tnavbar puts the v-d-e wildly far to the left (no clue why this is skin sensitive)

Anyone care to address these, or are we officially only supporting monobook at this point? -- Rick Block (talk) 19:12, 23 November 2006 (UTC)

Would love too, but am not qualified... Anyone else...? Regards, David Kernow (talk) 05:03, 24 November 2006 (UTC)

The quick fix for the NavFrame style issue is to inline the style in the "div" rather than use a css style that is only defined in one skin. I'm perfectly willing to do this if no one objects. -- Rick Block (talk) 06:29, 24 November 2006 (UTC)

Seems fine to me... If any problems occur, the status quo can be restored pending another solution. Yours, David (talk) 08:16, 24 November 2006 (UTC)

I've inlined the NavFrame and NavHead styles, which makes it at least tolerable in classic. If anyone can explain why these styles were only added to monobook.css I'd appreciate it. -- Rick Block (talk) 13:18, 24 November 2006 (UTC)

[edit] Changes to protected template

Some administrators seem to think that they are above the rest of editors. With no decent reasons template was first fully protected, and then without discussion and even summary some administrators edit it. I request removal of full protection, and revert to prior settings. -- tasc ^words_deeds 10:29, 25 November 2006 (UTC)

It's protected as a defensive measure since it's included in so many articles that each change creates a significant spike in server load (many, many thousands of articles are cached, and if a very commonly used template is changed the resultant cache invalidation processing takes a [relatively] long time). I agree no one should be making changes to it without prior discussion, but I do not think it's a good idea to unprotect it. -- Rick Block (talk) 16:10, 25 November 2006 (UTC)

well, it can be semi-protected. As I noted at my unprotection request, it's not easily reached by vandals since it's not included in any articles directly. -- tasc ^words_deeds 16:17, 25 November 2006 (UTC)

You see protection doesn't help when admins are vandals. -- tasc ^words_deeds 16:23, 25 November 2006 (UTC)

Well I'm assuming good faith on this, but I think that unless a template like this has a history of serious vandalism or forms an integral part of Wikipedia policy then it shouldn't be protected. If there is a history of occasional vandalism then a status of {{sprotected}} would be sensible. (→Netscott) 20:07, 25 November 2006 (UTC)

Template was protected only because it's 'highly used'. I'm unfortunately don't assume good faith here :( As far as I'm concerned, template hasn't been vandalised. -- tasc ^words_deeds 20:11, 25 November 2006 (UTC)

Does anyone know if a denial of service attack has ever been attempted on Wikipedia though Template vandalism? (→Netscott) 20:16, 25 November 2006 (UTC)

Has it ever been attempted on WP by any means? -- tasc ^words_deeds 20:24, 25 November 2006 (UTC)

Tasc, please read the rationale part of Wikipedia:High-risk templates to understand why I'm assuming good faith. (→Netscott) 20:38, 25 November 2006 (UTC)

I have. But I also see what is going on. Guideline you're referring to says: Minimize edits on high use templates. And what about this after a consensus to change the template has been established on the template's talk page. clause? -- tasc ^words_deeds 20:47, 25 November 2006 (UTC)

[edit] Is there any decency?

There is discussion going on! why some admin think that he's allowed more than the rest of us? -- tasc ^words_deeds 16:21, 25 November 2006 (UTC)

I'm amazed how admins disregard all possible guidelines in this case. They don't respond to direct requests, they don't discuss changes. They only edit, edit, edit. Making template even worse. -- tasc ^words_deeds 22:30, 25 November 2006 (UTC)

Tasc, there always is dispute resolution. Also you might want to address yourself to User:David Kernow who protected it. (→Netscott) 22:33, 25 November 2006 (UTC)

And there is a request for unprotection. I'm waiting for reply already 10 hours! And I should note - that's not a dispute at all. This is blatant violations of guidelines, wiki etiquette, you-name-it rules by numerous admins-vandals. -- tasc ^words_deeds 22:39, 25 November 2006 (UTC)

[edit] v-d-e

This was removed from the Navigation template. Before, the template looked fine. Now, the title is not centered because only an edit option is on the header, right next to the hide/show option. Why was this altered? —Cliff smith 18:12, 25 November 2006 (UTC)

The header should be perfectly centred. You might need to clear your browser cache first. —Ruud 20:13, 25 November 2006 (UTC)

Please revert your edits to the template, performed w/o discussion. -- tasc ^words_deeds 20:15, 25 November 2006 (UTC)

[edit] Tnavbar

What happened to the Tnavbar template - now it just has some really bulky looking [edit] link instead of the sleek

Was this intentional as i can't see why it would have been. Chris_huh^talk 18:14, 25 November 2006 (UTC)

The [edit] link doesn't seem to make as much sense as it just dumps a person right into edit mode on the template without easy access to viewing the template (the "v" link) on its own nor reading the talk page first (with the "d" link) to check for consensus. The only advantage I see with the edit link is of esthetiques as [edit] matches [hide] and [show]. Adding v.d.e back as [v • d • e] would probably help in this area. (→Netscott) 20:00, 25 November 2006 (UTC)

Edit in place of hide/show also confuses reader. But it's of course not a major problem. Main thing is that such major change was performed w/o discussion on fully protected template. -- tasc ^words_deeds 20:05, 25 November 2006 (UTC)

The three letters v.d.e are very confusing (especially to new users). How is one supposed to know they stand for view, discus and edit? The non-mini version adds too much bloat to the template. —Ruud 20:17, 25 November 2006 (UTC)

You changed their location which adds much more to the confusion. -- tasc ^words_deeds 20:22, 25 November 2006 (UTC)

An option would be to add only a [view] link. —Ruud 20:18, 25 November 2006 (UTC)

Yes that has logic to just tack on a |viewplain=1 call at the end which'll force users to look at the template first and then proceed from there... but I prefer the immediacy of access with all three. The navigation templates themselves aren't generally too high of a risk as far as templates go. (→Netscott) 20:23, 25 November 2006 (UTC)

It's a trade-off between power users' needs and that of casual editors and interface sleekness. Given that edit and talk pages or only a single click away from the template page, I would favour a single descriptive link. —Ruud 20:39, 25 November 2006 (UTC)

Well I've been using Tnavbar since May and have only recently added the simple view option. What I know is that templates that have had the v • d • e options added have tended to improve quite a bit. See Template:Buddhism the day I added Tnavbar and then three days later. (→Netscott) 20:45, 25 November 2006 (UTC)

I could image that having v.d.e links on a template would attract more editors (compared to not having any direct way to edit the template). However, I do not believe having only a view link would reduce the number of people who improve the template. In fact, I conjecture that the increased accessibilty would have the opposite effect, drawing in even more editors. We could even add an "edit" link which does not directly go to the edit page, forcing editors to read any important messages first; calling the link "view" might not tell people they can edit the template as well. —Ruud 21:32, 25 November 2006 (UTC)

Well if it's going to be an edit link then call it that... if it's going to be a view link then call it that... relative to the rest of the wiki I'd see an edit link that only goes to a view of a template as deceptive plus it'd just confuse usage with the actual {{edit}} template. (→Netscott) 21:47, 25 November 2006 (UTC)

Well, the way I see it, if new users have difficulty understanding the links that's likely a good thing as those types of users probably shouldn't be editing too much in template space. Regardless a simple hover of the mouse over each letter provides an explanation of what that link does. (→Netscott) 20:20, 25 November 2006 (UTC)

An option would be stop messing with template and revert to previous version. -- tasc ^words_deeds 20:22, 25 November 2006 (UTC)

[edit] [hide] link attached to header, and proposed layout change

The [hide] link is currently directly attached to the header, which is really ugly. The picture to the right shows how it appears on IE 6.0. I think it should be on the right, together with [edit] and [discuss]]. I don't see a need for [view], since that doesn't give anything different from what the user already sees. — Sebastian (talk) 22:29, 27 November 2006 (UTC), edited 23:54, 27 November 2006 (UTC)

Not sure why you're having the display problem with hide being attached to the header text... anyone else seeing that? (→Netscott) 00:07, 28 November 2006 (UTC)

View is good because it allows editors to not be distracted with other elements on a given page and thereby just visualize the template itself. (→Netscott) 22:34, 27 November 2006 (UTC)

Here's a perfect example of why it's good to have a view option on the templates. See the article Military of Angola and notice the Navigation template towards the bottom. You'd think it'd look like that when viewed solely but you'd be wrong. Go ahed and view that template by itself. (→Netscott) 22:40, 27 November 2006 (UTC)

Thanks, that's cool! But it doesn't give you anything that [edit] doesn't give you, and I doubt that it's very useful beyond the circle of those who edit templates. — Sebastian (talk) 23:54, 27 November 2006 (UTC)

AKAIK the div-based version only works when you use the monobook skin. —Ruud 17:09, 29 November 2006 (UTC)

The classes for NavFrame NavHead & NavContent are in MediaWiki:Common.css, and the controlling script is in MediaWiki:Common.js. It'll work in all skins. --DavidHOzAu 03:02, 10 December 2006 (UTC)

[edit] autocollapse

Can we at least get this to not autocollapse when multiple examples exist on a page? Super annoying. ericg ✈ 07:41, 26 November 2006 (UTC)

Do you mean the default behaviour should be not to hide the boxen when more than 1 or 2 is/are present in an article? This would sort of defeat the point of this template (although, I'm definitely not a proponent of collapsed boxen myself.) —Ruud 12:20, 26 November 2006 (UTC)

Yes, I do. I think the collapse/open states should be controlled by cookie per user, not by javascript globally. ericg ✈ 16:36, 26 November 2006 (UTC)

A cookie may be fine, but please keep the default behavior to collapse for multiple templates. — Sebastian (talk) 22:29, 27 November 2006 (UTC)

A cookie per user per template? or just one for all templates? -- tasc ^words_deeds 11:02, 28 November 2006 (UTC)

All templates. ericg ✈ 23:35, 28 November 2006 (UTC)

[edit] LEAVE THE TEMPLATE ALONE!!!

Please leave this template alone. I am tired of every single time in go on Wikipedia it looks different. To be honest the current revision looks like crap. What happened to the light grey menu bar, with th "v d e" and "hide" tabs - that was fine. OSX 22:46, 25 November 2006 (UTC)

[edit] Request unprotection

To all admins: I request uprotection of this template, as it's layout is not agreed upon and risk of vandalism is very low. -- tasc ^words_deeds 13:10, 26 November 2006 (UTC)

Lowered to semi. —Ruud 13:16, 26 November 2006 (UTC)

[edit] Custom background colours

Now we have an option to have different colours for header background. It doesn't seem to be the best one though. I reckon that system adopted on German Wikipedia better suits purpose of navigation and gives more style to the wp. So, my question is what are advantages of custom colours (as I noted in recent weeks editors tend to chose quite disturbing colours sometimes)? Isn't better to have single colour for all templates? We should think also about unification of all templates across wikipedia, but it's another topic. -- tasc ^words_deeds 07:58, 30 November 2006 (UTC)

Please, voice your coherent opinion on the topic. If there will be no appropriate replies in 72 hours after my initial posting I will consider that community supports abolishing of custom colour option and will implement it. Thanks, -- tasc ^words_deeds 13:23, 1 December 2006 (UTC)

I do not support abolishing of the custom colour variable. An example where colour is useful would be the Stargate project, they have there "own" colour and so this is a place for example where their colour could be used. It is also not better to have one colour, Wikipedia isn't paper, we do not have to worry about ink, we can have some colour, though we do need to be considerate when choosing colours so as to enable everyone to be able to enjoy (for example the colour blind) - another example where colour can be put to good use would be an article on a battle, battle infoboxes use a light blue colour, so it would also be logical for articles relating to battles for their navbox to use the same colour as well. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 17:00, 1 December 2006 (UTC)

I'm sorry if I'm missing something, but does Stargate project uses Navigation template anywhere? I've noticed quite a number of different tables at the bottom of article, but none was based on template in discussion. That's most definitely has nothing to do with ink or enjoyment of colour blind users, but, let's take your example. Why do these infoboxes use 'light blue' colour in a first place? I think that any voluntarily chosen colours should not be forced upon other editors. -- tasc ^words_deeds 19:46, 1 December 2006 (UTC)

It was a scenario so please do not be uncivil towards me. I'll counter your question with a question: Why do you force the default colour on people? The Stargate project likely does not use this template because it is so limited. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 20:18, 1 December 2006 (UTC)

I'm sorry if you see any incivility in my comments. It was most certainly not intended. Well, we're all forced to use some style on wikipedia, sign our comments, and use wikipedia syntax. My concern is about these custom colours chosen by some editors, as I noted above I indeed find most of them at least disturbing. So, my idea was was that perhaps unifying templates will do some good to general look and feel of WP. Of course if Stargate project does not use these particular template due to its limitations, than mentioned changes would not affect project in any way. -- tasc ^words_deeds 20:52, 1 December 2006 (UTC)

I would be grateful if other editors would contribute to this discussion as well. So far I don't see sufficient reasons not to abolish custom colour. Thanks, -- tasc ^words_deeds 09:26, 2 December 2006 (UTC)

I do not see any reason to abolish them so you will not do it, HTH HAND. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 09:29, 2 December 2006 (UTC)

I would appreciate if you post decent comments on this page and avoid any kind of insults. -- tasc ^words_deeds 09:32, 2 December 2006 (UTC)

I'm the one who has posted constructively here; You are the one who is attempting to mould Wikipedia to your liking, if you do not like colour.. then turn it off in your CSS or set an alternate. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 09:37, 2 December 2006 (UTC)

It seems to me that what i've written above is quite understandable. But I'll summarise it one more time especially for you:

1. Custom colours are often (very, very often) ugly
2. They disturb wikipedia's style.
3. They do not improve navigation between article.

I hope that now my point became more clear and you'll stop calling it non-constructive. Cheers, -- tasc ^words_deeds 09:48, 2 December 2006 (UTC)

All the above are your opinions; I also do not share any of them. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 09:59, 2 December 2006 (UTC)

I've never stated that these opinions are yours. I'm so far pretty sure of my mental abilities. Thank you for you input anyway. Other editors please voice your pov. -- tasc ^words_deeds 10:06, 2 December 2006 (UTC)

I think that custom background colours are useful and needed. As was said before they match with the projects theme and if there are several navigation style templates on the same page (but not all using {{Navigation}}) then the colour can be changed to match. Sometimes editors do choose some odd, and clearly wrong colours; there could be a section added to Docs with a list of recommended colours to help this. Chris_huh^talk 10:35, 2 December 2006 (UTC)

The problems as I see them start when editors use poorly chosen colours on a number of template and pages, and 'fixing' this issue becomes a real pain in a neck. -- tasc ^words_deeds 10:39, 2 December 2006 (UTC)

Yes, but i think that the choice of colours should be there. Ideally every navigation template should use this template (or one of the few linked at the bottom of the Docs) and if that was to happen it would make it look a bit stale, whereas having distinct colours for a certain topic would separate things out. Chris_huh^talk 10:55, 2 December 2006 (UTC)

There is a list here of wikipedia suitable colours. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 11:24, 2 December 2006 (UTC)

Why is this link to some previous version of a manual and not an actual one? -- tasc ^words_deeds 11:43, 2 December 2006 (UTC)

Look @ the edit history; The editor entitled it "Allowed colours" - which would of placed limitations on colours that can be used. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 11:47, 2 December 2006 (UTC)

I think that the wide variety of colors in use on wikipedia makes it look childish and 1995. One easy step to becoming a more trusted resource is to look like one. ericg ✈ 16:31, 2 December 2006 (UTC)

So far we're having 2 users supporting abolishing of custom colours and 2 users opposing it. Is there anyone out there who would like to say something? -- tasc ^words_deeds 11:54, 3 December 2006 (UTC)

I strongly support removing the color parameter from this template. Navigation boxes should be uniformly coloured because (with the colour specified in the skin's CSS-sheet):

1. It looks more professional (e.g. see User:R. Koot/navbox.)
2. It fits in better with the skin the user is using (and allows the user to choose their own colour in their personal stylesheet.)
3. Different colours draw to much attention (which navigational boxes should not.)
4. I don't see any argument for using different colour-schemes within a single encyclopaedia (what functionality do the colours add?)

—Ruud 12:56, 3 December 2006 (UTC)

Haha.. this isn't a vote.. also your saying it looks more professional? Have you looked at your before and afters? Your afters look _terrible_ - Has anyone opposing colour looked at the Main_Page lately? thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 13:36, 3 December 2006 (UTC)

I didn't vote. haha... —Ruud 13:45, 3 December 2006 (UTC)

But, to start a more constructive discussion (if you are cable of that): I do not like the navigational boxes in the "after" pictures either, I don't like the colour-scheme, they are too "box"y, and still draw too much attention. I do find them to look better than the navigational boxes in the "before image (even just because they look consistent.) What do you dislike about them? —Ruud 13:53, 3 December 2006 (UTC)

My opinion is that we should use a bot to replace all uses of color with bgcolor so that color is actually the foreground color.
Anyway, if we don't let people customize it to their particular uses, they won't use the template. Making a compromise so that Template:Matrix can have a title that's green phosphorous text on a black header seems a sensible compromize to make if it will ensure consistent typographic layout across wikipedia. Anyway, it'll still be possible for someone to pass <div style="background: fuchsia; color: yellow; width: 100%">Insert title here</div> to the title parameter no matter what we do; it is far better to build functionality into the template in the first place than for everyone to hack it in later as a horrible kludge. I agree that consistency is important, but there won't be a problem if (bg)color is consistently different on a given page.
--DavidHOzAu 04:06, 10 December 2006 (UTC)

• Aside: I agree that (for as long as this parameter maintained) color is too ambiguous a name for this parameter; suggest, however, that barcol preferable to bgcolor...? Regards, David Kernow (talk) 12:32, 10 December 2006 (UTC)

• In CSS style nomenclature the code would be: style="background-color:#somecolorcode". (→Netscott) 12:54, 10 December 2006 (UTC)

You might want to double check that; "background: #fff;" validates just fine. CSS permits the use of shorthand. ericg ✈ 15:50, 10 December 2006 (UTC)

[edit] Please allow the state= parameter.

{{Dynamic navigation box}} allows the state parameter to be set, so that large navboxes can default to being closed. Would this be possible for this box as well? {{shortdick}} (no, I didn't name it that) is pretty long, and we'd like it if it could be collapsed unless the user specifically expands it. grendel|khan 17:00, 11 December 2006 (UTC)

No. Not with the NavFrame-bases solution currently used by this template. —Ruud 20:40, 12 December 2006 (UTC)

But {{dynamic navigation box}} uses NavFrame as well, and it provides the state parameter. Is it not possible here (if so, why not?), or would it violate some design goal or add too many parameters or... ? grendel|khan 14:13, 13 December 2006 (UTC)

No, {{dynamic navigation box}} uses collapsible tables, which have a more powerful script behind them. —Ruud 18:38, 13 December 2006 (UTC)

Grendelkhan, there are many flavors of nav templates. IMHO, there are too many. However, before someone consolidate them, you can look at the nav box of the nav template. The ones implemented with collapsible are capabel of what you're asking. --ChoChoPK (球球PK) (talk | contrib) 20:32, 13 December 2006 (UTC)

[edit] cat(egory) parameter

Shouldn't this be <includeonly>...? David Kernow (talk) 01:17, 15 December 2006 (UTC)