Template talk:Infobox

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Template:Infobox page.
Please sign and date your posts by typing four tildes (~~~~). Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Ask questions, get answers.	Be polite Assume good faith No personal attacks Be welcoming
Archives: 1

Archives

Archive 1

Contents 1 Proposal to repurpose this template 2 Tnavbar 3 Label background request 4 item... as alternative to label... 5 Accommodating an alternative coloration scheme 6 More label-data entries needed, please 6.1 Take a deep breath 7 Okay, new code without hard-coded backgrounds 8 Header and data can coexist 9 Help please 10 Font-size discrepancies between browsers 11 Nested Infobox 12 KISS 13 Multiple images? 14 Image captions 15 another style parameter for data-only row

[edit] Proposal to repurpose this template

There's been some discussion on the enwiki mailing list about creating a standardized meta-template for infobox creation, in the same general manner as is done with navboxes by {{navbox}}. This template title would seem to be the perfect one to use, and I note that this template is not currently used for much - the few places that do transclude it appear to be transcluding it in error. So, I've whipped up a basic meta-template to replace it with that can be found here: User:Bryan Derksen/Template sandbox. If there are no objections I'll clean up the erroneous transclusions of this template, archive the talk page, and move over the new code for use and further development. Bryan Derksen (talk) 22:33, 22 January 2008 (UTC)

There. I've only put in a maximum of 20 rows at the moment, but since infoboxes often have more rows than that I'll add more later. I just figured I should start out small to make it easier to fine-tune the formatting and styling and such. I'm field-testing the template at Template:Infobox crater data. Bryan Derksen (talk) 20:15, 23 January 2008 (UTC)

That's some excellent work you have done! This template has greatly improved the code and appearance of Template:Infobox public transit (and other infoboxes). --Kildor (talk) 08:11, 16 March 2008 (UTC)

Thanks. Infoboxes tend to be a rather diverse bunch of templates, I hope I struck a good balance between standardization and customizability. There have been a few infoboxes I've come across that this metatemplate still can't handle, but I suppose a few hand-crafted exceptions are no big deal at this point. :) Bryan Derksen (talk) 20:21, 16 March 2008 (UTC)

FWIW, and I'm really late to this, but the original intent of this template wasn't to actually do anything. It was educational in that it allowed editors new to templates and their syntax to see a very simple template that demonstrated many of the common features people usually try to implement on their own. Anyways, there's the historical view as I remember it. Anyways, it's unfortunate that this template got taken over for another purpose. —Locke Cole • t • c 09:08, 15 May 2008 (UTC)

[edit] Tnavbar

I've seen view/talk/edit navbars a million times on other templates, and I understand that they mean v/t/e the template, but my expectation on seeing the new {{Infobox software license}} at BSD licenses was that clicking on "edit" would open up the article's infobox for editting, just like clicking on a section's "[edit]" link. In fact, I pressed it to make a change and was surprised when the source for {{Infobox software license}} appeared! I think the difference from other v/t/e templates is that in the case of an infobox, the "content" is in the article, not in the template. I know we can't make the v/t/e links open up the infobox as defined in the article, so I think the navbar should be removed. RossPatterson (talk) 14:43, 8 March 2008 (UTC)

How about if instead of "this box: " it was labeled with something like "this template: "? I'm not really wedded to the inclusion of a navbar, but it still seems like a handy thing to have. Bryan Derksen (talk) 21:15, 12 March 2008 (UTC)

Or, alternately, I could add a parameter to enable/disable the display of the tnavbar on any given infobox. That way those that it's useful for could still have it. Bryan Derksen (talk) 21:33, 12 March 2008 (UTC)

Yes, it would be nice to have a enable/disable parameter for the tnavbar. And perhaps it would be better to have it disabled as default. In most instances, the infobox content is located in the article rather than in the template, and editing the infobox makes no sense for most Wikipedia readers/editors. I also think that the tnavbar would do better in mini-format at the title bar, as in {{navbox}}. --Kildor (talk) 08:24, 16 March 2008 (UTC)

I had the tnavbar there originally, but it had some significant problems. It caused the title text to be shifted off-center and it isn't compatible with infoboxes that use only the "title" parameter (it only worked when placed inside the table, not in the caption). Since the existing infoboxes I've come across with tnavbars generally had them at the bottom, I figured making that a standard made sense. Bryan Derksen (talk) 19:49, 16 March 2008 (UTC)

v • d • e Example showing v/d/e

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

There, I just reverted {{Infobox/sandbox}} back to an old version where the v/d/e links were at the top in the "above" cell. You can see the off-centeredness of the title that results in the little example I've stuck to the right. I think if there were a show/hide link on the other side that'd balance it out, but I don't know how to add that offhand and didn't consider it as important to implement in infoboxes as it is in navboxes. I suppose I could tinker around with it some more, but not for a little while - I've spent way more time on Wikipedia in recent weeks than I can actually spare. :) Bryan Derksen (talk) 20:17, 16 March 2008 (UTC)

Okay, I've made the tnavbar optional. Simply omit the "name" parameter and it won't be displayed. That means all the existing infoboxes will still have it, since the name parameter was mandatory until this point, but if you've got an infobox you want to take it off of just remove the parameter. Bryan Derksen (talk) 20:00, 16 March 2008 (UTC)

