Template talk:Navbox generic

Group moved to subtemplate

Having just seen {{Navbox generic subgroup}}, I've had the thought of moving the code for an individual groupn/listn entry into a subtemplate to replace the current 20-whatever entries that differ only in the number. Thinking about it, one potential problem comes to mind: How would the template and subtemplate handle an image? If this problem could be figured out and overcome, it would take care of a lot of the code bloat and would more or less remove the restriction on the number of rows. Any thoughts? --Dinoguy1000 ^Talk 00:04, 28 August 2007 (UTC)

I'm actually working on that now. You can see my progress at User:CapitalR/Test2. Basically, it will have the subgroup handle the image placement, which will technically allow nested images (as shown in the example). Thus, the Navbox/core could be rewritten to just accept a {{{body|}}}, and the Navbox template will insert a Navbox subgroup as the body. I'm going to work out any bugs, test it, then see what others think for making this the real code. --CapitalR 14:03, 28 August 2007 (UTC)

I too am working on things related to this. You might have seen what I am testing at {{navbox subgroup }} and its talkpage. I've been doing a lot of template and CSS coding lately so I am starting to get decent at it so I want to take part in this.

CapitalR: I think you might be misunderstanding what Dinoguy1000 meant.

Dinoguy1000: Yes, moving the group code to a subtemplate that handles one single group+list item would be better in several ways. Good suggestion.

However, all these changes/additions pose a lot of questions that needs to be discussed. But I'll have to get back to you guys later about that since it is bedtime for me.

--David Göthberg 01:56, 29 August 2007 (UTC)

CapitalR: If we do as you suggest to insert a whole "navbox subgroup" to handle all the group+list rows in a "navbox" then we get a problem with the right padding/margin. At least if the "navbox subgroup" itself is a table. Since each table adds some extra right padding (or is it margin?) so the more table levels the more right padding/margin.

If the "navbox subgroup" is not a table but just the code we had in the navbox before then there probably is no point in moving all the group+list rows to a separate "navbox subgroup" template. Then it is better to do as Dinoguy1000 suggested, to use a template that handles a single row (but that is not a table in itself), and call that one for each row in the navbox. (That means we will have to continue to use rowspan for the images.)

I discovered the right margin problem while I was coding and testing the new extended {{navbox subgroup}}. You can see the margin problem in the test examples at Template talk:Navbox subgroup. I am currently doing a lot of testing on my personal test pages to see if I can solve it.

Note, when we use the {{navbox subgroup}} just as a subgroup inside a navbox list, then the margin problem doesn't matter that much. But if we use several levels it becomes too visible.

I hope my description of the problem is comprehendable?

--David Göthberg 19:50, 29 August 2007 (UTC)

Shouldn't the right margin problem be easily fixable by initially setting margin-right, padding-right, and spacing-right to 0, and then adjusting to taste? --Dinoguy1000 ^Talk 23:25, 30 August 2007 (UTC)

I fought with that right margin problem for the last few days and can't figure it out. My HTML/CSS skills aren't too great, however, so perhaps someone else has ideas for fixing it. I'll keep trying with the margin, padding, and spacing fields to see if I can get it to work. I've been playing around at User:CapitalR/Test3 with a simple example of the problem; I'd appreciate any help on fixing it. --CapitalR 12:25, 31 August 2007 (UTC)

Alright, I think the problem is between the second and third tables. Try setting margin-right, padding-right, and spacing-right to 0 for the third table, and see what happens. --Dinoguy1000 ^Talk 05:33, 1 September 2007 (UTC)

I just tested creating a subtemplate that handles a single group+list item. Unfortunately it did not work as expected. I gave the subtemplate two parameters: The row number and if it is even or odd. And then used that inside the subtemplate to put together which variables to use. (group1, list1, oddstyle etc.) Unfortunately MediaWiki does not interpret the variable names when I put them together like that. The other option is to give the subtemplate all those variables as parameters. But then the call becomes almost as big as the old code, thus we do not gain anything.

I have also done more tests with the "right margin problem". I tried setting "margin-right:0; padding-right:0; spacing-right:0;" just about everywhere but it did not help at all. I still get the extra right margin in all my web browsers. I also read up on all settings one can do on a table and its cells and tried pretty much everything. I can make the right margin slightly thinner but then the whole table becomes ugly. So I think the next thing I'll try is to tinker with this off-line on a pure HTML page that is not handled via MediaWiki. Just in case it has something to do with Wikipedia.

--David Göthberg 06:20, 2 September 2007 (UTC)

