Template talk:Infobox

vertical alignment

The neutrino page has an infobox, which shows an alignment issue that I believe finds its root cause in this template. See Template talk:SubatomicParticle#Weird formatting bug for the discusssion that lead to this conclusion. In short: all cells in an infobox have css top alignment, which means all elements inside the cell are aligned with their top to the top of the cell. This causes incorrect alignment of text in various elements if these elements have different heights, as is the case when you use sub/superscript. Let me try to draw an example of this:

  +--cell-(top align)---------------------------------------------+
  | +-link-------------+ +-text---------------+                   |
  | |      superscript | | More text          |                   |
  | | Text             | +--------------------+                   |
  | +------------------+                                          |
  |                                                               |
  +---------------------------------------------------------------+

Here, "Text" and "More text" should be aligned, but are not. One way to fix this is to wrap everything in an inline element with bottom alignment; here's an example of that:

  +--cell-(top align)---------------------------------------------+
  | +--inline-(bottom align)----------------------+               |
  | | +-link-------------+                        |               |
  | | |      superscript | +-text---------------+ |               |
  | | | Text             | | More text          | |               |
  | | +------------------+ +--------------------+ |               |
  | +---------------------------------------------+               |
  |                                                               |
  +---------------------------------------------------------------+

I'm hesitant to fix this, as I myself haven't the time to check if this works and doesn't break other layout expectations nor revert or fix any errors this may introduce.     — SkyLined (talk) 15:08, 31 October 2011 (UTC)

If no one else steps forward, I'll try to do this myself at some point.     — SkyLined (talk) 13:12, 17 November 2011 (UTC)

I'm happy someone's noticed this problem. I completely lack the skills to do anything here, but I just wanted to express my appreciation for any efforts to be made towards fixing this. Leonxlin (talk) 04:12, 30 December 2011 (UTC)

Not sure it can be fixed. No matter how you align the contents of a cell, if something has different height, it will always be misaligned. — Edokter (talk) — 10:30, 30 December 2011 (UTC)

HOWTO override alignment

How does one override the center alignment for just a row? Or any style setting for that matter? Int21h (talk) 22:40, 6 January 2012 (UTC)

header1
label2	data2
data3

header1
label2	data2
data3

You can override for all header rows (|headern=, where n is a number between 1 and 80), and/or all unlabelled data rows (|datan= with no corresponding |labeln=), but you can't easily override on specific rows except by using CSS classes.

Add either or both of |headerstyle=text-align:left; (which affects |headern=) and |datastyle=text-align:left; (which affects |datan= for rows without a corresponding |labeln=) - see example at right: the top one uses |headerstyle=text-align:left;, the bottom one uses |datastyle=text-align:left;

Styling for individual rows formed using |datan= (with or without |labeln=) may be achieved by means of either |classn= or |rowclassn=, and styling for individual rows formed using |headern= may be achieved by means of |classn=.

The main problem with the class parameters is that you need to find an existing CSS class which has been set up with the style that you want. --Redrose64 (talk) 23:42, 6 January 2012 (UTC)

Infobox historic site

Earlier today I edited the sandbox of {{Infobox historic site}} to be compatible with this template. There are still a few minor kinks to work out, but it's getting there. I do have one question I can't figure out, however. Any idea why this is happening? The relevant parameters that are causing this parser error are |designation1_free1value= and |designation2_free1value=. Those parameters are passed through a child infobox, but other than that, I can see no reason they would trigger an error. It appears something is going wrong within the {{Convert}} template. Any help?--Dudemanfellabra (talk) 01:29, 8 January 2012 (UTC)

{{convert}} is very expensive. If you specify the calculation precision, like this, it doesn't need to decide that for itself, so the expense is reduced. --Redrose64 (talk) 17:48, 8 January 2012 (UTC)

Ah ok I had never run into that problem before; I'll keep that in mind for the future. What still remains to be demonstrated, however, is why running convert through a child infobox triggered an error while just going through the regular infobox template (the |area= parameter higher up in the test case) did not trigger an error. Yes, adding the precision fixes the problem, but where is the actual error coming from? I'm sure that many articles on which this infobox is used do not specify a precision for the convert template, so they would all be broken.--Dudemanfellabra (talk) 22:47, 8 January 2012 (UTC)

It's mainly to do with template expansion depth (see Wikipedia:Template limits and meta:Help:Expansion depth). Templates can use other templates, which in turn can use further templates, etc., but that can't go on for ever. In the case of {{convert|2100|acre|km2|1}} for example, I've not counted the total number of levels, but I find that the small change from {{convert|2100|acre|km2}} to {{convert|2100|acre|km2|1}} subtly amended one of the subtemplates which were used - specifically, from {{convert/round}} to {{convert/pround}}. These are very different inside, and if my calculations are correct, {{convert/round}} goes seventeen levels deeper than {{convert/pround}}. So, explicitly giving the precision saves 17 levels of template depth, which is a significant number compared to the maximum of 40. --Redrose64 (talk) 00:04, 9 January 2012 (UTC)

Good lord! I figured it had something to do with depth, but I had no idea convert was that taxing. I guess that one extra include kicked it over the limit of 40. Looks like that's something we'll just have to deal with then.. or maybe try to fix convert. Thanks for the help!--Dudemanfellabra (talk) 00:24, 9 January 2012 (UTC)

Why is the font-style modifier failing here?

In the Template:Tuskegee Airmen box, the Films section is meant to be in italics.
It is not.
Syntactically, we have:

| group6 = Films
| list6style = font-style:italic;
| list6 =
* Black Eagle (Wild Card character)
* Flight of the Red Tail
* Hart's War
* Henry Browne, Farmer
* Red Tail Reborn
* Red Tails
* Silver Wings and Civil Rights: The Fight to Fly
* The Tuskegee Airmen
* Wings for This Man

However, this is working here in Template:Nuclear weapons tests of the United States, where the syntax is:

| bodyclass = hlist
| group1 = Operations
| list1style = font-style:italic;
| list1 =
* Anvil

From decades of experience, I am familiar with the rare but real case of invisible control codes, so I overwrote the working specimen to produce this:

| group1 = Films
| list1style = font-style:italic;
| list1 =
<!--
 * [[Black Eagle (Wild Cards)|Black Eagle <small>{{noitalic|(''Wild Card'' character)}}</small>]]
 -->
* Flight of the Red Tail
* Hart's War
* Henry Browne, Farmer
* Red Tail Reborn
* Red Tails
* Silver Wings and Civil Rights: The Fight to Fly
* The Tuskegee Airmen
* Wings for This Man

and commented out the anomalous noitalic call.
I kept the numeral 1, in case support does not extend above the nth case.

That does not work either. What is the obvious trouble here?
Varlaam (talk) 18:30, 13 January 2012 (UTC)

They were using different templates. Template:Nuclear weapons tests of the United States uses {{Navbox}} and Template:Tuskegee Airmen uses {{Military navigation}}. I've updated Military navigation to work with this change. -- WOSlinker (talk) 19:23, 13 January 2012 (UTC)

Told ya. The trouble was obvious. Thanks, Varlaam (talk) 15:30, 14 January 2012 (UTC)