Good solution! And as far as I am concerned, there is no need to spend time to move the v/d/e to title bar. I am happy to have the option to turn the v/d/e links off... --Kildor (talk) 21:05, 16 March 2008 (UTC)

[edit] Label background request

{{editprotected}} This template looks like a boon. Nice work! Just one request, though. The "labels" on virtually all the already-existing infoboxes I've seen so far appear to use background:transparent rather than {{Infobox}}'s current default background:#ddf, so it would seem to make sense to set that default to background:transparent as well. Sardanaphalus (talk) 11:06, 19 March 2008 (UTC)

Absolutely. The shading is pretty offputting and templates have gradually been migrating away from gratuitous use of colour. The defaults really need to reflect the state of the art in how infoboxen are presenting themselves before I'd have a go at migrating the ones I've been maintaining for a while. Chris Cunningham (not at work) - talk 21:12, 20 March 2008 (UTC)

• For the time being, I'm including "background:transparent;" in the labelstyles. Hopefully, though, the {{editprotected}} I've just added might prompt some action. Sardanaphalus (talk) 22:52, 20 March 2008 (UTC)

I simply copied the default colors from {{navbox}} when I first set this up. Personally, I don't think the shaded background is gratuitous. When the background is the same as the body of the table I often find it difficult to tell where one row ends and the next row begins, especially in infoboxes where the data cells are multi-line and there's a lot of space between the label text and the data text. Is there someplace more centralized for discussing global stylistic concerns like this? I didn't find one last time I went looking, closest seemed to be Wikipedia:WikiProject Infoboxes and they specifically disclaim being a place for infobox standardisation. Bryan Derksen (talk) 21:06, 22 March 2008 (UTC)

N Not done Sounds like an uncontroversial change but, as I said below, no admin will touch that with a bargepole unless they know or are told exactly what needs to be changed. If you copy the code to a sandbox, change it however you need and then come back here and say "copy the code from this permalink", I'll be happy to oblige. Happy‑melon 22:26, 22 March 2008 (UTC)

Okay, although the original description seems clear to me (to paraphrase, "set the default bacground for labels to transparent"). Infoboxes aren't navboxes, so perhaps this is san area where copying the code from Navbox verbatim wasn't such a good idea. If WikiProject Infoboxes isn't the place to discuss/clarify default settings, then I don't know where else would be! Sardanaphalus (talk) 12:05, 24 March 2008 (UTC)

Yeah, this is one I could have done but which I didn't do because I opposed it. Not strenuously, but I think this is something that common practice gets wrong and navbox gets right. I suppose we could discuss it here, this may well be the best place for it since nobody seems to know of a better one. Bryan Derksen (talk) 15:27, 24 March 2008 (UTC)

• I feel the default setting for the label background ought to be "transparent" as that's how it looks across virtually all the infoboxes I've seen so far (something like 99%). Setting it to be transparent doesn't mean it can't be set differently from one infobox to the next, thanks to the labelstyle parameter. If the consensus was to use color, I reckon I should've seen far more than 1% of infoboxes doing so...? Sardanaphalus (talk) 22:39, 26 March 2008 (UTC)
  • The reason it's so prevalent might also be due to the fact that it's easier to leave the backgrounds blank when hand-crafting a table from scratch. :) I'm kind of wary about trying to figure out consensus from second-hand things like existing hand-crafted infobox tables (granted, most of them are transparent) and navbox (I presume navbox's style has seen a massive amount of debate but it's not in exactly the same role here). I'd rather see more people chime in, but since there's no pre-existing place for discussing this particular matter I'm not sure how to get more eyes in on this. A couple of ideas come to mind:
    • Canvas a couple of related places calling for input; manual of style talk pages, the navbox talk page, maybe some noticeboards.
    • Use default-style infoboxes in a bunch of prominent places so that lots of people will form an angry mob and come over here to "set things right" (with "right" being determined by whatever consensus they come up with). I'm only half serious with this one, but it may bear some thought - there's nothing that gets people more interested in correcting something than being clearly wrong about it. The downside is that it may be interpreted as violating WP:POINT. :)

I suppose if it's two-to-one in favor of transparent backgrounds right now we could call that a weak consensus and go with transparent defaults until further discussion can be had at some later date. I've suffered worse traumas on Wikipedia before and survived. Bryan Derksen (talk) 20:17, 28 March 2008 (UTC)

Well, I prefer the current color/layout, so I guess it is two-two now... :) --Kildor (talk) 21:33, 28 March 2008 (UTC)

• Another approach is to keep the status quo until any more people come knocking. As {{Infobox}} finds more use – which I think it should! – then more people will be given the chance to notice and respond to its defaults. In the meantime, to keep the status quo of the infoboxes I convert to use it, I'm including "background:transparent" in the labelstyle. Sardanaphalus (talk) 12:35, 30 March 2008 (UTC)

I've put out a request for more input at Template talk:Navbox, Wikipedia talk:WikiProject Infoboxes and Wikipedia talk:Manual of Style (infoboxes). I tried to make my requests non-biased-sounding, and if anyone knows of good hangouts for template-editors and infobox-editors who might be interested in participating by all means invite more in. Bryan Derksen (talk) 16:58, 1 April 2008 (UTC)

