Template talk:Infobox/Archive 3

Display of "official website" links
I'd welcome any input on a discussion about whether a website entry in an infobox should display the URL itself or a link-title such as "official website". DMacks (talk) 02:49, 3 February 2009 (UTC)

Adding External links
How can we add External links like this template (Template:Infobox Television)? I'm making a infobox but i couldn't add External links like as Infobox Television?--Hedda Gabler (talk) 10:47, 3 February 2009 (UTC)

Alternate row colorig
Infobox VG colors alternate rows with a darker shade. It would be a good idea to migrate that code into this template. SharkD (talk) 05:30, 14 February 2009 (UTC)
 * I disagree, it shouldn't be forced, many infoboxes has wrapped lines, so it would make it look unsymmetrical. It might instead be Infobox VG that should convert, at least use infobox as it's base? and isn't alternate colouring already possible to use in this template? Plus it is so widely used in multiple templates which might "break" them &mdash;  CHAN  DLER #10 &mdash; 09:14, 14 February 2009 (UTC)


 * It's not meant to look "symmetrical"; it's meant to allow readers to more easily distinguish between lines. Navbox already does this to great effect. It's trivial to migrate the VG infobox to infobox, but it'd be even better if nothing would be lost in that transition. I'm going to look into implementing this in infobox3cols, my current fork of infobox. Chris Cunningham (not at work) - talk 10:50, 14 February 2009 (UTC)

References in labels
I was helping another editor fix a template using infobox that used references in the labels and have run across an interesting issue.

As a test case, I have created Template talk:Infobox/Test2, a simple infobox coded as:

{{Infobox
 * name        = Template talk:Infobox/Test1
 * title       = Template talk:Infobox/Test1


 * label1  = Label1
 * data1   = {{{data1|}}}


 * label2  = Label2
 * data2   = {{{data2|}}}


 * label3  = Label3
 * data3   = {{{data3|}}}

}
 * label4  = Label4
 * data4   = {{{data4|}}}

If we invoke this template using some of the labels, we get:

Now, you would think that because the label1 and label2 are suppressed that the associated references would be suppressed. But looking at the infobox, you will see that the reference links show [2] and [4], not [1] and [2] as expected. If we invoke the tag, all of the references show:

If a data* field contains a bulleted list, the first item is mis-formatted...the asterisk is treated as an asterisk rather than wiki-markup for a list item. Adding whitespace or newlines doesn't help. However, putting some dummy text (even if just HTML newline or space character) works. Apparently the first non-blank (in a wiki source sense) of the data* field is placed in-line with...something...so an asterisk isn't the first character in the substituted output and therefore isn't treated as a list item.



NB: I've subst:'ed the first example in the text to clarify what I see now, but left the later longer demonstration of various ideas dynamic so that fixes can be observed to work. DMacks (talk) 19:12, 14 March 2009 (UTC)


 * Even though it's a little cheat, that doesn't give the 100% correct effect if you go:
 * data1= &lt;nowiki/>
 * * bar1
 * * bar2
 * It sort of works, but for me looks like a small space is created at the top, as can be seen if you compare in my example chandler · 19:27, 14 March 2009 (UTC)

Must be something to do with parsing the wikimarkup for an unordered list; the HTML markup works: 

--—— Gadget850 (Ed)  talk  -  20:32, 14 March 2009 (UTC)


 * The code for each field is laced with several spaces that can cause the problem as seen above. A possible fix would be to remove those spaces, or start every data field on a new line, so that * will be the first character. Time for some sandbox testing. — Edokter  •  Talk  • 00:06, 15 March 2009 (UTC)
 * I seems to not be a bug attributable to this template but a more general wikitext feature: -- droll  &#91;chat&#93;  07:10, 16 March 2009 (UTC)



The slight drop is in the nature of both wiki and HTML unordered lists. Note:

foo  bar bar 

-- droll  &#91;chat&#93;  07:36, 16 March 2009 (UTC)

Why HTML instead of Wikitables?
Why does this template use HTML markup (      , etc.) for each row instead of Wikitable syntax? Both systems render the same thing, and Wikitables are much easier to understand for the average user. Also, if some text is added to one of the data rows that includes wikitable syntax (not HTML as in this code), it doesn't render correctly. I think this template should be converted to use all wikisyntax.. that is, in fact, what the syntax was created for, isn't it? --Dudemanfellabra (talk) 21:43, 23 March 2009 (UTC)
 * It uses HTML to avoid limitations that is inherit in wikitables. Most notably, it conflicts with pipes (|) used in parser functions. — Edokter  •  Talk  • 00:06, 24 March 2009 (UTC)
 * Is that not what the ! template is for? Look at the coding of Infobox nrhp; there is no HTML in there whatsoever (other than styling and stuff like that... which is actually CSS).. all wikisyntax. The code is segmented and easy to understand in my opinion.. at least more so than this template's coding. --Dudemanfellabra (talk) 00:19, 24 March 2009 (UTC)
 * Even then, coding a template that way is more complicated then using HTML, and ! is not without limitations, especially with nested tables or parser functions. Plus templates that are used on a lot of pages should not depend on other (small) templates if it can be avoided. — Edokter  •  Talk  • 14:31, 24 March 2009 (UTC)

In my opinion there is no inherent advantage to using wiki markup over HTML. The only people who have to understand the HTML are the people who maintain the template. There should be no reason a casual editor should need to examine the code other than curiosity. It should be for the most part a black box. The documentation should disclose everything a user needs to know.

If the question is about wiki markup not render correctly, I think more research needs to be done. Show me an example on my chat page and we can test it. I think you would have the same results if this template where coded in wiki markup but I'm will to prove it. If you would like I would be glad to work with you. This question has come up before and should be put to rest once and for all. I'm really interested in identifing a problem if one exists. -- droll  &#91;chat&#93;  23:47, 27 March 2009 (UTC)

Houston, we have a problem?
it seems to me that this template is really mucked up with respect to the way rows are coded. the basic row block is this:

what this seems to say is that label1 and data1 will only be displayed when header1 is not defined, which is patently weird. the problem is that spurious pipe character at the end of the first line (after the   ).

this would actually be a huge problem to fix - this template is massively transcluded. I might be able to work up a repair job that won't break all of the current versions (which have all doen funky things with the parameters to compensate for the problem). should I try? -- Ludwigs 2 05:37, 27 March 2009 (UTC)

EDIT: actually, it's probably not as bad as I thought. this change should fix the template without affecting any of the current pages:

basically this separates the header line from the data line by closing the first IF block after the header row. all of the current templates that are structured 'header1 - data2 - header3 - data4 - ...' should still look the same, but a more normal 'header1 - data1 - header2 - data2 - ...' structure could be used as well. if other people concur, I'll run the template through some regex and change all the instances that need to be changed. while I'm at it, I could also convert it to wikitable format; what do you think? -- Ludwigs 2 05:50, 27 March 2009 (UTC)
 * It's not meant to be used with header1 and data1, its made so you set 1 thing for each row. chandler · 08:27, 27 March 2009 (UTC)
 * so what you're telling me is that it was designed not to make sense?   ok, well, maybe that's not fair.  it doesn't sense from a programming perspective, though it might make more sense from a non-technical perspective.  at any rate, it bugs me, so I'm going to work up a revision in user space so we can discuss the pros and cons of it.  -- Ludwigs 2  14:30, 27 March 2009 (UTC)

collapsible infoboxes?
following a request at Wikipedia_talk:WikiProject_Infoboxes, I started wondering whether it would be worth the effort to make the data section of infoboxes optionally collapsible. basically this would involve adding a conditional subtable using something like the following before the header 1 row:



and closing it at the end of the data section with:


 * }}