I just got everything working in IE, Firefox, and Safari. See User:CapitalR/Test2 and User:CapitalR/Test1 for examples. The templates used are User:CapitalR/Navbox, User:CapitalR/Navbox subgroup, User:CapitalR/Navbox/core, and User:CapitalR/Navbox/group. It supports individual styles for all groups/lists and nested groups/lists (including nested images). The basic pre-expand size is about 14k with all of these additional options, which is about the same as the current Navbox design. Also, it fixes a bug in the Navbox/Navbox generic design (IE only) that gives extra spaces when the template is collapsed and an image is inside the hidden part. Feel free to play around in my userspace to modify the code. Let me know what you all think, --CapitalR 21:24, 2 September 2007 (UTC)

Oh! Your new navboxes are so shiny I gotta wear sunglasses when looking at them!!! It really looks like you've solved it!!! #8)) I'm going to study your code thoroughly after I had my dinner. It seems your new navbox code fulfils all our wishes and more. (Yes, we spent lots of time on this without solving it so it is worth a lot of exclamation marks that CapitalR now solved it.) Oh, and they look correct in all my three web browsers: Firefox 2.0, IE 5.5 and Opera 9.02.

--David Göthberg 00:07, 3 September 2007 (UTC)

New navbox design

Check out this new feature added to my new navbox design:

{{User:CapitalR/Navbox
|body = 
 {{User:CapitalR/Navbox
  |borderless = true
  |name = User:CapitalR/Test2
  |state = uncollapsed
  |title=Title1
  |list1 = List1
 }}
 {{User:CapitalR/Navbox
  |borderless = true
  |navbar = plain
  |state = uncollapsed
  |title=Title2
  |list1 = List2
 }}
 {{User:CapitalR/Navbox
  |borderless = true
  |navbar = plain
  |state = uncollapsed
  |title=Title3
  |list1 = List3
 }}
}}

This could be useful in many templates to allow large navboxes to be collapsed in sections. I think I'll create a new wrapper template to make using it easier. --CapitalR 20:26, 4 September 2007 (UTC)

Hehe, have you been snooping around my pages? (Which of course you are welcome to do.) That is exactly the thing I coded up for the WikiProject Cryptography about one year ago. You can see how we use our navboxes in a common border at that page. Oh wait, I told you about that some time ago, didn't I? Anyway, it is a feature that it seems everyone at the WikiProject Cryptography have liked a lot so I bet that most others will like it to.

By the way I don't think you need to feed each subnavbox to its own list item in the mother box, I think you can simply feed them all after each other to the same main list item.

And I hope you know the way we do it at the WikiProject Cryptography? We code each subnavbox on a separate template page. And then just include those subnavboxes we want on each article page. I hope that is what your wrapper will be doing?

Oh, and sorry that I haven't had the time to study your code yet. I've been busy in the real world (dancing with the girls, literally) and also been busy here on Wikipedia with the template standardisation (article message boxes). But I am going to check your code, soon.

--David Göthberg 01:31, 5 September 2007 (UTC)

Haha, yeah you caught me, I was looking at your contributions and came across your crypto navbox work with the nested collapsible templates. There's about 15,000 other articles that could use this feature that I know of; namely, the ones containing {{fb start}} and {{fb inner start}} (for an example, see {{Football in Northern Ireland}}). I just modified the code above to allow the collapsible lists to be specified as you described, which seems much easier. Now it's time for more testing. Let me know if you have questions on the code...it's done with tons of nested tables and gets very confusing to keep straight. However, all of the spacing is done manually (i.e. with dummy rows/cols) instead of leaving it up to the whim of each browser's default padding/spacing values, so the look should be more consistent. --CapitalR 04:15, 5 September 2007 (UTC)

Yeah there are no lack of articles with more than one navbox. And ouch, dummy rows/cols? So you didn't use the solution I was thinking of. Guess I will test the fairly simple solution I am thinking of. I'll report back to you as soon as I am done. Don't know exactly when that will be since I have a busy schedule ahead of me the next few days. --David Göthberg 06:41, 5 September 2007 (UTC)

Eh, I can sleep some other day. I tested the solution I had in mind, and I read through your code. Man, you must have spent lots of time coding that up and debugging it. I have both good and bad news:

1. The simpler solution I had in mind did work! I coded up a simple demo at one of my test pages. Basically I use a table with no margins, then I create fake cell margins by using borders on some sides of the cells instead.

2. Your solution uses padding:0px in the lists which means the list text comes to close to the groups and also when there is a full text line it comes to close to the right border. Although it isn't a that big deal. But still that means we haven't reached perfection and I am a perfectionist, at least when it comes to programming.

3. Both your and my solution must have padding:0px for lists that hold a subgroup, while we want normal padding (2px or more) for lists that hold text content. But I have come up with a solution: We need to inform the list cell that it has a subgroup. I suggest that we do that by using two kinds of list items, the normal "list1" that is for text content and then "list1sub" that is for subgroup content.