It seems like you have changed the default background color to transparent anyway. But now when I see the result, I am changing my mind. It does look better with transparent background. --Kildor (talk) 11:35, 3 April 2008 (UTC)

[edit] item... as alternative to label...

{{editprotected}}

Another request: Please add itemstyle and itemN as alternatives to labelstyle and labelN as I reckon they can be thought of as either. Thanks. Sardanaphalus (talk) 22:52, 20 March 2008 (UTC)

What is the purpose of an "item" parameter? Is it simply another name for label, or should it have some different meaning and implementation? --Kildor (talk) 08:14, 21 March 2008 (UTC)

Simply an alternative (part of a) name for "label". So I'm imagining the code would use syntax like {{{item1|{{{label1|}}}}} etc. Sardanaphalus (talk) 09:29, 21 March 2008 (UTC)

I am sorry, but I still not understand. What is the point having an alternative name, if it only affects how the code is written? --Kildor (talk) 10:06, 21 March 2008 (UTC)

There is no point. We should aim to keep syntax as consistent as possible, and this would not be a good change. Chris Cunningham (not at work) - talk 11:32, 21 March 2008 (UTC)

Okay, I get the picture. Sorry not to've communicated my intentions more clearly. The change would have no effect on consistency (typos notwithstanding). Sardanaphalus (talk) 16:12, 21 March 2008 (UTC)

The consistency being referred to is the naming of the parameters that accomplish particular tasks, so having two different names for a parameter that accomplishes the exact same task would indeed be inconsistent. I'm also thinking that the parameter name "item" is itself less clear on its meaning - it seems to me that it could just as easily mean the data associated with the item rather than the label for that data. Bryan Derksen (talk) 21:16, 22 March 2008 (UTC)

[edit] Accommodating an alternative coloration scheme

{{editprotected}} Would it be sufficiently straightforward/worthwhile to amend the template to accommodate a coloration scheme such as here? (Reminds me of the Navbox oddstyle and evenstyle.) Sardanaphalus (talk) 03:22, 21 March 2008 (UTC)

I pondered how to do that when I first started setting this up and it's not as easy as it might seem, since with infoboxes rows are very often optional. I can't think of an easy way to determine which rows are "even" and which are "odd" when any given row may or may not be present in the infobox displayed in the article. I'm not familiar with the deeper intricacies of parser functions, though, so there may be techniques I'm unaware of that would simplify things. Bryan Derksen (talk) 21:02, 22 March 2008 (UTC)

N Not done I'm not touching that (and neither will anyone else :D) unless you can say exactly what needs to be changed! Happy‑melon 22:23, 22 March 2008 (UTC)

I'd love to do it, mind you. I just don't know how. :) Bryan Derksen (talk) 08:29, 24 March 2008 (UTC)

Understood. When I pass by Template:Infobox Lunar crater again, I'll try converting it to an {{Infobox}} without the previous color scheme and see if/when anyone reacts. Sardanaphalus (talk) 12:07, 24 March 2008 (UTC)

You might want to take a look at {{Infobox crater data}} when you do. I created that one for use both in cases where there wasn't a specialized infobox template for a crater on a particular body and for use as a meta-template when defining other crater infobox templates ({{MarsGeo-Crater}}, {{Mercury crater data}}, {{Venus crater data}}). I did it a while ago though so it may need refinements. Bryan Derksen (talk) 15:56, 26 March 2008 (UTC)

[edit] More label-data entries needed, please

{{editprotected}} Hi. I've converted a template to {{Infobox}} but it has (wait for it) 55 possible label-data entries, so would someone with access to the code please increase the number of available of label-data entries from 40 to (say) 60. Thanks. Sardanaphalus (talk) 00:50, 26 March 2008 (UTC)

• Y Done I've increased the limit to 60. I'm sure at some point the parser police will come for me, but we don't seem to be hitting any limits yet. :) Bryan Derksen (talk) 05:59, 26 March 2008 (UTC)

• Thanks. Hopefully the parser police won't be stirred as I can't image many infoboxes with as many possibilities. Sardanaphalus (talk) 11:10, 26 March 2008 (UTC)

[edit] Take a deep breath

I spoke too soon. I'm now working a merged version of two templates (Template:Infobox Airliner accident and Template:Infobox Mid-air accident) that is going to need at least 67 label-data entries. Would pushing the number implemented here to 75 or 80 be too high? Sardanaphalus (talk) 12:25, 26 March 2008 (UTC)

I don't see any reason why not, I've just never done anything with quite so many #if:s before. My comment about parser police was mostly tongue in cheek. :) Make sure to post here if you encounter any strange effects from using that many rows, though, just in case. Bryan Derksen (talk) 14:50, 26 March 2008 (UTC)