of course, it would need some CSS work as well to keep the look consistent. comments? -- Ludwigs 2 16:45, 30 April 2009 (UTC)


 * How would that print? ---— Gadget850 (Ed)  talk 17:46, 30 April 2009 (UTC)


 * having never printed a wikipedia page, I have no idea.   I tested it by printing to a pdf, and it seems that tables are printed in their current state (collapsed or uncollapsed) rather than always expanded or always collapsed.  there may be a special printing class to specify that collapsed tables be printed in their uncollapsed state, but if so it's not documented anywhere obvious; I'd have to dig through the CSS files to figure it out.  -- Ludwigs 2  18:02, 30 April 2009 (UTC)


 * That is what I meant- collapsed tables do not expand when printing, so how would you print the information. I am not aware of any way to expand when printing. If we can determine the CSS, we can request a new class. ---— Gadget850 (Ed)  talk 18:16, 30 April 2009 (UTC)


 * well, you'd have to expand it first. if the table is expanded, it prints expanded; if the table is collapsed, it prints collapsed. -- Ludwigs 2  21:45, 30 April 2009 (UTC)


 * MOS:SCROLL has an exemption for infobox templates, as they shouldn't contain any unique information which isn't available in the article body. For what it's worth though, it should be trivial to make .collapsed only apply to @screen media, no? Chris Cunningham (not at work) - talk 09:45, 1 May 2009 (UTC)


 * well, it might be a little more complicated than that. collapsible tables work by setting the 'display' style element of individual rows to 'none' using javascript.  so you'd probably need something like:
 * to always display collapsible tables during printing (use none to never display them), but I'd want to test it a bit. the javascript for expanding a collapsed table actually uses the display mode of the header row rather than the generic 'table-row' I used above, and I don't know if that difference makes an actual difference, if you know what I mean.  but it ought to be doable.  -- Ludwigs 2  15:34, 1 May 2009 (UTC)
 * New rules at common.css now expand collapsed boxes when printing. ---— Gadget850 (Ed)  talk 18:53, 13 May 2009 (UTC)
 * New rules at common.css now expand collapsed boxes when printing. ---— Gadget850 (Ed)  talk 18:53, 13 May 2009 (UTC)

Belowclass
Propose adding  for the bottom cell by changing:

to

The specific purpose would be to set  for infoboxes that use a portal link in the below cell. As Wikipedia navigational elements, such links should be non-printable. Currently, the contents of the below cell must be wrapped in a. --—— Gadget850 (Ed)  talk  -  22:30, 31 March 2009 (UTC)


 * Yup. For reference, this came up at Template talk:Infobox Court Case. Chris Cunningham (not at work) - talk 12:10, 1 April 2009 (UTC)


 * I have added this to the sandbox version and the testcases. Let me know of any issues. ---— Gadget850 (Ed)  talk 15:44, 9 June 2009 (UTC)
 * No objection from me. &mdash; Martin (MSGJ · talk) 16:39, 9 June 2009 (UTC)


 * This is documented, but not implemented. Was there a problem? ---— Gadget850 (Ed)  talk 02:19, 6 September 2009 (UTC)