Jump to content

Template talk:Navbox/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10→Archive 15

Requirements To Import To Another Wiki

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

Template:Navbox
MediaWiki:Common.js
MediaWiki:Common.css
Warning to all: This is NOT a complete set of instructions; upon trying this myself, I ran into several missing contents, massive numbers of missing images, etc.
Can someone flesh this out with supplemental information regarding what else is needed?  —Preceding unsigned comment added by 17.213.34.122 (talk) 18:04, 3 July 2008 (UTC)

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

I'll be sure to add this to WP:TRAN, a slow, but growing technical help guide for reusing English Wikipedia content. -- Ned Scott 23:00, 22 May 2008 (UTC)
Following these instructions did not get things working. I have much of it working, but the show/hide box is not showing up at all for me. Is there something I'm missing? Also, is there an "official" -- at least for the Navbox template -- way to import to another wiki? I have seen several sets of instructions about what is required and there is some conflicting information. It would be nice to see some information from the template developer as to how to get this on another wiki, as it is a very handy template to have. If anyone has any information for me, it would be greatly appreciated! Thank you! Metatinara (talk) 23:08, 10 July 2008 (UTC)

float issue

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

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

It's floating for me... (IE6) — Edokter • Talk • 13:00, 8 June 2008 (UTC)
Not for me. Here is a test with "style= width:22em; float:right;" it is centered in FF2. --—— Gadget850 (Ed) talk - 13:26, 8 June 2008 (UTC)
But it does float right in IE7 and FF3. --—— Gadget850 (Ed) talk - 13:28, 8 June 2008 (UTC)
Eep, yes. I'm using FF2 also. --Izno (talk) 17:09, 8 June 2008 (UTC)
Try setting "margin-left:0em;margin-right:0em;" also (or to whatever em value you want, probably 0em on the right and 1em on the left), which might work. The default "margin-left:auto;margin-right:auto;" sometimes messes with floats. --CapitalR (talk) 18:50, 8 June 2008 (UTC)
Perfect, thank you capital. Someone may want to add that to the /doc page, which suggest that floating is as easy as floating anything else. :) --Izno (talk) 19:03, 8 June 2008 (UTC)
Glad to hear that worked. I just added a comment at the bottom of the doc page about using navbox as a float. --CapitalR (talk) 01:53, 9 June 2008 (UTC)

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

  1. The article-section-[edit] links are site-wide on the right.
  2. Yet, the navbox v · d · e links are on the left.
  3. Our readers are more likely to want to [show] the collapsed navboxes, than to edit them - but the [show/hide] is currently on the right (where a left-to-right reader will look last).
  • Also - the article-section-[edit] links and the [show/hide] links are all 4 letters long and surrounded by [square brackets] (easy to confuse at a glance) - But, one pops-opens a navbox, and the other changes to a new page!

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