Oh, since you've been making a lot of template edit requests and you seem like a sane and capable person who's really into infoboxes, would you like me to switch this template to semi-protection so you can tinker with it yourself? I realize that it may mean labels will switch to background:transparent; by default and this will cause me a brief moment of pain as my soul leaves my body, but I don't want to be seen as some sort of monster gatekeeper imposing his will on Wikipedia. I'll still argue the case for shading in talk, of course. (side note: I've been using background:inherit; when these situations arise instead of background:transparent, I'm not sure if there's any significant difference but it might be worth a look through the CSS docs to see if there is.) Bryan Derksen (talk) 16:18, 26 March 2008 (UTC)

Thanks for boosting the label-data number again and offering to ease the template's protection. I'm probably tempting fate, but I don't imagine I'll find myself requesting anything more in the near future, so it's probably best to keep the template safe. Thanks for the thought, though. I'll post some thoughts about the default background above. Sardanaphalus (talk) 22:30, 26 March 2008 (UTC)

[edit] Okay, new code without hard-coded backgrounds

{{editprotected}}

Tidied the whitespace up a bit and dropped some excessive styles (such as some hard-coded italic). This code is basically the same as is used in {{infobox Game}}, {{infobox computer}} and most other infoboxen I've worked on.

This drops the hard-coded blue fields and some other unnecessary styling.

Copied here for a quick visual. The code is available at User:Thumperward/infobox.

<table class="infobox {{{bodyclass|}}}" cellspacing="5" style="width:21em; text-align: left; font-size: 90%; {{{bodystyle|}}}">
<!-- Caption-->
{{#if:{{{title|}}}|
<caption class="{{{titleclass|}}}" style="font-size: 130%; font-weight: bold; {{{titlestyle|}}}">{{{title}}}</caption>}}
<!-- Header-->
{{#if:{{{above|}}}|
<tr><td colspan="2" class="{{{aboveclass|}}}" style="text-align:center; font-size: 130%; font-weight: bold; {{{abovestyle|}}}">
{{{above}}}
</td></tr>
}}
<!-- Image-->
{{#if:{{{image|}}}|
<tr><td colspan="2" style="text-align:center; {{{imagestyle|}}}"> {{{image}}} {{#if:{{{caption|}}}|<br />
<span style="{{{captionstyle|}}}">{{{caption}}} }}</span>
</td></tr>
}}
<!-- Row 1-->
{{#if:{{{header1|}}}|
<tr><th colspan="2" style="text-align:center; {{{headerstyle|}}}">{{{header1|}}}</th></tr>
| {{#if:{{{label1|}}}|{{#if:{{{data1|}}}|
<tr>
<th style="{{{labelstyle|}}}">{{{label1|}}}</th>
<td class="{{{class1|}}}" style="{{{datastyle|}}}">{{{data1|}}}</td>
</tr>
}}
| {{#if:{{{data1|}}}|
<tr><td colspan="2" class="{{{class1|}}}" style="text-align:center; {{{datastyle|}}}">{{{data1|}}}</td></tr>
}}
}}
}}

Repeat the code under Row 1 for another eighty or so rows...

<!-- Row 80-->
{{#if:{{{header80|}}}|
<tr><th colspan="2" style="text-align:center; {{{headerstyle|}}}">{{{header80|}}}</th></tr>
| {{#if:{{{label80|}}}|{{#if:{{{data80|}}}|
<tr>
<th style="{{{labelstyle|}}}">{{{label80|}}}</th>
<td class="{{{class80|}}}" style="{{{datastyle|}}}">{{{data80|}}}</td>
</tr>
}}| {{#if:{{{data80|}}}|
<tr><td colspan="2" class="{{{class80|}}}" style="text-align:center; {{{datastyle|}}}">{{{data80|}}}</td></tr>
}}
}}
}}
{{#if:{{{below|}}}|
<tr><td colspan="2" style="text-align:center; font-size:small; {{{belowstyle|}}}">{{{below|}}}</td></tr>
}}
<!-- Tnavbar-->
{{#if:{{{name|}}}|
<tr><td style="text-align:right;" colspan="2">{{Tnavbar|{{{name}}}}}</td></tr>
}}
</table><noinclude>{{documentation}}<!-- Add categories and interwikis to the /doc subpage, not here! --></noinclude>

There are no semantic changes to the old code, just some style tweaks and addition of whitespace to make it easier to read. Chris Cunningham (not at work) - talk 21:17, 31 March 2008 (UTC)

Which styling does it change, exactly? There's not many people participating in the discussion yet, but of the ones that are there doesn't seem to be a clear consensus on whether to color the the default label backgrounds. Also, all the text styling of the existing infobox can be overridden with style parameters as well (there isn't anything "hard-coded", simply default), so IMO it's fine to include some text styling in order to increase the consistency across infoboxes. Bryan Derksen (talk) 00:04, 1 April 2008 (UTC)

It makes minor edits to the cell padding, title font size and such, which can be quickly compared by looking at the top three rown and comparing it to the existing template. Internally, the only change it makes from the current version (other than whitespace) is to remove a hardcoded background:#ccf from every single row. If individual projects want to add a colour (like WikiProject Comics) then they need only add one attribute to their own templates (and indeed have already done so). Meanwhile, it means that projects which don't want the colour don't need to go overriding it. As for consistency, I'd argue that infoboxen have, over time, been moving to using less colour and that lots of high-profile ones have already phased it out. Chris Cunningham (not at work) - talk 00:15, 1 April 2008 (UTC)

The other tweaks to styling mostly look fine to me, but the default width doesn't match the guidelines at Wikipedia:Manual of Style (infoboxes)#Design and usage. And I still think that without any visual markers to show where each label begins and ends it makes it harder to visually associate which label goes with which bit of data. I'd really like to see more of a discussion on that rather than simply going with what's popular simply because it's popular. Bryan Derksen (talk) 16:29, 1 April 2008 (UTC)

I'm happy for the width to be tweaked. As for the aesthetics, well, all I can do is request the change and point out that the trend has (until this template's revival) been away from colour. WikiProject Video games, for instance, moved to a colourless version for all their infoboxen after extensive discussion at the end of January. Unlike {{navbox}}, the fields in question are not so long that visual distinction between them is usually difficult (at a width of less than 30 ems, and with what are usually key-value pairs). Chris Cunningham (not at work) - talk 17:58, 1 April 2008 (UTC)

