Template talk:Infobox/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

Infobox autoupdate/date

I wonder if it was ever explored to get the updatedate date automatically which by now has to be typed manually and is forgotten to do to oftenly. Whenever the data set of the infobox is edited it should be possible to obtain the date from the edit log, where it is stored, too. As the update date is displayed in many other infoboxes, there may be the chance that somebody has created a little java-script already. In case you have an idea or a result pls let me know. --Maxxl2 (talk) 21:33, 29 April 2012 (UTC)

I assume that you are thinking of dates such as those at the bottom of {{Infobox thoroughbred racehorse}}. This is not a feature of the generic {{infobox}}, but {{Infobox thoroughbred racehorse}} has been coded in such a way that if a parameter |updated= is filled in on an article using that infobox, whatever has been filled in there will be displayed after the label "Last updated on". See for example The Tetrarch - the infobox on that article contains the parameter |updated=February 17, 2011, which displays as "Last updated on February 17, 2011". This parameter expects text, which is not validated as a date in any way, so |updated=the course at Ascot will display as "Last updated on the course at Ascot".

It is left to the article editor to decide whether that date should be amended or not when an edit is made. There are several problems with such a parameter, some of which are discussed at Template talk:Infobox thoroughbred racehorse#"Updated" parameter. For me, the main one concerning automation is this: how would an automatic system know that it is the data inside the infobox that has been amended, rather than the text outside it? There are some variables which may be used to show the date of the most recent edit: either the {{REVISIONTIMESTAMP}} alone, or a combination of {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}, perhaps pushed through {{#time:j F Y|{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}}}. But whichever is chosen, those will be the date of the most recent edit to any part of the article, and cannot be restricted to the infobox, or even to just one section. The page history log records dates and times; it sometimes shows section names. Infoboxes are usually (but not always) in the lead section: but edits to the lead section do not record a section name in the log, and that is also true of edits to the whole page. Just as a whole-page edit cannot be distinguished from a lead-section edit in the history log, so a lead-section edit which affects text outside the infobox cannot be distinguished from a change to the infobox.

The only way that I know of to accurately show infobox change dates within the infobox, in such a manner that edits to other parts of the page do not affect these dates, is to split infobox from article - i.e. put it into a template page, which is then transcluded into the article, as has been done for the chemical elements - see hydrogen/{{infobox hydrogen}}; helium/{{infobox helium}}; etc. These infoboxes do not contain revision date information - they are just examples of article/infobox split. --Redrose64 (talk) 23:15, 29 April 2012 (UTC)

Very interesting to learn more about the template design opportunities. What i learned is, that is impossible using existing features within the template to have an automatism that changes the "last update" dates. So we have to ask again to pay more attention to this whenever the infobox data is changed. Thx again. --Maxxl2 (talk) 09:20, 30 April 2012 (UTC)

Child parameter inherits styles?

Is there a way, when using the child=yes parameter, to have the child inherit styles of the parent template? The template I'm working with, {{Infobox road}}, has a handful of parameters which control the style of the headers. I would prefer to not pass through all the style-affecting parameters to the subinfobox; inheriting styles would greatly simplify this. –Fredddie™ 00:52, 15 May 2012 (UTC)

Row styling

I am looking to update an older infobox that uses currently different colored rows. Any way to make that happen? Spanning the text of course only changes the background of the actual text, leaving gaps. ---— Gadget850 (Ed) ^talk 10:42, 23 April 2012 (UTC)

Header1
Label2	Data2
Header3
Label4	Data4
Header5
Label6	Data6

{{infobox |header1=Header1 |rowclass1=" style="background-color:red; |label2=Label2 |data2=Data2 |rowclass2=" style="background-color:orange; |header3=Header3 |rowclass3=" style="background-color:yellow; |label4=Label4 |data4=Data4 |rowclass4=" style="background-color:green; |header5=Header5 |rowclass5=" style="background-color:blue; |label6=Label6 |data6=Data6 |rowclass6=" style="background-color:violet; }}

It's a bit kludgy, since it misuses the |rowclassn= parameters; and you can't style a header that way, just label/data. --Redrose64 (talk) 13:51, 23 April 2012 (UTC)

Perfect! Thanks. ---— Gadget850 (Ed) ^talk 14:36, 23 April 2012 (UTC)

How about adding individual parametrs for style of every rows' header, label and data? It is not difficult to do... I think I can do it myself, but template is protected (and these things is not good to do oneself only =)) What do you think about it? --Base^talkсontr. 21:11, 13 June 2012 (UTC)

Page exceeded the expansion depth

Hi, further to a comment I posted at [1], I've found by experimentation that the infobox at the article Heligoland, in and of itself, causes a "Page exceeded the expansion depth" error. I found this by editing the article, then deleting everything except the infobox, then previewing, and I get the said error. I don't know if this is a misuse of the template in that article, or a problem with the template itself, but I mention it here in case anyone has the inclination and ability to find out what is going wrong. 86.179.113.84 (talk) 01:02, 18 May 2012 (UTC)