It seems we now can make perfect navbox subgroups with all padding and all margins correct.

--David Göthberg 10:21, 5 September 2007 (UTC)

CapitalR: By the way, the last few days while coding for the article message box standardisation project I learnt that some people think it is very important to be able to "skin" templates. That is, to set different looks by changing/overriding the CSS code in the different skin's CSS files so the template colours etc will match with the rest of the skin's theme. I just wanted to mention that I am right now working on a way to make the navboxes easy to "skin" by just a few easy to understand CSS classes. It will make the code in the navboxes slightly funny but still pretty OK. We will of course still have the options to "hard set" colours etc by using template parameters just like before.

I hope you have the patience to wait for my work?

--David Göthberg 02:33, 6 September 2007 (UTC)

Yup, take your time with the skin classes for the navboxes. I've been working hard to make sure that all of the sub-tables and elements in my design are transparent, so the style only needs to be set in one place in the navbox and the rest of the colors will be inherited. Thus, setting up the skin colors should be a relatively simple process (I hope). I took a look at the border-top / border-left code you used above and am now trying to incorporate it into the new design. Keep me posted on the skin classes. Thanks, --CapitalR 02:54, 6 September 2007 (UTC)

Ehm, the way I am going to use those borders will change now that I want to make them easily skinnable. I will use kind of negative logic. You'll see my examples soon. --David Göthberg 03:16, 6 September 2007 (UTC)

Ok, I now have a primitive demo / explanation of a CSS skinnable navbox at my test page. --David Göthberg 05:01, 6 September 2007 (UTC)

While you guys are at it, can you fix a minor problem (I had made the request when the option was first introduced, but I think it got lost in the shuffle): When navbar is set to default, the title centers properly between "v·d·e" and "[show/hide]"; however, when navabr = plain, the title is centered between the left margin and "[show/hide]", which throws it off a bit to the left. Can the centering be fixed? Regards.--Old Hoss 05:58, 6 September 2007 (UTC)

Yup, I noticed that too and will be sure it gets fixed when we update the code. --CapitalR 06:42, 6 September 2007 (UTC)

I've made up a test page for my new design: User:CapitalR/Test1. Please let me know what you all think. --CapitalR 02:58, 9 September 2007 (UTC)

Oh, seems you have come up with some pretty nifty ideas of how those boxes should be used. (That is, from a user point of view only one single template exists.) But have you noticed your navboxes now are larger than 100% page width? (Sorry to be picky.) I just had the same problem in the navbox code I am working with. I think I have figured out what is going on, just need to test some more stuff before I am ready to explain it. --David Göthberg 04:14, 9 September 2007 (UTC)

Hmm, interesting, I haven't seen the width problem yet. Which browser do you see it in by the way? I've been testing in IE, Firefox, Opera, and Safari (all the latest versions, all running on Vista and XP). --CapitalR 04:28, 9 September 2007 (UTC)

Ok, I finished testing the width problem. Actually, it is not a bug, it is a feature of CSS. I see it in all my browsers and you should see it in all your browsers, if you know what to look for. Look closely at the right border of your navboxes at your Test1 page. That border is more to the right than the end of the "[edit]" buttons in the headers and the underline of the headers and the right borders of the PRE boxes. The right border of your navboxes end exactly 8 pixels more to the right than the other things. Our old navboxes do not do that so your new boxes would not line up nicely with old ones in the same article.

And here is why: I see you use a DIV tag for the outer border and the padding inside that border. Just like I do to in the navboxes I am coding now. And you tell that DIV box to be 100% wide. But the thing is that the "width" of a DIV tag is not its outer width, instead it is its "content" width. So your box gets 100% content width + the width of the paddings and the border = 100% + 2*3 + 2*1 = 100% + 8 pixel.

I tested several ways to solve it. One is to use a table instead of a DIV tag but that causes weird naming of the CSS classes or you will get into style conflicts. (Don't bother about what that means if it isn't immediately clear to you.) The better solution for us seems to be to use two DIV tags instead of one around the navbox. You can see how I do it at User:Davidgothberg/Navibox demo#Hardcoded example.

--David Göthberg 05:12, 9 September 2007 (UTC)

Ah, now I see it. I used your two div trick to get the job done and now it only fills 100% width instead of going a few pixels beyond. I created a new CSS class to allow skinning the padding size. --CapitalR 05:31, 9 September 2007 (UTC)

Ah, now your navboxes look perfect. And yeah, I to use an extra CSS class to allow skinning the padding size. You even named it the same. :))

By the way, are the 4 pixels padding between the right flag and the lists on purpose? In my design I have 2 pixel margin there like around all other cells. I think both look OK.

So you are way ahead of me. But I still think the way I am now building my navboxes will be simpler than your way.