Well, I'm not going to fight to the death over it. I was about to switch to colorless a few days back when Kildor showed up and ruined everything by agreeing with my own opinion. :) I've put out a call to a couple of other talk pages to get some more participants in the discussion, but if nothing else crops up I guess I'll start implementing style changes and see if that causes any complaints. Nothing stylistic is actually hard-coded with the current design so there's no rush on any of this. Bryan Derksen (talk) 18:19, 1 April 2008 (UTC)

Cool. Cheers! Chris Cunningham (not at work) - talk 18:21, 1 April 2008 (UTC)

N Not done for now, as consensus does not appear to be forthcoming. If more discussion occurs and a consensus emerges to change, readd the template. Happy‑melon 14:35, 6 April 2008 (UTC)

[edit] Header and data can coexist

I just took a close look at this new meta-template. I was surprised when the docs said: "When a header is defined on the same row as a data cell the header takes precedence." From what I see in the current code that means that if a header is input for a row then the label and data is not shown. I find that counter intuitive. I was expecting to be able to specify header1, label1 and data1 at the same time, and thus see header1 above label1+data1.

All we have to do to make that happen is to disconnect the #if statement for the header. That is, put the label and data stuff after it, instead of inside it. Like this:

{{#if:{{{header1|}}}
| <tr><th colspan="2" style="text-align:center;
  {{{headerstyle|}}}">{{{header1|}}}</th></tr>
}}{{#if:{{{label1|}}}
| {{#if:{{{data1|}}}
  | <tr><th style="{{{labelstyle|}}}">{{{label1|}}}</th><td
    class="{{{class1|}}}" style="{{{datastyle|}}}">{{{data1|}}}</td></tr>
  }}
| {{#if:{{{data1|}}}
  | <tr><td colspan="2" class="{{{class1|}}}" 
    style="text-align:center; {{{datastyle|}}}">{{{data1|}}}</td></tr>
  }} 
}}

--David Göthberg (talk) 01:02, 3 April 2008 (UTC)

"Counterintuitive" is in the eye of the beholder. :) The reason I did it this way is because this way each row in the infobox has its own number, and I felt it would be more confusing to have two "row 8"s than it would to have items overriding each other when placed on the same row. I can your view too, though, so I don't know which is better. Fortunately the existing uses of the template will be backward-compatible if at some point we change over to allow headers and labels with the same row number, though switching back again would be less so. Bryan Derksen (talk) 03:39, 3 April 2008 (UTC)

Right, "counterintuitive" is in the eye of the beholder, that's why I changed from the word "illogical" just seconds before I saved. :)

And right, this change should be possible to do without changing existing boxes. But changing back will then not be possible. But I see no reason why one would want to change back. After all, if headers and labels would be allowed on the same row then infoboxes could use a lower number of rows.

--David Göthberg (talk) 08:21, 3 April 2008 (UTC)

There'd still be the same number of rows, it only looks like there'd be fewer because some of them would share the same row number. That's the bit that I'd have conceptual trouble with, the sharing of row numbers between adjacent rows. Most infoboxes only have two or three headers at most so IMO the practical effect on the size of the template will be minimal. Bryan Derksen (talk) 07:08, 7 April 2008 (UTC)

So, what does everyone else think? There are starting to be a fair number of people who are using this template, so if the current arrangement is unintuitive by all means toss in your !vote. I'm probably too close to the design myself to be certain about what "makes sense" in general usage so I welcome third-party input like this (plus, I'm not the template's guardian monster so I shouldn't say "third-party" there :). I just inadvertently hid a data row with a header myself while doing an infobox conversion so I'm open to being swayed. Bryan Derksen (talk) 19:17, 9 April 2008 (UTC)

[edit] Help please

Someone please point out why the caption in the Infobox-based template below isn't wrapping. I'm guessing it's something I'm overlooking, but can't see what.

[defunct link removed]

Thanks. Sardanaphalus (talk) 22:36, 4 April 2008 (UTC)

Your bodystyle parameter had some trailing syntax cruft, presumably from your copy-paste. I've fixed it in your sandboxed template. For what it's worth, you'd have a much easier time if you weren't micro-managing the template style by overriding things everywhere. The simpler the markup, the easier it is to debug (and work on in the future), and the more consistent infoboxen are across Wikipedia. Ditto with the unnecessary font size overrides. Chris Cunningham (not at work) - talk 22:56, 4 April 2008 (UTC)

Thanks for spotting the copy-paste error. Sorry you don't like the "micro-managing", but unfortunately many of the current default sizes/positions/etc yield wide gaps between (wrapped) lines, questionable font-size relationships, etc. Maybe someday what might currently look like "micro-management" might become default. Thanks again. Sardanaphalus (talk) 00:48, 5 April 2008 (UTC)