{{Infobox German location}} is using recursive string templates {{str find}} and {{substr_any}} to extract the district code and display the relevant imagemap (the map which displays when you click "[show]" in the infobox). This can probably be rewritten more efficiently, but the logic is a bit beyond my comprehension at the moment! — Richardguk (talk) 08:54, 18 May 2012 (UTC)

What is the "tidy extention" and where can I find it?

The title is pretty self explanatory, but all the same, I tried to move the infobox template to my personal wiki, but couldn't get it to work, after reading through the documentation again, I discovered the tiny line at the end, (which really should be at the top somewhere) saying that you need the "tidy extension".

What is the tidy extension and where can I find it? I've looked on the media wiki page, but can't seem to find it.124.171.236.236 (talk) 15:48, 31 May 2012 (UTC)

Ergh... Nevermind, I give up on this...124.171.236.236 (talk) 16:24, 31 May 2012 (UTC)

Pretty sure that refers to HTML Tidy. You need to enable $wgUseTidy. ---— Gadget850 (Ed) ^talk 02:17, 1 June 2012 (UTC)

Child infoboxes on wikis without HTML Tidy

This template normally works reasonably well when imported to wikis without the HTML Tidy extension enabled, in spite of the line in its documentation suggesting otherwise - see the documentation examples in this straight port for an example. The only problem I've ever noticed is with child infoboxes: for each child infobox, the plaintext </td></tr> is produced.

After some experimentation and carefully reading through the code, I've figured out that this is caused in the {{Infobox/row}} instance that the child infobox ends up in, where the code opens a <tr><td> pair and then the child infobox's code immediately starts. Since a child infobox is just a set of naked table rows, without a <table/> tag, the parser prematurely closes the previously opened table row. However, this means that after the child infobox is finished parsing, the parser encounters an extra pair of closing tags, and, having nothing to pair them with and instead of simply discarding them, it escapes them and outputs them as plaintext.