This is because the collapsible tables script automatically inserts the [show/hide] link to the right. There's no way to change this without changing the script, and this would affect hundreds of thousands of other uses across Wikipedia. —Dinoguy1000 21:09, 10 June 2008 (UTC)
Yes, it would obviously be a large scale change.
  • Are you saying that I'm asking in the wrong place?
  • If so, where should I be asking?
  • and would you agree that the order should be switched, so that the vde/edit links are all on the right of the screen and the show/hide link is on the left (at the beginning of the line, where the reader's eye first looks)? thanks, -- Quiddity (talk) 22:44, 12 June 2008 (UTC)
I think it would be better too keep them as they are, the "view discussion edit" is probably there in that order because that's how it is at the top of the page. |Template|Discussion|View source| for this template. ← chandler 23:50, 12 June 2008 (UTC)
Since Quiddity asked me to come here and comment:
Too me from a visual point of view it doesn't matter which object is on which side, I have no problem to see them all. But since I mostly use the mouse to pull the scroll bar the mouse pointer tends to be on the right side of the screen. Thus considering that [show/hide] is the more common thing to click then having it on the right side means a shorter mouse movement. So the current position is perhaps the slightly better one. But doesn't matter much.
Of course, since I do use the scroll bar (instead of a scroll wheel or other slower means of moving the page) and have my mouse speed set properly I have no problem to scroll past long sections of boxes. Thus I find hidden (collapsed) boxes very annoying since they mean unnecessary information hiding and unnecessary clicks for me. I rather see it all and simply scroll past it. But it seems other people have trouble scrolling pages thus they want to hide things. When will people learn to scroll properly? Do they have a lack of motor skills or what? :((
--David Göthberg (talk) 04:24, 13 June 2008 (UTC)
I personally hate really long scrollbars. But that's just me. ^^ --Izno (talk) 05:20, 13 June 2008 (UTC)
Personally, I seriously doubt that concensus for swapping the VDE/show-hide links could be achieved, considering the order is largely a matter of personal preference, and an actual change would require checking each of the hundreds of thousands of uses of both features beyond navboxes to ensure that nothing breaks, and to update things when they *do* break. —Dinoguy1000 16:44, 13 June 2008 (UTC)
I see it as a matter of usability (specifically Web usability), not personal preference. I've tried to explain that above, but noone seems to understand. Whatever. Consider it dropped. -- Quiddity (talk) 18:56, 13 June 2008 (UTC)

Titlebar problem

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

The template is simply too narrow for the title and the controls to fit on one line. — Edokter • Talk • 17:18, 13 June 2008 (UTC)
I've tried widening it to 300px, yet the titlebar is still placed on a new line. SharkD (talk) 17:23, 13 June 2008 (UTC)
try 28em, but that gets very wide. — Edokter • Talk • 17:47, 13 June 2008 (UTC)
I think I managed to get it to a satisfactory state. SharkD (talk) 20:31, 13 June 2008 (UTC)
It's probably because of the forced padding to center the title which offsets the [hide] button. I've had a similar issue redesigning a small template myself. --Izno (talk) 21:23, 13 June 2008 (UTC)
Part of the problem is also trying to make it look like an infobox; wouldn't it make more sense to just use the standard formatting using groups? — Edokter • Talk • 23:52, 13 June 2008 (UTC)
Could you provide an example? I'm not sure what you mean. SharkD (talk) 01:26, 3 August 2008 (UTC)

Help please

Hi,

I'm from catalan wiki and we have a little problem with navbox template. We have the same code in our Navbox template (we copied the english code) but the results are different as you can see here (the colors, the width,....)

Do you know why?

Thank you very much!!--Schizodelight (talk) 09:09, 22 June 2008 (UTC)

I think you need to copy all of the CSS code for navboxes into the MediaWiki:Common.css page. Take a look at MediaWiki:Common.css in English wikipedia and copy all of the lines for navboxes into the ca:MediaWiki:Common.css page (be sure to delete the old navbox CSS lines first; also, note that you need to be an admin to do this). Then clear your cache and it should work. Please let me know if you need assistance with this. --CapitalR (talk) 00:37, 23 June 2008 (UTC)
 Done. Thank you very much CapitalR!!--Schizodelight (talk) 10:12, 26 June 2008 (UTC)

external wiki version

I finally stopped dragging my heels and made a version of Navbox that will work with most other wikis, such as those hosted by Wikia, at Wikipedia:WikiProject Transwiki/Template:Navbox. It's a "pure wiki table" version, with {{!}}'s equaling |'s, making it work with parser functions. There is still one problem left, the use of a div for each group/list

{{#ifeq:{{{evenodd|}}}|swap|odd|{{{evenodd|even}}}}}" {{!}} <div style="padding:{{{listpadding|0em 0.25em}}}">}}{{{list4|}}}{{#if:{{{list4|}}}|</div> }}

Because the div tag starts in one parser and ends in another it breaks, resulting in a visible </div> tag at the end of each list, as seen on wikia:fashion:Template:Grands couturiers. This is the same reason the template code needed to be wikitable code and not HTML, because when the opening and closing HTML tags get separated they then break on these wikis. (because of a different Tidy setting than what we have)

How vital is this div tag? When I took it out of one line it didn't seem to make a difference when viewing on Safari. There's probably a way to still keep it, but use a single parser function, so that the opening and closing tags don't get separated.

Also, on {{Tnavbar}} there's a switch to use either div or span. Since this also places the opening and closing tags in different parsers, the tags won't apply and will result in orphaned </span> and </div> tags being visible. I assume this is for browser compatibility?

Any suggestions or advice would be appreciated. -- Ned Scott 23:20, 29 June 2008 (UTC)

The purpose of the div is to provide default left and right padding of 0.25em in all of the list cells. If the padding is placed in the table cell instead of in the div, then it is impossible to use child navboxes (i.e. subgroups), because they will have the padding on either side of them. The div has the advantage that if it is immediately closed (i.e. <div style="padding:0em 0.25em;"></div>) without anything inside of it, then it is ignored by the browsers. Thus, the subgroups take advantage of this by immediately closing the divs without anything in them to prevent unwanted padding around them. Adding default padding without using the div is impossible as far as I can tell (I did massive testing on this particular feature, and this was the only way I could do it). The default padding makes navboxes much easier to read in my opinion, so I would not like to see it go away. For an external wiki version, however, you can eliminate the divs and live without padding (just don't replace the English Wikipedia one with it so we can keep our padding). --CapitalR (talk) 01:22, 30 June 2008 (UTC)
I don't know that much about css and doing stuff like tweaking the padding of tables, but wouldn't setting that space with cell spacing, rather than padding, fix the issue? -- Ned Scott 06:25, 30 June 2008 (UTC)
Hmmm, not quite sure we're talking about the same thing. The issue is that if we add padding to the table cell, then any child navboxes inside of the cell will have padding around them, which is bad. Thus, we add padding to a div inside the table cell, which child navboxes can disable to avoid the extra padding. Changing cell spacing doesn't really have anything to do with the padding. --CapitalR (talk) 16:11, 30 June 2008 (UTC)
But wouldn't it create the same visual effect? -- Ned Scott 08:19, 3 July 2008 (UTC)
I think that I still don't quite understand what you mean by cell spacing. The "cellspacing" of a table controls how many pixels are in between cells. We need padding in the cells for on the 0.25em left/right, not cellspacing. Padding goes inside of the cells, cellspacing puts space in between cells. Besides, tables can only have one cellspacing value for all cells; we only want the padding in the list cells, not on the groups cells. If we set cellspacing=0.25em this would create huge gaps between the cells and look funny (we want 2px between cells; we only want 0.25em inside of the list cells, and only on the left/right). --CapitalR (talk) 17:16, 3 July 2008 (UTC)

Suggesting amendments to default group/liststyle

Hi. With their current default nowrap formatting, groupnames can occasionally dominate a Navbox template's appearance, e.g.

Not that great an example, but hopefully anyone who's worked with templates knows what I mean. So, suggest that Navbox/core's default group/liststyles are amended to include: 

|groupstyle = ...width:12.5% [or thereabouts]; white-space:normal;...
|liststyle  = ...width:auto; [due to groupstyle width]...

The above example would then become:


Also, the current group/liststyle defaults render gaps between wrapped lines that -- on Firefox 2 here, at least -- are very wide (groupstyle) or aren't smaller than the gap between lists (liststyle). Hopefully, the following will demonstrate:

Although, yes, the lists' backgrounds alternate, I still reckon a default formatting such as the below works better as it spaces each list a little further apart from its predecessor/successor. The wrapped groupnames should also appear less widely spaced:

To produce the above, the default group/liststyle would need to be amended thus: 

|groupstyle = ...padding:0.35em 1.0em; line-height:1.1em;...
|liststyle  = ...padding:0.25em 0; line-height:1.4em;...

Combing both sets of suggestions above yields:

I guess the fixed groupstyle width default would need to be coded along the lines of "no larger than 12.5% (or whatever) but smaller if possible". Would that itself be possible? Sardanaphalus (talk) 07:24, 30 June 2008 (UTC)

It's bad practice to try to fix any dimensions; most navboxes do not have any wrap problems. Sizing should be left to the browser. Also, the padding would break nested navboxes, so that is out as well. In cases where the no-wrapping is troublesome, a simple <br/> should fix the problem. — Edokter • Talk • 13:45, 30 June 2008 (UTC)
  • I'm not sure I understand your response... First, I'm not meaning to suggest that dimensions (default settings?) are fixed, only amended; secondly, I don't see why/how such amendments would break nested navboxes. If they do, perhaps an excpetion could be coded for such situations, as I reckon they're relatively uncommon. Third, I think you may've missed the "raison d'être" for my suggestions re groupname wrapping; yes, a <br/> "fix"es the situation, but currently it's something editors would need to know how and/or remember to do rather than something taken care of by default. Sardanaphalus (talk) 14:33, 30 June 2008 (UTC)
  • Well the padding is currently set to 0.25em on the left and right; this could easily be changed to 0.35em as suggested if it is agreed that is better (we just need to be sure to adjust the padding in the divs, not in the table cells). I have no problem with going to 0.35em. As for the group widths, I think making the change would break quite a few templates. Right now groups are set to not wrap unless manual breaks are put in place, which helps prevent strange group wrapping and browser differences. I think the current system has worked fairly well and I can only foresee problems with changing it (long groups are relatively rare, and asking people to put in manual breaks for them isn't much to ask; and it prevents wrapping problems for the vast majority of short groups). Thus, I'm strongly against the group width change. As for the line-height, that one will probably generate the most comments. There's no real technical reasons why it can't be done, just differences in style opinions between users. I, for example, weakly oppose the different line height because I think it makes the text look unnaturally squished and hard to read. We'll see what others think though. So, in conclusion, I see no technical reasons against the padding and line-height (just style opinions), but I do foresee problems with the group width change. --CapitalR (talk) 16:04, 30 June 2008 (UTC)
  • Thanks for your thoughts. Re the list spacing and groupname wrapping, it just seems a pity that the (vertical) spacing between the end of one list and the start of another looks identical with that between lines within each list; and that a dispropotionately large gap between lines appears when a groupname is wrapped. (This, at least, is what I see in Firefox 2.0.0.14 on a Windows XP PC.) So, to me the situation seems more than merely a matter of style or decoration. Sardanaphalus (talk) 18:01, 5 July 2008 (UTC)
PS The 0.35em and 0.25em padding suggestions are top-bottom, not left-right.
  • Ah, I totally read that wrong and didn't notice it was top/bottom instead of left/right. Yeah, the top/bottom unfortunately introduces some other problems that can't be easily fixed. Right now, as explained in a thread above, when a child navbox is used, the left/right padding in the parent list cell disappears (due to a trick in the CSS standard that is exploited), making the child fit snuggly in the parent with proper spacing. Unfortunately, this trick only works for left/right padding, and does not work for top/bottom padding. Thus, if we introduce a top/bottom padding, then there will be extra padding around all child navboxes that users would have to manually remember to disable each time they use a child navbox. That said, once m:StringFunctions is added to Wikipedia (which will hopefully be soon), then I can rewrite the Navbox logic to not use the CSS left/right padding trick, and we will be able to put the padding directly in the list cells (including top/bottom padding) without any negative consequences. So, for now, if we want the extra padding on the top/bottom then we need to decide if we're willing to mess up all of the child navboxes ({{Navbox subgroup}}, {{Navbox with columns}}, {{Navbox with collapsible groups}}, etc.) with unwanted padding, or if we want to wait for StringFunctions, or if we want to leave it the way it is now. As I've said before I'm in favor of leaving it be (since I don't care for the decreased line-height look), but I'm open to others coming to another consensus (and I'd be willing to make the necessary changes if need be). I'll add some examples of the problem I just described later tonight when I get more time. --CapitalR (talk) 23:49, 7 July 2008 (UTC)

help involvement

Hey can someone here help me with the Navbox on the Living Dead wiki? Well I just need that please reply here and when finished delete the message. Demon Hunter Rules(—) 22:36, 7 July 2008 (UTC)

Request to enhance

An easy one (maybe?): add group/list21 and group/list22. Then Template:Royal houses of Europe will work as intended, see TALK! People try to add their royal houses, but Spain and Sweden are lost, despite being entered into the template. Since the template is written by using arguments (numbered) to generate table slots (unnumbered sequential), using another template set that avoids using arguments might be considered for the template Template:Royal houses of Europe some faraway day. Said: Rursus ☻ 07:42, 9 July 2008 (UTC)

I'll answer for what I'm worth, in that that template should probably be split. I'm unsure of how, but there it is for you. You're entering category-usefulness with that particular version. --Izno (talk) 07:45, 9 July 2008 (UTC)
checkY Done Germany was also listed twice in the coding, but it was group13, which already existed, so it did not show up in the template. Also, there was no group11, so that threw off the background striping. I added a {{Navbox subgroup}} at group20 that allows for add'l groupings past 20. Rgrds. --Tombstone (talk) 08:34, 9 July 2008 (UTC)
THX 106!! Yeah! That template should probably be split, or use navbar twice. I'll consider carefully how, and make a try. Said: Rursus ☻ 08:54, 9 July 2008 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Navbox/Archive_8&oldid=1138531624"