[edit] Font-size discrepancies between browsers

I just noticed that the font-size set for the .infobox class has discrepancies between at least IE and Firefox. See the screenshots to the right. The cause is that the font-size has been set to 90% in common.css; a value that dangles between two rendition the two browssers, who obviously have a slightly different base font-size. I want to get rid of this dicrepancy by adjusting it to a value that produces the same font-size. However, I would need to know what the intended font-size was to begin with; the small (Firefox) or the bigger (IE) rendition.

For comparison, .navbox has a base font-size of 88%, which renders the small font on both IE and Firefox. And for reference, see User:Edokter/fonttest to see how the different sizes render in your browser (play with your browser's font-size). — Edokter • Talk • 14:35, 12 April 2008 (UTC)

I just used the font-size value that was here in the "example" code that this template used to contain, as seen in this revision: [1]. The edit that changed the font size to that is this one, from September 25 2006: [2]. It mentions that the edit was done "per talk page", looking in the old archives I think this is the discussion that's being referred to: Template talk:Infobox/Archive 1#titling. Ironically, the change was done "so that there can be a standard that definitely renders correctly for all Wikipedia users". Apparently the previous value of 95% caused some inconsistencies with boxes overlapping things and wrapping words. I have no idea when and where the css pages were edited similarly, you'd probably know better where to find that information than me, but considering that there was practically no discussion of the issue here I don't imagine there'd be any really solid reason not to tweak the font size to 88% if that makes things more consistent across major browsers. A 2% font size change shouldn't be all that big a deal. Bryan Derksen (talk) 05:48, 13 April 2008 (UTC)

2% may not seem much, but the difference to IE users will be clearly visible as demonstrated to the right. If there are no further objection though, I'll change it to 88% in the near future. — Edokter • Talk • 15:05, 17 April 2008 (UTC)

[edit] Nested Infobox

Hi again. In the opposite, how do I (1) prevent the gap between "{{Infobox}} 1" and the start of Infobox 2, (2) remove the padding/margin to the left of Infobox 2?

{{Infobox}} 1

{{Infobox}} 2

Code

|data1 = {{Infobox}} 1
|data2 = {{Infobox
         |bodystyle = font-size:100%;
         |data1 = {{Infobox}} 2
         }}
}}

Thanks. Sardanaphalus (talk) 14:33, 17 April 2008 (UTC)

(1) I fixed the template to remove any extranious line-breaks.

(2) Add margin:0; to the 2nd infobox's bodystyle.

— Edokter • Talk • 14:53, 17 April 2008 (UTC)

{{Infobox}} 1

{{Infobox}} 2

Code

|data1 = {{Infobox}} 1
|data2 = {{Infobox
         |bodystyle = font-size:100%; margin:0;
         |data1 = {{Infobox}} 2
         }}
}}

• Thanks, Edokter! Sardanaphalus (talk) 07:05, 19 April 2008 (UTC)

[edit] KISS

system provides uniformity and makes infobox creation easier, but is it necessary for all infoboxes, and does it make the big picture overly-complex? !! time= 23:38, 19 April 2008 (UTC) }}

Regarding this conversion to use Template:infobox, and the over all purpose of this template, I don't see the point. Doesn't this make it harder to edit the infobox, with out any real benefit? It would be far easier to just use normal wikitable syntax and follow some kind of guideline for helping to standardize the template. And if anyone is wondering, I feel the same way about {{Navbox}}, though I think the argument is stronger for infoboxes. -- Ned Scott 05:48, 18 April 2008 (UTC)

And while my understanding of CSS is limited, I thought that's what the table class was for, this kind of common formatting. -- Ned Scott 06:17, 18 April 2008 (UTC)

• I support {{Infobox}} because for me it usually makes seeing the wood for the trees easier. In other words, to take the previous and current {{Infobox Film}}'s code, the current version is much more user-friendly to me because virtually all the repeating {{!}}s, {{!}}-s, {{#if:}}s, etc are gone. Ditto {{Navbox}} (and variants) with navboxes. So, more a case of {{Infobox}} (and {{Navbox}}es) MakingISS. Sardanaphalus (talk) 07:04, 19 April 2008 (UTC)

• I'll repeat what I said on Template talk:Infobox Film: I still think it makes things needlessly complicated in the big picture. Infobox film doesn't have to be "easy to edit" for every single editor, and it's protected from editing anyways. There's tons of editors who easily understand how to edit the template, if an edit is needed. This used to be one of the very few templates that one could even copy onto another installation of MediaWiki without making any modifications, because it was a well crafted template.

• We're supposed to be dealing with parser functions, and we're supposed to be making hand-crafted changes (when necessary). Everything else can be covered in the infobox CSS class.

• This does more to limit future options and possible custom considerations, because we wouldn't be able to have any unique code. This is fixing a non-existent problem. I insist on reverting back to the previous code until we can discuss this some more. -- Ned Scott 23:34, 19 April 2008 (UTC)

• Wow... well, let's see what your request for comment brings. I don't think {{Infobox}} is about fixing a non-existent problem, but about making infoboxes easier to create and maintain. I think, for instance, I'm less likely to mislay or miscount "}}"s and "}}}"s, etc. Sardanaphalus (talk) 08:12, 20 April 2008 (UTC)

