Template talk:Navbox/core
From Wikipedia, the free encyclopedia
[edit] Add template doc
{{editprotected}}
Could someone please add the following at the end of this template inside of the noinclude tags (and after the protection template)? This will allow this page to have documentation. Thanks, --CapitalR 14:41, 22 August 2007 (UTC)
{{template doc}}
- Hmm... I would say that it should just link to {{navbox}}'s documentation, since my understanding of {{navbox/core}} is that it's not intended as a stand-alone template (if I'm wrong, feel free to correct me). --Dinoguy1000 Talk 15:26, 22 August 2007 (UTC)
- Actually, Navbox/core was designed to be used by multiple templates. It is currently used by both {{Navbox}} and {{Navbox with columns}}, and possibly will be used by {{Navbox generic}} in the future. Thus, I think it should have its own documentation (not documentation for the average user of Navbox or Navbox with columns; this will be documentation meant only for advanced editors of the core). --CapitalR 15:42, 22 August 2007 (UTC)
[edit] Style whitespacing
{{editprotected}}
This is far more for aesthetics than anything else, but I was hoping someone with edit access could insert spaces in the style attributes - specifically in the two lines causing the source edit box to scroll horizontally. Once again, this isn't anything terribly important, but it would help out with source readability. --Dinoguy1000 Talk 15:31, 22 August 2007 (UTC)
- Sorry, but I don't know which lines you're referring to. Care to clarify? Cheers. --MZMcBride 20:31, 22 August 2007 (UTC)
I think this is what Dinoguy1000 asked for:
<table class="navbox collapsible {{{state|autocollapse}}} nowraplinks" style="margin:auto;{{#ifeq:{{{nogroups|}}}|true||background:white; }}{{#if:{{{l1|}}}|{{#if:{{{l2|}}}|background:white;}}}}{{{bodystyle|}}}"><!--
---Titlebar---
--><tr><th colspan="{{{span|1}}}" style="text-align:center;width:100%;{{{titlestyle|}}}"><!-- --><div style="float:left; width:6em; text-align:left;">{{#ifeq:{{{navbar|}}}|plain||{{Tnavbar| {{{name<noinclude>|Navbox</noinclude>}}}|mini=1}}}}</div><span style="font-size:110%;">{{{title}}}</span></th></tr><!--
In the example above I have added some spaces in places that should not hurt the code but that allow line wrapping often enough to be nice in the edit / view source window. (But it is correct that the lines do not wrap in the pre box I use here.)
--David Göthberg 14:53, 23 August 2007 (UTC)
-
- Yeah, that's more or less exactly what I was after. Thanks! --Dinoguy1000 Talk 23:12, 30 August 2007 (UTC)
[edit] Oddities in the code
The last few days I have studied and tested the code in this navbox. I have found two strange things:
- If the navbox only gets one list item and no group item then it gets grey background instead of white.
- Imageleft is only shown if the navbox has no groups.
Are there any specific reasons for these "features"? When looking in the code it seems to me that the first one is clearly coded on purpose while the second mostly looks like bad coding.
--David Göthberg 02:14, 28 August 2007 (UTC)
- I prevented the imageleft with groups because it looked funny when groups weren't lined up on the left. Don't even ask me why I did that weird color scheme thing, as I can't really remember now. Both of those points you bring up can be easily fixed, and I would be in favor of doing so. --CapitalR 03:15, 29 August 2007 (UTC)
[edit] VDE button changes
This change will affect how the VDE buttons are displayed. The changes will make the color match the titlestyle parameter, and will cut the pages pre-expand size by a few kb. Some editors have complained that the colors don't currently match the title color, so this will fix the problem.
Old code section:
---Titlebar---
--><tr><th colspan="{{{span|1}}}" style="text-align:center;width:100%;{{{titlestyle|}}}"><!--
--><div style="float:left; width:6em; text-align:left;">{{#ifeq:{{{navbar|}}}|plain||{{Tnavbar| {{{name<noinclude>|Navbox</noinclude>}}}|mini=1}}}}</div><span style="font-size:110%;">{{{title}}}</span></th></tr><!--
---Above (optional)---
New code to replace old code section:
---Titlebar---
--><tr><th colspan="{{{span|1}}}" style="text-align:center;width:100%;padding-left:1em;padding-right:0.5em;{{{titlestyle|}}}"><!--
--><div style="float:left; width:5.5em; text-align:left;"><!--
-->{{#ifeq:{{{navbar|}}}|plain| |<!--
--><div class="noprint plainlinksneverexpand" style="font-size:xx-small;white-space:nowrap;font-weight:normal;"><!--
-->[[Template:{{{name|Navbox}}}|<span title="View this template" style="color:#002bb8;{{{titlestyle|}}};font-size:100%;">v</span>]] <!--
--><span style="{{{titlestyle|}}};font-size:80%;font-weight:normal;">•</span> <!--
-->[[Template talk:{{{name|Navbox}}}|<span style="color:#002bb8;{{{titlestyle|}}};font-size:100%;" title="Discussion about this template">d</span>]] <!--
--><span style="{{{titlestyle|}}};font-weight:normal;font-size:80%;">•</span> <!--
-->[{{fullurl:Template:{{{name|Navbox}}}|action=edit}} <span style="color:#002bb8;{{{titlestyle|}}};font-size:100%;" title="You can edit this template. Please use the preview button before saving.">e</span>]</div><!--
-->}}<!--
--></div><!--
--><span style="font-size:110%;">{{{title}}}</span></th></tr><!--
---Above (optional)---
—Preceding unsigned comment added by CapitalR (talk • contribs) 04:48, 17 September 2007
- Actually, it might be easier add a parameter to be passed on to {{tnavbar}}'s fontcolor parameter, and one could change to code to make sure the color is used for the whole title. I think that might be a better solution as titlestyle is used for more than just the color.
- Possible code:
---Titlebar---
--><tr><th colspan="{{{span|1}}}" style="text-align:center; width:100%; {{{titlestyle|}}} {{#if:{{{titlecolor|}}}|; color:{{{titlecolor}}};}}"><!--
--><div style="float:left; width:6em; text-align:left;">{{#ifeq:{{{navbar|}}}|plain||{{Tnavbar| {{{name<noinclude>|Navbox</noinclude>}}}|mini=1|fontcolor={{{titlecolor|}}}}}}}</div><span style="font-size:110%;">{{{title}}}</span></th></tr><!--
---Above (optional)---
- Ms2ger 15:42, 17 September 2007 (UTC)
[edit] Interwiki Links
{{editprotected}}
Could an Admin ad es:Plantilla:Navbox/core and the coresponding other languages? --190.10.203.221 19:26, 22 September 2007 (UTC)
- Interwiki links should be added to the documentation subpage, which is unprotected. I've added the es link for you, but I'm unaware of other interwikis, I'm afraid. Nihiltres(t.l) 01:11, 25 September 2007 (UTC)
[edit] Line gap between lines of same list
{{editprotected}} Per talk in template talk:Navbox hit enter between all l1, l2, l3 etc. See 2 revisions ( [1] and [2] )to see difference of hitting enter {{#if:{{{l3|}}}|<tr>{{#if:{{{g3|}}}|<th style="{{{gs|}}}">{{{g3|}}}</th>}}<td colspan="{{#if:{{{g3|}}}|1|{{#ifeq:{{{nogroups|}}}|true|1|2}}}}" style="text-align:{{#if:{{{g3|}}}|left|center}};{{{os|}}}">(.............HERE.............){{{l3|}}}</td></tr>}}.
Resultant code will look like after enter key in "HERE" (see code enter is not displayed in talk page): {{#if:{{{l3|}}}|<tr>{{#if:{{{g3|}}}|<th style="{{{gs|}}}">{{{g3|}}}</th>}}<td colspan="{{#if:{{{g3|}}}|1|{{#ifeq:{{{nogroups|}}}|true|1|2}}}}" style="text-align:{{#if:{{{g3|}}}|left|center}};{{{os|}}}"> {{{l3|}}}</td></tr>}}.
it should be done to all l1, l2, l3 till end. Just hit enter key before list transclusion, expected o/p can be seen in 2 revisions i gave above. Lara_bran 06:44, 28 September 2007 (UTC)
[edit] Some admin- Here's a fix for above not centering
{{editprotected}} Change from
{{#if:{{{above|}}}|<tr><td style="text-align;center
To
{{#if:{{{above|}}}|<tr><td style="text-align:center
Semicolon->colon. Just like below. -Mak 16:34, 15 October 2007 (UTC)
Done. Cheers. --MZMcBride 04:32, 16 October 2007 (UTC)
[edit] High Use Template
Please note that this template is transcluded on over 340,000 other pages. Great care should be taken to minimize the times that this page is edited, even by admins, to avoid negatively impacting performance. (Note that this is a general comment, not focused on the most recent change.) --After Midnight 0001 05:05, 16 October 2007 (UTC)
[edit] Suggested Design Imporvements
Due to not wanting to get involved in flamewars I did not partake in the construction of this template as much as I'd like. However, I still have a few grips I'd like to voice.
- If this template is fully compatible with {{Navigation}} then why isn't that template redirecting here?
- {{Navigation}} is labeled decrapated. It probably could be redirected, once it is sure nothing breaks. (same goes for {{Navbox Television}}.
- There should be no styles directly implemented in the template. Discussion such as CSS 3? should have been shot down as it add unneed complexity and size to pages. And if we really need to use 95% font-size and nowrap on each cell then it should be implemented in common.css.
- If we want no CSS in here, we end up with an hell of a lot of CSS IDs in Common.css' navbox class. Most inline CSS here (in Navbox anyway, not in /core) does not need to be in a class because they're never used elsewhere.
- First we'd need to use classes, as IDs need to be unique. Second, we'd just need them in the TR elements. The rest would work using CSS selectors.
- If we want no CSS in here, we end up with an hell of a lot of CSS IDs in Common.css' navbox class. Most inline CSS here (in Navbox anyway, not in /core) does not need to be in a class because they're never used elsewhere.
- {{Navbox generic subgroup}} is a perversion of HTML and represents all that is wrong with incorporating tables into wikicode.
- The second example is a grand display of how to turn a semantics design into a bad imitation. We fake headers not even allow it to be skinned.
- The page should redirect to a page on a tutorial of how to create a navbox with the proper wikitable code.
-
- I'm sorry, I can't see anything wrong there. I think the choice to use HTML tables was a very concious one to reduce load on the Mediawiki parser. Code looks clean too.
- I was not complaining about the use of HTML, but the structure that was chosen to accomplish the task.
- Could you give an example? All I see is a straight HTML table. — Edokter • Talk • 03:01, 31 October 2007 (UTC)
- It a nested table what could easily be implemented as a single table with better uniformity too boot. The Accessibility problem with the second example should be obvious to anyone who has ever bothered disabling CSS in their browser. —Dispenser 03:46, 31 October 2007 (UTC)
- Could you give an example? All I see is a straight HTML table. — Edokter • Talk • 03:01, 31 October 2007 (UTC)
- I was not complaining about the use of HTML, but the structure that was chosen to accomplish the task.
- I'm sorry, I can't see anything wrong there. I think the choice to use HTML tables was a very concious one to reduce load on the Mediawiki parser. Code looks clean too.
- VDEcolor should be renamed fontcolor like all the other templates.
- VDEcolor and fontcolor should go alltogether and replaced by the style parameter. In fact, Tnavbar already has a style parameter, but needs a little hacking to accept style.
- This will never work without a javascript hack, simply because there's no way to make the link color "inheritable". Using the style parameter would only color the bullet between the v-d-e.
- Oh but it will work; Try wrapping someting in <font style=... No javascript required! This courtesy of Mediawiki, which is kind enough to place the font tag inside an anchor, even a wiki-anchor, automagically. — Edokter • Talk • 03:01, 31 October 2007 (UTC)
- Your using a using a deprecated element. Also, it does not work when styles for border, font sizes, padding, etc... are specified. —Dispenser 03:46, 31 October 2007 (UTC)
- Oh but it will work; Try wrapping someting in <font style=... No javascript required! This courtesy of Mediawiki, which is kind enough to place the font tag inside an anchor, even a wiki-anchor, automagically. — Edokter • Talk • 03:01, 31 October 2007 (UTC)
- This will never work without a javascript hack, simply because there's no way to make the link color "inheritable". Using the style parameter would only color the bullet between the v-d-e.
- VDEcolor and fontcolor should go alltogether and replaced by the style parameter. In fact, Tnavbar already has a style parameter, but needs a little hacking to accept style.
- The state parameter should be using a parser function so even if its empty it doesn't turn off autocollapse.
- No, an empty state should turn off autocollapse; it was designed that way.
- I thought the same too when I first implemented it [3]. However, its become apparent to me that this is highly non-intuitive and creates bloat in templates downstream.
- No, an empty state should turn off autocollapse; it was designed that way.
- Should be possible to specify a other navbars like {{Unavbar}} or {{Tnavbar}} or {{edit}} with different options.
- Merge them.
- Isn't possible due to technical reasons. The work around is what we have in place unless somebody's planning on extending the parser function to allow use to make talk links out of regular pages. Getting this template to work in userspace is an often requested feature.
- Merge them.
- We don't use 1/4 of the feature offered by tnavbar so why are we using something so big and complexed. I've gone ahead and reworked it to be simpler and 1/3 of the size.
While we're at it could somebody tell me why some editors insisting that we convert from wikitables back to HTML tables? —Dispenser 00:24, 29 October 2007 (UTC)
-
- So that were they get it from, but we don't worry about performance. —Dispenser 01:48, 31 October 2007 (UTC)
[edit] VDE button colors...
...should no longer be a problem. {{Tnavbar}} has been changed to accept the style parameter (and it works too), so I have removed the VDEcolor parameter and passed the titlestyle parameter instead. I also did not need to use the <font style... hack. — Edokter • Talk • 17:54, 5 November 2007 (UTC)
[edit] Adjacent navboxes
I have added a small (1 pixel) space above the navbox table. This is so adjacent navboxes have a space rather than a thick line between them. If there is a way to do this without the code: <div style="height:1px" /> that I inserted please let me know what the parameter is. Thx --Trödel 20:54, 6 November 2007 (UTC)
- Not the most elegant solution. Better way is to add a margin-top: 1px; in the style tag. But I thought it was designed to stack? — Edokter • Talk • 21:03, 6 November 2007 (UTC)
- I had to revert your edit, as the div actually inserted more like 20px space, because the inherited line-height that contols the actual height wasn't accounted for. If you want certain navboxes to seperate, add margin-top: 1px; to the style parameter of the template(s) in question. — Edokter • Talk • 21:42, 6 November 2007 (UTC)
[edit] Fix bad code
{{editprotected}} The template currently begins with
<table ... style="... {{#ifeq:{{{nogroups|}}}|true||background:white; }}{{#if:{{{l1|}}}|{{#if:{{{l2|}}}|background:white; }}}} ...">
which produces background:white;background:white; in most cases. Change the expression to
{{#ifeq: {{{nogroups}}} |true| {{#if: {{{l1|}}} | {{#if: {{{l2|}}} |background:white; }} }} |background:white; }}
which removes the duplication (though I am not sure about the original logic: should having l1 and l2 override nogroups?). Please keep the spacing for better linewrapping and easier-to-read code; also, pipe sign is superfluous in the first ifeq. --Malyctenar (talk) 13:19, 11 February 2008 (UTC)
Not done The logic is correct; neither "background:white;" is guaranteed to execute depending on the evaluation. #if and #ifeq cannot be combined, so it has to be there in both instances. Also, the pipe is there to guarantee the parameter's value is not left undefined, which is needed because the value is evaluated; Evaluating a parameter with an undifed value gives unpredictable results. — Edokter • Talk • 15:16, 11 February 2008 (UTC)
Let me stress again: This fix maintains the logic, removing only the buggy duplication of the background in case both #ifs are triggered. Try writing out decision table – doing it myself seems a waste of time, so I'll hope you see it eventually, or somebody else appears.
You are wrong on the second point as well: an undefined parameter evaluates completely predictably to "{{{nogroups}}}" and as this is in #ifeq , it makes no difference to the logic (while it saves the code length, readability and for all I know may even speed up execution). Or keep the pipe if you must, but fix it.
You might also want to shorten your signature as shown above. --Malyctenar (talk) 14:41, 12 February 2008 (UTC)
- I'll test the fix in the sandbox first; after looking a bit closer, you may be right. As for the pipe; I stand by the fact that not having a default value defined (as that is what the pipe does), is not proper coding.
I stand by the fact that in many cases and particularly when #ifeq tests for some specific value (unlike when you can put pretty much anything into a switching-off parameter which is tested by #if) there's no use in specifying default.
Thanks, but I really wished you had let the spaces in; the code is hard to read and in fact doesn't even fit the screen in diff.
As for your signature, it is pointlessly long and complicated (nesting wikicode for bold text just inside a span) when the same look can be achieved in a simpler way. --Malyctenar (talk) 18:14, 12 February 2008 (UTC)
- I cannot not make it more clear then this: evaluating a parameter without specifying a default value can return random values; that is why parameters within #ifeq should always contain a default value (in then case, [empty]). If in one in a million shot it returns a random "true", then the template fails.
- With code this tight and so often used, every space being output by the parser is scrutinized. The code isn't made to look pretty, but work well and efficient, so formatting spaces are avoided. Notice that even the linebreaks are commented out.
- I use valid HTML/CSS for my signalture. It could be shorter, but not without reverting to decrapated HTML font tags, and I have only just learned not to use those anymore. — Edokter • Talk • 19:16, 12 February 2008 (UTC)
Oh I see - where can I learn more about this one-in-a-million unpredictability?
Code formatted so as to be easy to read and understand is always important, especially so in a massively multi-author online collaboration as Wikipedia. AFAIK the linebreaks are hidden because they mess up parsing the pipe code for tables; and how worrisome performance-wise are occassional whitespaces within commands, widely used everywhere else?
Yes, you do use valid HTML; it's just that it's decidedly suboptimal. You might be interested to learn that by using MediaWiki's ''' and '' markup, you DO produce <b> and <i> tags in the HTML output, démodé or not. Your current signature
<span style="font-family: verdana;"> — [[User:Edokter|<span style="color: #008;">'''''E''dokter'''</span>]] • [[User_talk:Edokter|<span style="color: #080;">Talk</span>]] • </span>
has 180 characters in the wiki source and expands to 261-char HTML
<span style="font-family: verdana;">— <a href="/wiki/User:Edokter" title="User:Edokter"><span style="color: #008;"><b><i>E</i>dokter</b></span></a> • <a href="/wiki/User_talk:Edokter" title="User talk:Edokter"><span style="color: #080;">Talk</span></a> •</span>
Even leaving your way of punctuation with non-necessary trailing semicolons and spaces after colons (not to mention the chance of leaving out quote marks around colors), it can by shortened to 165 characters
<span style="font: 1em verdana;"> — [[User:Edokter|<b style="color: #008;">''E''dokter</b>]] • [[User talk:Edokter|<span style="color: #080;">Talk</span>]] • </span>
(note the space instead of underscore in User talk link; long nonbreakable strings are bad) and 244-char HTML
<span style="font:1em verdana;">— <a href="/wiki/User:Edokter" title="User:Edokter"><b style="color: #008;"><i>E</i>dokter</b></a> • <a href="/wiki/User_talk:Edokter" title="User talk:Edokter"><span style="color: #080;">Talk</span></a> •</span>
But of course, in the end it is as ever your call whether you prefer your own satisfaction, or functionality and regard to others. --Malyctenar (talk) 14:51, 13 February 2008 (UTC)
-
- I hardly see why signature length should be brought up at all on this particular discussion page, but while we're on the topic, I'd like to point out that my own signature is longer than Edokter's, and could not be reasonably shortened without the loss of color effects. —Dinoguy1000 18:44, 13 February 2008 (UTC)
