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?) 10 [Show]/[Hide]

[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] The current faint grey (#eee)

• Boring and too light. Kaldari 05:21, 18 November 2006 (UTC)

it calls style of wikipedia as of 2006. we're not in 1999 to have fun colours on the web. -- tasc ^words_deeds 08:38, 18 November 2006 (UTC)

Wikipedia does not JUST have one skin. I do not see a consensus establishing that all templates are required to have #eee... If you desire to use a different color, just pass it to the template. I made the parameter optional for that reason.

A brilliant observation we are indeed not in 1999.

--Cat out 10:39, 18 November 2006 (UTC)

Well maybe wp should have ONE skin. We're talking here about default colour. No one is saying that all templates should have #eee. But it's also an option. -- tasc ^words_deeds 13:49, 18 November 2006 (UTC)

[edit] Previous/original light blue (#ccccff)

• Perfection. Kaldari 05:22, 18 November 2006 (UTC)
• Ugly. -- tasc ^words_deeds 08:39, 18 November 2006 (UTC)

• Still perfect when title includes one or more links, i.e. also uses a blue colo/ur...? (Thanks for adding the samples!) David Kernow (talk) 06:44, 18 November 2006 (UTC)
• hardly readable. -- tasc ^words_deeds 08:39, 18 November 2006 (UTC)

  I can read it just fine. --Cat out 10:48, 18 November 2006 (UTC)

I cannot. -- tasc ^words_deeds 13:47, 18 November 2006 (UTC)

• When this template was created an ice blue color was used, it should not have been changed without consensus. The color in question had been popular on wikipedia for quite some time, such as on {{Asia}}: (28 March 2006) (4 April 2004) --Cat out 10:48, 18 November 2006 (UTC)
• I prefer this color; besides, I believe it is current practice on Wikipedia. (Note that this color can also be shortened to #ccf like #eeeeee has been above.) --DavidHOzAu 11:23, 18 November 2006 (UTC)

  Note about current practice: Compare ccccff usage to eeeeff usage. --DavidHOzAu 11:29, 18 November 2006 (UTC)

current practice is not necessary best practice. -- tasc ^words_deeds 13:47, 18 November 2006 (UTC)

You guys realize that you can wrap your own css around wikipedia if there's something you don't like, right? For example, I found the old nav template's colors butt-ugly, so I threw my own together. Change is sometimes good on templates - this should be decided based on consensus from an actual vote, and if you dislike the end result, that's your responsibility to change your user monobook.css. ericg ✈ 18:33, 18 November 2006 (UTC)

[edit] Something else (suggestions?)

Here is my suggestion; a very light blue, contrasts well with both black and blue text. -/- Warren 05:10, 18 November 2006 (UTC)

• Too light (barely shows up on my laptop monitor). Kaldari 05:22, 18 November 2006 (UTC)

  I cant see it either when I am using my laptop on batteries (the screen is dimmed to save power as in many other laptops) --Cat out 10:52, 18 November 2006 (UTC)

One of the colors used on the Wikipedia frontpage. ~ trialsanderrors 10:22, 18 November 2006 (UTC)

Doesn't look right. I see no reason to change the colors used on navigation templates for the past 2+ years --Cat out 10:49, 18 November 2006 (UTC)

How about making the color an optional parameter in the template itself, so the color can be used to match the articles?--HereToHelp 00:56, 19 November 2006 (UTC)

[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)