• If an infobox needs unique code, then by all means hand-craft an infobox for it. There are still lots of navboxes out there that have hand-crafted code to accomplish things that the {{navbox}} template can't yet handle. However, in most of the cases I've seen, the "unique" code in infoboxes simply serves to steepen the learning curve for any new editor who comes along and doesn't accomplish anything that this template can't accomplish in a more standardized manner. Bryan Derksen (talk) 19:06, 20 April 2008 (UTC)

• It's possible for pure-template markup to be unmaintainable gunk just like with wikitables, admittedly. However, not only does using {{infobox}} consistently help to make infoboxen across the project look and behave similarly, it also leads to cleaner code when done right. It can be seen from the example code that almost all of the trimmed material is syntactical cruft. I'd also point out that similar movements have taken place across the board ({{navbox}}, {{userbox}}, {{ambox}}) and that the trend is clear. As for "future options and possible custom considerations", in my experience it's possible for the generic templates to accomplish (or to be modified to accomplish) basically anything that could reasonably be required from an infobox, and that there's no point in having infinite flexibility just for flexibility's sake. I suppose conversion wholeheartedly. Chris Cunningham (not at work) - talk 11:24, 20 April 2008 (UTC)

• Well, I've come across a number of infoboxes in my travels that have features that can't be easily reproduced with infobox. I've simply left those ones alone. Perhaps in the future {{infobox}} will be expanded to handle more; I added on microformat-handling parameters after the fact, for example. Bryan Derksen (talk) 18:58, 20 April 2008 (UTC)

Ned, I've noticed that you've been going around and reverting templates away from using {{infobox}} without any explanation in either talk pages or edit summaries, and for no readily apparent reasons. I count 28 of these on April 19 alone. This strikes me as being just as disruptive as trying to force {{infobox}} on a template that it can't handle in the first place, something I've avoided doing. Could you at least raise specific objections when you do something like that? I see no reason not to simply roll back such unexplained reversions. Bryan Derksen (talk) 18:58, 20 April 2008 (UTC)

I should apologies for that. At first I was only going to go through a few that seemed very obvious (ones that didn't even use any complex coding like parser functions), but got caught up in my own frustration. I'm waiting to get more input from this RfC, and yes, in the future I will try to better explain individual situations. -- Ned Scott 02:39, 21 April 2008 (UTC)

I'll holding off re-reverting them too, then, at least not without addressing each one in detail to make sure I didn't break anything. I suspect that in a lot of cases where there weren't parser functions used it was because they're tricky for novice templateers to figure out how to use in the first place rather than because they wouldn't be useful. But everyone makes mistakes and I'm willing to be convinced otherwise. Bryan Derksen (talk) 04:20, 21 April 2008 (UTC)

This is an interesting idea, but of course not one that should be rolled out over all infobox templates. Many infobox templates are quite simple in terms of layout, containing a simple 2-column table and maybe an image (eg. Infobox Film) so I can see no problem there, but for more complicated ones that are under constant development (eg. {{Infobox Settlement}}) I would be against such a change since its content is far more complex than this setup can allow in a manageable way. 52 Pickup (deal) 11:48, 23 April 2008 (UTC)

I think the very simple ones should be left alone (no parsers, etc), but we should definitely strive for some visual consistency. I guess it does make sense for templates like the Film one to be converted, because they're far from simple, but at the same time they're protected. I guess I can't say I have a strong opinion on those ones like I did before, having thought more about it (being, ones that are complex, but protected). This does seem to be a very nice tool for making and maintaining infoboxes, and there probably won't be much of an issue. -- Ned Scott 06:10, 24 April 2008 (UTC)

[edit] Multiple images?

{{editprotected}}

So {{infobox software}} has both the logo and screenshot attributes. Can we get image1/caption1 etc. to accommodate this? Cheers. Chris Cunningham (not at work) - talk 17:51, 22 April 2008 (UTC)

Yes, but where abouts? What code needs to be added where? Happy‑melon 17:59, 22 April 2008 (UTC)

The current code is:

-->{{#if:{{{image|}}}|<tr><td colspan="2" style="text-align:center; {{{imagestyle|}}}"> {{{image}}} {{#if:{{{caption|}}}|<br />
<span style="{{{captionstyle|}}}">{{{caption}}} }}</span></td></tr>}}<!--

Add the following lines directly afterwards to enable a total of three maximum image/caption pairs:

-->{{#if:{{{image1|}}}|<tr><td colspan="2" style="text-align:center; {{{imagestyle|}}}"> {{{image1}}} {{#if:{{{caption1|}}}|<br />
<span style="{{{captionstyle|}}}">{{{caption1}}} }}</span></td></tr>}}<!--
-->{{#if:{{{image2|}}}|<tr><td colspan="2" style="text-align:center; {{{imagestyle|}}}"> {{{image2}}} {{#if:{{{caption2|}}}|<br />
<span style="{{{captionstyle|}}}">{{{caption2}}} }}</span></td></tr>}}<!--

Chris Cunningham (not at work) - talk 18:05, 22 April 2008 (UTC)

That would produce three image stacked together. Do we actually need multiple images here? You can easily hack image= to include images in the same way. — Edokter • Talk • 19:50, 22 April 2008 (UTC)