This can be fixed easily enough by simply adding the opening tags <tr><td> to any of the {{#ifeq:{{{child|}}}|yes|... statements in {{Infobox}}, but this can lead to phantom whitespace. A better fix then becomes something like <tr style="display:none;"><td> (thus preventing the display of the empty row and, therefore, the phantom whitespace), but the best fix would be to address this problem at the root. I've tried to come up with a way to do so, but can't think of any. Can anyone else (and, if so, could this fix be added to this template so that future reusers don't have to worry about this problem)? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 03:24, 21 July 2012 (UTC)

In the sandobx, I've added module params to Template:Infobox/sandbox & Template:Infobox/row/sandbox, so instead of using:

| data64 = {{{module|}}}
| data65 = {{{module2|}}}
| data66 = {{{module3|}}}

You would use:

| module64 = {{{module|}}}
| module65 = {{{module2|}}}
| module66 = {{{module3|}}}

Haven't tested that it works though. -- WOSlinker (talk) 06:40, 21 July 2012 (UTC)

Well, it does fix the stray markup, but it exposes a coding idiosyncrasy: in child navboxes, the proper display of the title parameter actually depends on the opened table row/cell for proper display (in a child navbox, all markup from the opening <table/> tag to the above row is omitted, and title, if it is provided, is just dropped in wherever it happens to be without any containing markup). This can be fixed by wrapping that output in its own table row (I was hoping to be able to take advantage of it to fix the markup problem without needing a new set of parameters, but that happens in just the wrong way for it to work).

I've updated the documentation to reflect this change, and now I'm wondering about getting these changes added to the deployed template here (I would just do so, but adding a parameter to the template system, particularly when it involves passing it through in 80 of the transclusions of /row, goes well beyond my level of willingness to risk getting yelled at =) ); this would eliminate one problem potential reusers face, and the above section is proof enough that most reusers already have enough difficulty in just getting it to work, without the added burden of figuring stuff like this out. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 08:22, 21 July 2012 (UTC)

Another way would be to add some code so that title doesn't work when child=yes. And then mention that in the docs. -- WOSlinker (talk) 09:46, 21 July 2012 (UTC)

@Dinoguy1000 - I'm a bit puzzled. Twice you've mentioned <table />, which is an invalid tag - <table>...</table> is not an empty element but an enclosure, so has opening tag <table>, some content, and a closing tag </table>, all three of which are required. --Redrose64 (talk) 13:18, 21 July 2012 (UTC)

@WOSlinker: Yeah, but that would only fix the problem with title; fixing the stray markup would still require the extra parameter.

@Redrose: I'm aware of that - I simply use that as shorthand when I'm feeling too lazy to write out the full pair in discussion; I don't actually have any expectation of it being valid markup. ;) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 16:27, 21 July 2012 (UTC)

Support for header90 is missing

The document says, “Row numbers may be from 1 to 80”, but the template actually supports Rows up to 99. However, header90, label90, data90, class90 are not supported:

...
}}{{Infobox/row
 |header={{{header88|}}} |headerstyle={{{headerstyle|}}}
 |label={{{label88|}}}   |labelstyle={{{labelstyle|}}}
 |data={{{data88|}}}     |datastyle={{{datastyle|}}}
 |class={{{class88|}}}   |rowclass={{{rowclass88|}}}
}}{{Infobox/row
 |header={{{header89|}}} |headerstyle={{{headerstyle|}}}
 |label={{{label89|}}}   |labelstyle={{{labelstyle|}}}
 |data={{{data89|}}}     |datastyle={{{datastyle|}}}
 |class={{{class89|}}}   |rowclass={{{rowclass89|}}}
}}{{Infobox/row
 |header={{{header91|}}} |headerstyle={{{headerstyle|}}}
 |label={{{label91|}}}   |labelstyle={{{labelstyle|}}}
 |data={{{data91|}}}     |datastyle={{{datastyle|}}}
 |class={{{class91|}}}   |rowclass={{{rowclass91|}}}
}}{{Infobox/row
 |header={{{header92|}}} |headerstyle={{{headerstyle|}}}
 |label={{{label92|}}}   |labelstyle={{{labelstyle|}}}
 |data={{{data92|}}}     |datastyle={{{datastyle|}}}
 |class={{{class92|}}}   |rowclass={{{rowclass92|}}}
}}{{Infobox/row
...

Technically this is not a bug, since 81+ is undocumented in the first place. But “1 to 99” is more intuitive, flexible, and convenient, and the template does support 1–99 already, except 90. So it should support 90 too. Thanks! (I can't quick-fix the broken Template:Infobox planet, since that one is protected too.) —Gyopi (talk) 10:34, 6 September 2012 (UTC)

PS. I forgot to say this: Template:Infobox planet is broken because it happens to use header90. —Gyopi (talk) 10:37, 6 September 2012 (UTC)

D'oh. I had a sneaking suspicion I'd let one of those by. Now fixed. Cheers! Chris Cunningham (user:thumperward) (talk) 11:28, 6 September 2012 (UTC)

Related discussion at Village Pump

Please see Wikipedia:Village_pump_(proposals)#Add_functionality_to_include_links_to_sister_projects_in_infoboxes . --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 17:02, 11 September 2012 (UTC)

Please review sandbox version (padding)

In a quest to remove obsolete HTML, I tinkered with the "cellspacing" (border-spacing in CSS). I found the current 5px to generous, so I made it 3px. I have not removed the actual cellspacing attribute alltogether, as it affects older browsers, so they are now both present (CSS overrides old style HTML attributes anyway). please review the new look in Template:Infobox/testcases. — Edokter (talk) — 11:01, 7 October 2012 (UTC)

It still fails validation of course, but I guess we will have to live with that. ---— Gadget850 (Ed) ^talk 13:29, 7 October 2012 (UTC)

Only the fallback fails; modern browsers ignore it anyway because border-spacing is present. HTML5 and supporting older browsers bite eachother, there is no way around that until we drop support for older browsers (IE6.7) like a brick. — Edokter (talk) — 14:02, 7 October 2012 (UTC)

Edit request on 29 October 2012

| management = Stephen Budd and Al Lavelle

Sbcragg (talk) 17:25, 29 October 2012 (UTC)

Not done: this is the talk page for discussing improvements to the template {{Infobox/Archive 7}}. Please make your request at the talk page for the article concerned. --Redrose64 (talk) 17:54, 29 October 2012 (UTC)

Subbox styling

I have seen instances where it would be useful to use this template as a "subbox" in the same spirit as {{navbox subgroup}}. Currently, we have "child" which isn't exactly what I need, since it removes the outer table. What I want is to embed an infobox in another infobox, infobox3cols, or sidebar. The issue is that each of those templates has a different default number of columns, so they are not compatible in the standard "child=yes" manner. As a first attempt to make this possible, I created {{infobox subbox bodystyle}}. After creating it, I was thinking that it was probably possible to just add this logic directly into this template, in the same way that {{navbox|subgroup}} works. If there is support for adding this feature, I can certainly code it up. The prototype for how it would actually work in terms of appearance and functionality can be found in the documentation for {{infobox subbox bodystyle}}. Since this style statement is templated, we can easily find them and convert them latter if support is added here. thank you. Frietjes (talk) 17:33, 30 October 2012 (UTC)

Table summary

I would like to suggest that a table summary parameter be added. See Help:Table#Summaries. It should be straight forward. Add summary="{{{summary|}}}" inside the table tag. I added code to the current sandbox and testcases.

I don't have any experience with this attribute. w3schools says its not supported in HTML5 but works in HTML 4.01. It is, evidently, supported in Wiki markup. –droll [chat] 07:09, 9 November 2012 (UTC)

P.S. It is my understanding that a table summary is akin to alt text. There should be no noticeable impact on HTML rendered by a standard browser but is available to screen readers. The presence of the summary can be checked in the HTML source code. –droll [chat] 07:42, 9 November 2012 (UTC)

I've updated the sandbox as the code wasn't synchronized with the main template. Everything looks to be working, and this seems like a good idea. However, I'm going to hold for more comments as this template has 1.2 million transclusions and we need to make sure we get the implementation right first time. By the way, do you know how this kind of thing is handled in HTML5? — Mr. Stradivarius ^{(have a chat)} 11:22, 9 November 2012 (UTC)

It will generate a validation error now that we render HTML5. ---— Gadget850 (Ed) ^talk 11:35, 9 November 2012 (UTC)

T43917 ---— Gadget850 (Ed) ^talk 12:24, 9 November 2012 (UTC)

Not done: Ah, I was afraid of something like that. So ideally this should be fixed in the MediaWiki software, but until that's done we have the choice of either going without the summary field and generating valid HTML, or including the summary field and generating invalid HTML. I'm deactivating the edit protected template until we find a consensus on what to do. — Mr. Stradivarius ^{(have a chat)} 13:24, 9 November 2012 (UTC)

It's better to ignore w3schools, who don't always get it right; and go straight to w3c, which is at least official - even if ignored by Microsoft. The summary= attribute of the <table> tag, which was valid in HTML 4.01, is obsolete in HTML 5. Alternatives are described at 4.9.1.1 Techniques for describing tables. --Redrose64 (talk) 15:54, 9 November 2012 (UTC)

And that is my proposed fix— to update rendering to use HTML5 <details> / <summary>. Whenever that gets done, we can revisit this proposal. I anticipate that the wikimarkup will not change. ---— Gadget850 (Ed) ^talk 19:35, 9 November 2012 (UTC)

Infobox/row styles

Would there be any issues with moving the hardcoded styles in {{Infobox/row}} to MediaWiki:Common.css? The following CSS should be close to what's required:

.infobox th {
  text-align: left;
}
.infobox th[colspan=2],
.infobox td[colspan=2] {
  text-align: center;
}

Thoughts? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 20:39, 19 December 2012 (UTC)

Yes, there would be issues. The first rule directly contradicts the default infobox table header behaviour of centering the text. There are some situations where desired behaviour can only be achieved with inline CSS. This is one of them. — Edokter (talk) — 21:42, 19 December 2012 (UTC)

Right, I should've checked for that. =/ Is there any reason not to slap a class on there and target that instead, then? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 22:16, 19 December 2012 (UTC)

Might consider using scope attribute and targeting that with common.css —TheDJ (talk • contribs) 15:27, 4 January 2013 (UTC)

Infobox

Hi I have tested some new codes in template:Infobox/sandbox I would like to include the codes in template:infobox — Preceding unsigned comment added by 86.159.27.117 (talk) 00:52, 27 January 2013 (UTC)

You just added extra rows, but you did not explain why they are needed. — Edokter (talk) — 09:28, 27 January 2013 (UTC)

so that people could add more information like for example if you were to go to lable 99 and you wanted to add more that why I added more rows 86.159.27.117 (talk) 12:19, 27 January 2013 (UTC)

I just reviewed the changes as well, and technically it looks OK. Please provide an example where 100+ data rows are needed. Infoboxes ae intended as an overview of the subject. --— Gadget850 (Ed) ^talk 12:31, 27 January 2013 (UTC)

There's no need as you can always use embedding to add more than 100. -- WOSlinker (talk) 12:36, 27 January 2013 (UTC)

oh ok 86.159.27.117 (talk) 18:47, 27 January 2013 (UTC)

Individual styles

The question has been asked, but no responses since then. Is it possible to add individual styles for each row (as in datastyle(n), labelstyle(n))? 178.216.128.99 (talk) 11:44, 4 February 2013 (UTC)

Possible, yes. But one has to consider if this benifitial. If there will only be a handfull of infoboxes using it, then it doesn't outweigh the increased load of double the amount of parameters to process by the million of templates that don't use it. — Edokter (talk) — 20:42, 4 February 2013 (UTC)

Extra white space generated when embedding

In the example below there is extra white space between row1 and row3. The reason is that {{Infobox}} causes the generation of an empty row. It might be a an artifact generated by the parser in an attempt to tidy the HTML markup.

Top level title

row1

row3

row4

{{Infobox
| title = Top level title
| data1 = row1
| data2 = {{Infobox | child = yes
  | data3 = row3
  | data4 = row4
  }}
}}

I think this is undesirable. If there is consensus, perhaps an additional parameter could be added below the last data parameter that does not generate a table row, or some other workaround can be found. Sample code is in the sandbox. –droll [chat] 21:36, 5 February 2013 (UTC)

My solution limits the number and location of embedded templates. –droll [chat] 21:39, 5 February 2013 (UTC)

Top level title

row1
child title
row3
row4

{{Infobox
| title = Top level title
| data1 = row1
| header2 = {{Infobox | child = yes|decat=yes
  | title = child title
  | data3 = row3
  | data4 = row4
  }}
}}

the issue is that you are not using the "title" parameter in the embedded box, which is how embedding was originally imagined. perhaps what is needed is some logic for when the template is embedded and there is no title parameter. I generally use the child parameter as a way to create sections, where each section has a header. clearly if there is no header, then you get a blank row, which is undesirable, but the way it currently works. to get around this in some situations, I created {{infobox subbox bodystyle}}, which also does a sort of embedding, but uses a second table so the label widths are not linked between sections. Frietjes (talk) 21:56, 5 February 2013 (UTC)

Interesting and I can use your ideas. I need to think about it some more. –droll [chat] 22:23, 5 February 2013 (UTC)

your idea should definitely should be explored, since the current methodology has issues when the embedded box does not have a section heading. Frietjes (talk) 16:18, 6 February 2013 (UTC)

I've been mulling this over. The present code simply doesn't support the first row very well. I've made an improvement in the sandbox where it at least presents titles as proper headers, but this comes at the expense of Tidy having to clean up the table (and results in an empty row before the module, albeit hidden). For the time being, though, that fixes the double-bold issue and is a moderate gain, so I think that should be synced. In the long run, we probably want to directly support freeform HTML in the rows by adding |child1=,|child2= etc to {{infobox/row}}, and having it output nothing but the child data. This eliminates the empty row problem. Thoughts? Chris Cunningham (user:thumperward) (talk) 14:16, 12 February 2013 (UTC)

I like your idea but I think the author should be free to define the style of the title header in the embedded infobox. Something like:

headerstyle={{#if:{{{childstyle|}}}|{{{childstyle|}}}|{{{headerstyle|}}}}}

This would be useful if the {{{headerstyle}}} in the parent infobox is undesirable for the title of the child. I'm not too crazy about the new parameter name. If backward compatibility is important then perhaps something like:

headerstyle={{#if:{{{childstyle|}}}|{{{childstyle|}}}|font-weight:bold;}}

would be appropriate. I haven't tested any of this so use caution. –droll [chat] 19:49, 12 February 2013 (UTC)

I've thought about it a bit more and perhaps something like:

headerstyle={{ifempty|{{{childstyle|}}}|{{{headerstyle|}}}|font-weight:bold;}}

should be considered. –droll [chat] 20:50, 13 February 2013 (UTC)

Edit request on 24 March 2013

Image caption styling

Some styling requires a <div>, not <span>, so please replace the corresponding lines in the code (near the beginning) with the following:

 Image1
-->{{#if:{{{image|{{{image1|}}}}}}|{{Infobox/row
 |data={{{image|{{{image1}}} }}}{{#if:{{{caption|{{{caption1|}}}}}}|<div style="{{{captionstyle|}}}">{{{caption|{{{caption1}}}}}}</div>}}
 |datastyle={{{imagestyle|}}}
 |class={{{imageclass|}}}
 |rowclass={{{imagerowclass1|}}}
}} }}<!--
 Image2
-->{{#if:{{{image2|}}}|{{Infobox/row
 |data={{{image2}}}{{#if:{{{caption2|}}}|<div style="{{{captionstyle|}}}">{{{caption2}}}</div>}}
 |datastyle={{{imagestyle|}}}
 |class={{{imageclass|}}}
 |rowclass={{{imagerowclass2|}}}
}} }}<!--
 Image3
-->{{#if:{{{image3|}}}|{{Infobox/row
 |data={{{image3}}}{{#if:{{{caption3|}}}|<div style="{{{captionstyle|}}}">{{{caption3}}}</div>}}

CsDix (talk) 12:30, 24 March 2013 (UTC)

How does it 'require' a div? Also, has this been tested in the sandbox? — Edokter (talk) — 12:57, 24 March 2013 (UTC)

<span style="line-height:X; ..."> don't work. Apologies for not including the amended code in the sandbox version – I'd tested it elsewhere. Now in place. CsDix (talk) 13:09, 24 March 2013 (UTC)

I can't see how it's not working. Do you have an example? — Edokter (talk) — 13:42, 24 March 2013 (UTC)

Yes – the sandbox examples (rightmost examples) at Template:Infobox aircraft occurrence/testcases. Caption lines that wrap should be closer together (probably too close once this span/div wrinkle fixed, so I'll widen them accordingly). CsDix (talk) 06:24, 25 March 2013 (UTC)

I see caption wrapping on three of the testcases (Template:Infobox aircraft occurrence/testcases#American Airlines Flight 587, Template:Infobox aircraft occurrence/testcases#Tenerife airport disaster, Template:Infobox aircraft occurrence/testcases#Korean Air Lines Flight 007) but there is no visible difference in line spacing between the left and right. --Redrose64 (talk) 09:52, 25 March 2013 (UTC)

I'm marking this as answered for now. This is a very widely used template, so the changes will need to be tested to everyone's satisfaction before we implement it. Once testing is complete, please reactivate the request. Best — Mr. Stradivarius ^{♪ talk ♪} 10:28, 25 March 2013 (UTC)

• That there's no visible difference in line-spacing is precisely the symptom that suggests to me that the <span>s don't seem to be working – if they were, those lines in the sandbox (rightmost) examples would be much closer together (probably too close, given the sandbox version's current captionstyle setting). Is replacing "<br/><span>...</span>" with "<div>...</div>" fraught with danger..? CsDix (talk) 14:26, 25 March 2013 (UTC)

Infobox aircraft occurrence/sandbox was using Infobox, I've now changed it to use Infobox/sandbox and a difference can now be seen. -- WOSlinker (talk) 14:58, 25 March 2013 (UTC)

Thanks, WOSlinker! As I thought, the line-spacing was far too close (now amended). I've also re-enabled the edit request – hope that's okay. CsDix (talk) 15:44, 25 March 2013 (UTC)

The difference is due to an actual difference in the line-height values passed through the templates, not because of the span vs. div argument. There is no difference between the rendering of line-heights between spans and divs. The is however a difference in padding behaviour, but as long as no custom padding is used, it still results in the same. The <br /><span>...</span> construct is there to prevent any (older) browser from creating a too large gap between the image and the caption. If there are no visible differences on the testcases page (especially in IE), then I don't see a problem. Until then, I disabled the request for now. — Edokter (talk) — 19:54, 25 March 2013 (UTC)

Understood, I think. When the time comes to update {{Infobox aircraft occurrence}}, I'll see what happens as regards this line-spacing and proceed accordingly. Thanks for the explanations. CsDix (talk) 10:33, 26 March 2013 (UTC)

Image + caption

Hi. The current code for the infobox image and associated caption uses <br /> and a <span>. Can we kill the <br /> and switch to a <div> instead? --MZMcBride (talk) 20:22, 8 April 2013 (UTC)

As soon as I posted this section, I noticed the section directly above, of course. I don't think older browsers should be an issue here. However, the inability to use padding or margin properties with "captionstyle" (as it's a span and not a div) is an issue. --MZMcBride (talk) 20:26, 8 April 2013 (UTC)

Support for colours

Add support for colours so we can change the colours of the Infobox please Skybliei (talk) 14:58, 11 April 2013 (UTC)

This
can
already	be
done!
WOSlinker (talk) 18:13, 11 April 2013 (UTC)

More rows

This template has, apparently a limit of 80 rows, This, in turn, limits other templates, such as {{Infobox church}}, which therefore do not use this one. Can we add more rows, perhaps taking advantage of Lua? Is there any reason Lua could not allow us to code an effectively infinite number of rows? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 15 April 2013 (UTC)

the switch to lua is in development, see Module:Infobox. once this is completed, there should be no limit on the number of rows. Template:Infobox church could be switched right now using the method used by {{infobox power station}}. Frietjes (talk) 16:51, 15 April 2013 (UTC)

That's great; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:05, 15 April 2013 (UTC)

The limit hasn't been 80 rows for a long time. There have been 99 directly-usable rows since September last year (and the documentation has also shown 99 since 6 Sep 2012); and even before that, the "embedding" feature has permitted, in theory, an infinite number (subject to template expansion limits). --Redrose64 (talk) 17:11, 15 April 2013 (UTC)

Infobox subbox bodystyle

Main 1
Main 2
Sub 3-1 Sub 3-2 3-3 This sub-table lost the space between border due to border-collapse, and also might receive extra padding if main <td> has some padding
Main 4
Sub 5-1 Sub 5-2 5-3 This sub-table does not declare border-collapse, and while this retains space between table cells, this adds even more border-spacing between <table> and <tbody>
Main 6
Sub 7-1 Sub 7-2 7-3 Best I could do using margin:-3px; to offset the border-spacing, padding:0px; to remove padding set by .infobox class, but this does not work well in narrower sub-boxes like below 7-4 This might be good if you really use this as a sub-section and do not mind the shrinkage, but bad if you use this for collapsible table section
Main 8
Sub 9-1 9-2 The same sub-box, gets narrower by 6px when collapsed :(
Main 10
11	Sub 11-1 11-2 Sub-label 11-3 This might also be another use?

Is there any reason why we can't merge {{Infobox subbox bodystyle}} with this template? It looks like we would just need change

style="border-spacing: 3px; width:22em;

to

style="{{#ifeq:{{{subbox|}}}|yes
 |border-collapse:collapse; border:none; width:100%; margin:0px; font-size: 100%; clear:none; float:none;
 |border-spacing: 3px; width:22em;
 }}

It seems like this was the original intent from the discussion at WT:WikiProject Infoboxes. Some CSS experts may also be able to suggest some improvements? Thanks! Plastikspork _―Œ^(talk) 23:13, 27 April 2013 (UTC)

Added some comparison on the right. I am being picky on the loss of border-spacing between cells, but otherwise there is not much good method to prevent additional space around sub-boxes. Some reading below:

• Inside-Only CSS Table border-spacing
• Box Sizing

As a side-note, {{Navbox subgroup}} uses border-collapse:collapse either, and try to re-create border-spacing using borders and empty rows. — Peterwhy 05:27, 28 April 2013 (UTC)

I had only tried it in cases where there was no background cell colouring, so it wasn't so obvious that there was space being removed. I like your suggestion of using a negative margin instead. in any case, I'm just glad to see there is some momentum for adding this feature to this template. thank you. Frietjes (talk) 16:05, 28 April 2013 (UTC)

Another point to note: my experience with MediaWiki mobile view has not been happy, and I know mobile view always wants to control how tables look. It could be a hard time to ensure mobile users see sub-boxes consistently. — Peterwhy 19:50, 28 April 2013 (UTC)

the additional padding is not entirely a bad thing, if we want a visual cue that these are subheadings. of course, its good to be able to make this additional padding optional. as far as mobile goes, they didn't support hlist for quit some time and that didn't seem to be a show stopper. I say we go ahead unless there is a more obvious way to achieve the same thing. I will see if some other "CSS experts" have any ideas. thank you. Frietjes (talk) 20:21, 6 May 2013 (UTC)

That leads back to one of my questions: what is this sub-box actually meant for? If I would like to use that for collapsible section, then I don't think sub-box is what I wanted. — Peterwhy 01:55, 7 May 2013 (UTC)

it's primarily meant for uses outlined in the documentation for Template:Infobox subbox bodystyle. if you simply want to collapse something you can use {{hidden}}, but this is meant to be more general. Frietjes (talk) 15:58, 7 May 2013 (UTC)

Request

okay, so it seems there are no objections to the negative margin version? I will add an edit request. Frietjes (talk) 21:56, 21 May 2013 (UTC)

please change

style="border-spacing: 3px; width:22em;

to

style="{{#ifeq:{{{subbox|}}}|yes
 |padding:0; border:none; border-spacing:3px; margin:-3px; width:auto; min-width:100%; font-size:100%; clear:none; float:none; background-color:transparent;
 |border-spacing: 3px; width:22em;
 }}

which seems to be the closest we can get to making this work like a navbox subgroup. note this will have zero impact on existing transclusions, but will allow |subbox=yes to be used to embed an infobox inside another infobox (or inside a sidebar). Frietjes (talk) 21:56, 21 May 2013 (UTC)

Will negative values for margin: give consistent behaviour across browsers? See CSS documentation, "Negative values for margin properties are allowed, but there may be implementation-specific limits". --Redrose64 (talk) 23:08, 21 May 2013 (UTC)

we can always update the implementation later if there is a better option. the only other option I see would be to go with the border-collapse variant, which also its issues. Frietjes (talk) 23:13, 21 May 2013 (UTC)

Code placed on Template:Infobox/sandbox. Are we good to go? — Martin (MSGJ · talk) 09:34, 22 May 2013 (UTC)

looks good to me. the worst possible outcome, as far as I can tell, of a browser not supporting negative margins would be an extra 3px padding, which is purely an aesthetic issue, and not anything that would cause serious problems. Frietjes (talk) 16:15, 22 May 2013 (UTC)

Okay, deployed. There seems to be some work on a Lua version, so perhaps that will sort out the margin problems. — Martin (MSGJ · talk) 09:14, 23 May 2013 (UTC)

fix for double bolding

I purpose making this change to the template, which will fix the double bolding problem described in Template:Infobox/doc#Embedding. the double bolding only happens in IE on Windows (see some discussion at MediaWiki talk:Common.css). in most cases, these headings are still double-bold, but most editors don't notice it, since a <th> tag plus a <b> tag looks the same as a <th> tag without the <b> tag. the worst thing that could happen by removing this extra bold tag is that some headings in child boxes become unbold. we could accompany this change with a tracking category/tracking template to find all the uses of |child=yes so they can be checked by bot. comments? Frietjes (talk) 20:27, 24 May 2013 (UTC)

I'm not exactly sure why I added those bold tags in the first place. Removing them seems reasonable. Thanks for figuring out the problem! Plastikspork _―Œ^(talk) 01:09, 25 May 2013 (UTC)

great, I will add an edit request. please update the code to this version of the sandbox. this will remove the extra bold tags from the |title= when |child=yes, and add a tracking category to find instances that are using this feature so they can be checked to make sure no necessary bolding was lost. thank you. Frietjes (talk) 14:05, 25 May 2013 (UTC)

Done! Plastikspork _―Œ^(talk) 23:39, 27 May 2013 (UTC)

Module:Infobox is now live

This template is now using Module:Infobox. It should (should) behave exactly as the old template did, but if anyone notices any bugs please post about them here. And a big thank you to Toohool who wrote the code, and WOSlinker who helped me to test it. — Mr. Stradivarius ^{♪ talk ♪} 10:12, 5 June 2013 (UTC)

• what was the issue with Template:Infobox airline? once this is stable for a few weeks, I will convert infobox school, which requires more than 99 rows. thanks for the hard work. Frietjes (talk) 17:29, 5 June 2013 (UTC)
  • When a wikitable is used against one of the data params it wasn't showing as a table because the table wasn't starting on a new line. For example:

{| class="wikitable" ! table |}

vs

table

Adding a new line into Module:Infobox fixed it. -- WOSlinker (talk) 18:15, 5 June 2013 (UTC)

good to know. I tend to use html tables in such cases to avoid this exact issue, and issues with whitespace since you can place an html table on a single line, but it's good to know that the other method will work as well. Frietjes (talk) 20:22, 5 June 2013 (UTC)

Blank line before infobox

The Lua form of the infobox is introducing at least one newline at the very start, where none previously existed - the pre-Lua form began with a parser function {{#ifeq:{{{child|}}}|yes|| which would have served to strip superfluous whitespace, had any existed (in fact it then went straight in with <table class="infobox ...>). Please see Template talk:Infobox U.S. county#Extra space. --Redrose64 (talk) 09:06, 8 June 2013 (UTC)

This isn't a Lua problem - {{Infobox U.S. county}} doesn't actually use {{Infobox}} at all. I've commented in more detail over at the thread you linked. — Mr. Stradivarius ^{♪ talk ♪} 09:33, 8 June 2013 (UTC)

Non-valid HTML code <br>

Hi, it seems to me this module generates a non valid HTML tag "<br>" (not closed), just before the image caption. One of the consequences of this is that parsoid has difficulties with it and display it. The Lua code seems to be OK to me (selfClosing = true), I don't know what is wrong wit it. But I propose to simply remove this BR tag, which is IMO useless. Regards Kelson (talk) 09:57, 8 June 2013 (UTC)

You're right, and this is a bug in Module:HtmlBuilder. It looks like support for selfClosing = true was never actually added, so the module ignores it and outputs <br></br>. I'm not too familiar with how that module works, though. I'll let Toohool know and see if they can help. I'm guessing that we do need to have the <br/> tag in Module:Infobox for backwards-compatibility reasons, so it would be best to fix the bug rather than rely on the workaround of removing it. Best — Mr. Stradivarius ^{♪ talk ♪} 10:14, 8 June 2013 (UTC)

@Kelson: The <br> tag is perfectly valid HTML, but it's not valid XHTML - XHTML requires the <br /> form, which most browsers will accept in HTML documents as an alternative form of <br>. However, when I follow the link you provide, what I see is a </br> just after the image, which is not valid in either HTML or XHTML. --Redrose64 (talk) 10:40, 8 June 2013 (UTC)

I found that the relevant parts of Module:HtmlBuilder weren't actually that hard to understand, so I went ahead and fixed it. This template should be generating <br/> now. — Mr. Stradivarius ^{♪ talk ♪} 10:47, 8 June 2013 (UTC)

Wonderful, thank you very much! Kelson (talk) 10:58, 8 June 2013 (UTC)

We don't use XHTML in any way. It's served with a text/html MIME type and a HTML5 doctype. The bug is in any code that assumes it's XHTML despite the MIME type clearly saying otherwise. Superm401 - Talk 00:09, 9 June 2013 (UTC)

Sorry, my mistake. I didn't realize it was outputting a '</br>', which is indeed completely invalid HTML5. Superm401 - Talk 00:20, 9 June 2013 (UTC)

Module:IncrementParams

Shameless plug - if you don't like manually renumbering infobox parameters, then you don't have to any more, as I have just written Module:IncrementParams. You're welcome. ;) — Mr. Stradivarius ^{♪ talk ♪} 08:33, 13 June 2013 (UTC)

I wrote a javascript script that does something related for infoboxes for the edit window, but it is confused by child boxes since it assumes a global numbering, but it certainly has saved me quite a bit of of time and mistakes. I am currently using it through greasemonkey, but could upload it here. Frietjes (talk) 17:24, 13 June 2013 (UTC)

see User:Frietjes/infoboxgap.js, adds two buttons to your toolbox in template edit mode, (1) infobox gap for inserting a gap in the numbering, and (2) infobox renumber for sequential renumbering, which removes gaps and makes it so the numbering is consistent with the order appearing in the infobox. Frietjes (talk) 18:00, 13 June 2013 (UTC)

Ooh, that looks rather nice - I might start using that. — Mr. Stradivarius ^{♪ talk ♪} 14:31, 30 June 2013 (UTC)

it works very well in most cases, but as I said, it is confused by child boxes. I actively use it so I fix bugs when I see them. I have some ideas of how to fix the child infobox issue, but I haven't been motivated to do it yet. Frietjes (talk) 18:36, 30 June 2013 (UTC)

No red link if image doesnt exist

There is no red link to the image if it doesnt exsit. It just write the name of the file, e.g.:

abcdef.jpg

Christian75 (talk) 14:05, 22 June 2013 (UTC)

this template does not convert the image name into an image, it uses the full image syntax. templates which call this template frequently use the image name syntax (e.g., see {{infobox bridge}}), but this meta-template does not. Frietjes (talk) 15:47, 22 June 2013 (UTC)

Please help with Eurozone

Hello,

Can someone please help left-justify the legend in the caption of the infobox at Eurozone? It looks a bit horrible at the minute. Thanks. 110.67.148.4 (talk) 13:04, 30 June 2013 (UTC)

I've done it with an extra <div> (diff), but I expect the "official" way to do this is with the captionstyle parameter. -- John of Reading (talk) 13:24, 30 June 2013 (UTC)

Thanks! 110.67.148.4 (talk) 13:26, 30 June 2013 (UTC)

I tried to do it with captionstyle, but it doesn't seem to work. It looks like this is because the caption style is inside <span> tags rather than <div> tags. I've changed Module:Infobox/sandbox to use <div> tags instead, and that fixes the immediate problem - see the test case that I added. I'm not sure if it will have any adverse affects on any existing infoboxes though, so it will need to be tested properly before it goes up live. — Mr. Stradivarius ^{♪ talk ♪} 14:07, 30 June 2013 (UTC)

Already, looking at the Aristotle test case I see that the change would introduce subtle differences in formatting. There is a space increase between the image and the caption, and the line-height: 1.1em; seems to now be working where it wasn't before. I think this change is probably for the best, but I would appreciate it if someone with better html knowledge than me could investigate. — Mr. Stradivarius ^{♪ talk ♪} 14:28, 30 June 2013 (UTC)