--David Göthberg 07:22, 9 September 2007 (UTC)

The 4 pixels were put there on purpose, but only because that is what is in the current navbox / navbox generic design (I think it's currently 5 or 7 or something, not 4 though). Having 2 pixels works for me; I'll change it tomorrow to see how the difference looks. By the way, I just converted almost all of the Navbox generic templates to Navbox (there's a handful left [366 of the original 5000], which will need to be converted individually instead of using my AWB script). Thus, the current {{Navbox}} is now the last remaining navigational template standard. --CapitalR 07:45, 9 September 2007 (UTC)

Well, 4 or 2 pixels, doesn't matter. Just wanted to check that it wasn't a bug. Oh man, you converted about 5000 templates? I think that after all that work you now need a wikibreak of say two weeks. (Thus allowing me to catch up with my coding of a suggestion for new navbox code...) --David Göthberg (talk) 08:06, 9 September 2007 (UTC)

Navbox subgroup

Can one of you two look at Template:United States Foreign Policy; I am having problems getting the {{navbox subgroup}} groupstyle respond to the "width" parameter of 115px, or even 315px. Either I am making a rookie mistake, or something is overriding it. Regards.--Old Hoss 17:24, 13 September 2007 (UTC)

I fixed it on the template. The problem is that the list defaults to 100% width, which overrides any manual width settings of the group. The solution is to set the groupstyle to the width you want, and the liststyle to "width:auto;". You actually bring up a good point about a confusing part of this template, and we'll have to doc this on the Navbox subgroup page. --CapitalR 18:24, 13 September 2007 (UTC)

Nice fix CapitalR. And Old Hoss, thanks for giving such clear bug reports. Note that I don't think we can change the default liststyle to "width:auto;" since older web browsers don't understand "auto". If we do use "width:auto;" as default then the groups will take 50% of the width in those browsers. But when you do as CapitalR did now and set a fixed width of the groupstyle then it doesn't matter that the old browser does not understand auto. Oh, by the way, at least in theory it is better to set the width of boxes containing text like that by using "em" instead of "px". Since then the boxes will grow with the text size if text sizes are changed later on. "em" is measured in text size. I'll guess I'll take some time and experiment with "auto" and "em" etc on my old browser later today.

Old Hoss: I saw in the history and code of that template that you had been having problems with the line wrapping between the flags and the country name. This is exactly the case where you get nicer code if you use {{nowrap begin}} and its helper templates instead of {{nowrap}}. See docs and examples at {{nowrap begin}}. It's really nifty, I think you will like it.

--David Göthberg 04:45, 14 September 2007 (UTC)

Eliminate CSS3

{{editprotected}}

Per a discussion on MediaWiki talk:Common.css, I'm requesting that the need for CSS3 be removed from Navbox generic (although I'm not sure what edits would be necessary). Anyone? --Dinoguy1000 ^Talk 05:07, 18 October 2007 (UTC)

• Well first, Navbox generic was deprecated and basically nothing uses it now. All instances were converted to use {{Navbox}} instead. I don't believe that Navbox relies on any CSS3 (and I don't think it ever did either) so there shouldn't be any required edits. I'm going to leave the editprotected flag up for an admin to look at who might know more though. --CapitalR 07:05, 18 October 2007 (UTC)
  •  Done. I've put the default colors for above, below and group headers directly in the template, and they can still be overridden using the groupstyle= parameter. Now they show as they are intended on all browsers. — Edokter • Talk • 11:17, 18 October 2007 (UTC)
    • Thanks! --Dinoguy1000 ^Talk 17:24, 18 October 2007 (UTC)

Time to delete?

No articlespace transclusions any more. time to propose deleting and merging this to {{navbox}}? Chris Cunningham (not at work) - talk 11:22, 12 April 2008 (UTC)

Go right ahead and send it to TfD. Don't know what needs merging though. — Edokter • Talk • 12:40, 12 April 2008 (UTC)

Heh. I can't add the {{tfd}} template here because the article is fully protected :) I'll nominate it tomorrow and come back to request editprotected. Chris Cunningham (not at work) - talk 15:11, 12 April 2008 (UTC)

I'll add it... On second thought... It is still transcluded to a lot of talk and image pages. A redirect may be more appropriate. — Edokter • Talk • 15:55, 12 April 2008 (UTC)

Isn't deprecation good enough? The archives here may prove resourceful in the future, and a redirect would change the look of the talk/image page transclusions. –Pomte 18:09, 12 April 2008 (UTC)

Simply deleting it would break those templates in use. They should also be converted first. — Edokter • Talk • 18:35, 12 April 2008 (UTC)

Merge now complete. Chris Cunningham (not at work) - talk 13:17, 15 October 2009 (UTC)