I'd rather not include hacks in individual instances of the template if it can be fixed cleanly upstream. Using additional parameters appears to be the most logical and intuitive way to do it, and would be the smoothest way to move templates like {{infobox software}} over to using {{infobox}} as far as I can see. Take a look at AbiWord, bash or irssi for the desired effect. Additional captions aren't strictly required here but there's no reason not to offer them just in case. Chris Cunningham (not at work) - talk 21:24, 22 April 2008 (UTC)

It's not really a hack; just use image = [[Image:]]<br/>[[Image:]], especially if you don't need the extra captions. That could be done in the templates to be convereted, so I don't really see the need to add extra parameters in this template when it isn't used that often. — Edokter • Talk • 22:04, 22 April 2008 (UTC)

Alternately, you can use data cells without labels to provide pretty much the same thing as the image cell. Just go data1= [[Image:blah.jpg]]<br/>Caption text to add another centered image. Bryan Derksen (talk) 18:12, 2 May 2008 (UTC)

N Not done for now - please establish a consensus for how best to implement this. Happy‑melon 11:54, 23 April 2008 (UTC)

[edit] Image captions

The current infobox template does not pass on image caption to the image tags themselves. Meaning that if you put your mouse over the image of Albert Einstein in his article, instead of display the caption from the TITLE field of the image, it says the filename. More seriously, as a result of this, the ALT tag of the images displayed through this template is blank—both incorrect by web standards as well as rendering the image inaccessible and invisible to those who rely on ALT tags.

I don't know enough about template syntax to dare mess with it myself, but surely there is a way to take the caption parameter and pass it into the bit that creates the framed image, without forcing anyone to change how they use the infoboxes? I think it's something that should definitely be done ASAP. --Fastfission (talk) 00:34, 9 May 2008 (UTC)

There is no easy way (or one at all) to do this automatically; The given image paramter expects a full image syntax, including the [[ and ]], so there is no way of injecting the caption into this. As a workaround, you can enter the caption in both the image and caption parameter. — Edokter • Talk • 13:37, 9 May 2008 (UTC)

You could use something like this code snippet:

|image= [[Image:{{{filename}}}|{{{caption}}}]]
|caption= {{{caption}}}

That would break existing templates horribly; image= was designed to enter the entire images syntax. — Edokter • Talk • 18:25, 26 May 2008 (UTC)

No, that code snippet is for calling the infobox template from the specific infobox being converted to use it. So if you're already using the name "image" for your image filename parameter, your template would consist of:

{{infobox
|title= My Infobox
|image= [[Image:{{{image}}}|{{{caption}}}]]
|caption= {{{caption}}}
|label1= Content 'n' Stuff
|data1={{{contentnstuff}}}
}}

And soforth. It's like object-oriented programming, we're overriding the meaning of the "image" parameter using a wrapper that modifies and passes it along to the parent template. I've done this trick with other infoboxes before and it works just fine. Bryan Derksen (talk) 22:16, 26 May 2008 (UTC)

There, I just updated {{Infobox Scientist}} to do this - see [3]. If you put your pointer over Albert's picture you get an informative alt text now. Bryan Derksen (talk) 22:22, 26 May 2008 (UTC)

[edit] another style parameter for data-only row

Hello, I'm using this template in Japanese Wikipedia, thanks! (though the two templates differ in very detail) When I use data-only row (data cell without label), often feel another style parameter for data-only rows would be great. For exmaple, when you try to apply this template to Template:Probability distribution, you would probably use data-only rows for image cells and have to code like:

|datastyle = text-align:left<!-- for normal data cell -->
|data1 = <div style="text-align:center">...

Such cases occur quite often because data-only rows and normal data cells usually have different "text-align" style. Can we have a special style parameter for data-only row? --125.201.158.128 (talk) 08:55, 15 May 2008 (UTC)

I'm not sure how easy it would be to add such a parameter, offhand, but in this particular case the default already works the way you're requesting. A data cell with a label defaults to left alignment and a data cell with no label defaults to centered alignment. Example:

Label1	Data1 (left aligned)
Data2 (centered)

You could also use headers for special row formatting, assuming you weren't using headers as headers already. Bryan Derksen (talk) 17:38, 26 May 2008 (UTC)

Thank you for teaching. I haven't noticed that the default already works well since I manually set datastyle = text-align:left, which overrides the default.

However I still want the new parameter. It will be like:

<!-- Row 1 -->{{#if:{{{header1|}}}|<tr><th colspan="2" style="text-align:center; {{{headerstyle|}}}">{{{header1|}}}</th></tr>| {{#if:{{{label1|}}}|{{#if:{{{data1|}}}|<tr><th style="{{{labelstyle|}}}">{{{label1|}}}</th><td class="{{{class1|}}}" style="{{{datastyle|}}}">{{{data1|}}}</td></tr>}}| {{#if:{{{data1|}}}|<tr><td colspan="2" class="{{{class1|}}}" style="text-align:center; {{{datastyle|}}};{{{specialdatastyle}}}">{{{data1|}}}</td></tr>}} }} }}

specialdatastyle (the name is just an example) is the new parameter. --125.201.3.209 (talk) 17:39, 7 June 2008 (UTC)