Jump to content

Wikipedia talk:Manual of Style/Infoboxes: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Revised proposal against hiding of infoboxes: blankets, wet, security, whichever
Mikekearn (talk | contribs)
Infobox citations: new section
Line 374: Line 374:
I am archiving this discussion pending the development of a viable solution. Development of an experimental infobox at [[Ponte Vecchio]] is an example of an attempt at innovation which may improve [[Wikipedia:About|the project]]. [[User:Sswonk|Sswonk]] ([[User talk:Sswonk|talk]]) 18:01, 30 August 2008 (UTC)
I am archiving this discussion pending the development of a viable solution. Development of an experimental infobox at [[Ponte Vecchio]] is an example of an attempt at innovation which may improve [[Wikipedia:About|the project]]. [[User:Sswonk|Sswonk]] ([[User talk:Sswonk|talk]]) 18:01, 30 August 2008 (UTC)
{{archivebottom}}
{{archivebottom}}

== Infobox citations ==

I have looked through what I was pretty certain were the relevant guideline pages, and have been unable to find an answer to my question. Are citations needed in an infobox? I ask specifically to the infobox in [[The Dishwasher: Dead Samurai]], as I added the fact that there was Multiplayer in addition to the Singleplayer. It is stated in Silva's blog that the game has this, so I thought the information should be added, but didn't know if it needed to be cited or not.

I eventually decided to just rewrite and add the information to the article itself, source it there, and then it won't matter much, but I would still like to know for future reference if citations are needed for infoboxes if the information isn't specifically in the article. --[[User:Mikekearn|Mike]] | [[Special:Contributions/Mikekearn|Contrib]] 07:48, 3 September 2008 (UTC)

Revision as of 07:48, 3 September 2008

General comments about WP:DIT

Much better. It's less opinionated, better written, deals more with the appropriate use of optional fields, and it comes off less authoritative then WP:ACT. However, I do think a warning should be added cautioning template editors not to get carried away with optional fields — as Netoholic has complained in the previously mentioned proposal. After all, it is not appropriate to make every field optional.--TheFarix 02:45, 10 March 2006 (UTC)[reply]

That's probably true—although I've seen cases where only a few fields are required and the rest are optional (this is more an issue with infoboxes intended for historical topics, where the lost information problem really comes into play). Maybe some more general advice about how to select which fields should be optional and so forth would be even better. —Kirill Lokshin 03:09, 10 March 2006 (UTC)[reply]
Agreed, this is much much better. Regarding whether or not to make each field optional, the only reason I think it's a good idea is because editors may not have all the information available (but they may have some information). If they can't fill it all in, they should be able to fill in as much as they can, and leave the rest to future editors (in this way, individual editors will fill in each missing piece as they come across the article). The alternatives are to not have a box even partially filled in (meaning we may lose out on that editors knowledge/piece of the puzzle), or worse, have editors who copy and paste the Wiki-markup directly into the article, omitting the data they're not aware of. Anyways, looks good so far, I'll keep this watchlisted. =) —Locke Coletc 19:19, 10 March 2006 (UTC)[reply]
I think that the work at {{Infobox University}} is an excellent example of where multiple forked templates were brought together into a single cohesive infobox and shows use of optional parameters. How they are made optional is another issue, but it was a good bit of work. Does anyone know of widely used infoboxes that do not use optional parameters? --Reflex Reaction (talk)• 19:48, 10 March 2006 (UTC)[reply]

mdashes

Is there any particular reason why the mdashes in the General advice section, or anywhere else in the proposal, shouldn't be unicoded? --TheFarix (Talk) 03:45, 11 March 2006 (UTC)[reply]

Feel free to convert them; I just use the HTML entities because it's faster for me to type them than to go hunting through the symbol box for the right one ;-) —Kirill Lokshin 03:46, 11 March 2006 (UTC)[reply]
Alt-0151 will give you the mdash and Alt-0150 will give you the ndash on a US keyboard. I hope that is of any help to you. ;) --TheFarix (Talk) 04:11, 11 March 2006 (UTC)[reply]

Ultimate status

Am I right in thinking the goal for this should be a style guideline? —Locke Coletc 04:38, 11 March 2006 (UTC)[reply]

I was thinking a regular guideline, actually, since we're only making broad comments about style rather than giving lots of specific rules. I could be wrong about this, though. —Kirill Lokshin 04:43, 11 March 2006 (UTC)[reply]
It would be hard not to talk a little about style when providing guidelines about when a field could be made optional. However, I believe the goal of this guideline to get encourage template editors to think more about the contents of a dynamic infobox while at the same time avoiding the "Editors are using this badly, so stop using it!" logic of both WP:AUM and WP:ACT. --TheFarix (Talk) 12:42, 11 March 2006 (UTC)[reply]
This article is not linked from anywhere substantive. It's orphaned. It really needs to be linked from somewhere, preferably the MOS. But if its in the MOS then it probably needs to be renamed, probably to something like Wikipedia:Manual of Style (infoboxes).
BTW, OT, what is WP:ACT meant to point to? Frelke 07:49, 11 April 2007 (UTC)[reply]

Creation or usage?

It seems that most of the guidance here focuses on infobox creation, rather than usage. For example, many (but not all) pages that have a single most-appropriate infobox place the infobox in the introductory section. This seems most logical, but the only recommendation I've found on the topic is in Wikipedia:Chemical infobox (which does instruct editors to put the infobox in the introduction). Would there be any opposition to recommending infobox placement in the introductory section as a usage guideline on this page? Tlesher 01:16, 1 June 2007 (UTC)[reply]

There already is! See discussion at the main MOS page and also at WT:LEAD
mikaultalk 13:38, 3 June 2007 (UTC)[reply]

Lacking vital information?

Hi contributors. Is there any reason that this page contains no advice about where infoboxes should be located, when they should and shouldn't be used, and guidelines for the use of images within infoboxes? Tony (talk) 13:36, 27 September 2007 (UTC)[reply]

Mainly because, despite the later renaming, it was never intended to be a proper MoS for infoboxes in general, but was rather a page regarding a very specific issue in terms of how the templates themselves were designed. Kirill 17:33, 27 September 2007 (UTC)[reply]
There have been discussions on this. Even though there has been a tendency for editors to put infoboxes in the lead section, this has not been part of any guideline. Indeed where advise has been given as a result of discussion and consensus (such as Wikipedia:Infobox_templates#Design_and_usage, it has been that infoboxes be placed in the main body or most appropriate section. Various reasons have been given for this - the two main ones have been aesthetics (too much overload of information in an infobox), and that when a content box is turned off an infobox can displace the section(s) below if it is placed in the lead. I'll adjust the sentence in the lead section to be less contentious, and to avoid a potential clash with other advise. SilkTork *SilkyTalk 16:02, 11 October 2007 (UTC)[reply]

This page Wikipedia:Manual of Style (infoboxes) deals with how to use infoboxes, and so does Wikipedia:Infobox templates. Would it be appropriate to look closely at them and merge the information? SilkTork *SilkyTalk 13:42, 15 October 2007 (UTC)[reply]

I think it should be the other was around. -- (Cocoaguy ここがいい contribstalk) 20:07, 26 October 2007 (UTC)[reply]


Merged talkpage from Wikipedia:Infobox templates

SilkTork *SilkyTalk 11:03, 29 October 2007 (UTC)[reply]

Recommendations

The width of an infobox should be specified in em's not px, as this is relative to font-size. ed g2stalk 11:09, 20 May 2005 (UTC)[reply]

That's a bad idea. We're talking about a box itself, not text. px are needed for absolute positioning. -- Netoholic @ 16:19, 2005 May 20 (UTC)
Could you give an example where absolute positioning is needed or used? Em measurements may improve readability in some cases. In others they can make it worse or destroy a layout. I'm not sure what would happed here. Wipe 22:34, 20 May 2005 (UTC)[reply]
What are you on about? I've specified loads of boxes in em's. What exactly needs to be positioned absolutely? The infobox itself is floated right. ed g2stalk 00:26, 21 May 2005 (UTC)[reply]
Yes, well, thanks for not bothering to wait for a reply or more comments before you went and implemented your suggestion on all the infoboxes. Why did you even bother posting on this talk page if you were set on doing this anyway.
Anyway, px is the only reliable absolute unit on screen. Using em, sometimes browsers use the wrong reference size. Using em might also break things if multiple infoboxes are meant to line up (see the section on secondary infoboxes on the main page). The best practice is to use px for "structural" elements like the outer box size, borders, etc. Leave em for strictly text styling. Appropriate use of both is what we need. Remember also that many infoboxs use images, which are going to be specified in px. -- Netoholic @ 03:11, 2005 May 21 (UTC)
I've always implemented em's, way before suggesting it as a recommendation here. In the cases px's are absolutely necessary (show me an example) they can be used. But most of the simple infoboxes work fine with em's. If defined as the main table width, the em will always be relative to the normal font size, nested width's can then be defined as percentages. Using px's makes the boxes very ugly for anyone who doesn't use the default browser font size. ed g2stalk 10:14, 21 May 2005 (UTC)[reply]

The backlinks now show all the pages with the infobox.

However, the maximum number shown is 999; therefore, for infoboxes used on more than 999 pages an automatically generated list that is complete is not available, unless there is a category. Alternatively there might be a non-automatic list.

Infoboxes used on more than 999 pages include:

As a workaround, the set of pages with an infobox can be divided in subsets of not more than 999, each calling a redirect to the infobox; the backlinks of the redirects are together the pages that use the infobox; one has to record the names of the redirects, because they are also part of the large set of backlinks of the infobox, of which only 500 are shown.

Redirects allowing 999 backlinks each:

Alternatively, CVG could redirect to CVG1, and the content put there, then on 999 pages less the template tag would have to be changed (from CVG to CVG2, etc.).

The same can be done for infoboxes when the number of pages reaches 999, then the backlinks are and stay complete without cumbersome changes in tags.

For example, for Template:Infobox City (talk links edit), when there are almost 999 cities, the template can be renamed, so that the existing tags refer to a redirect. A second redirect to the new name can be used for new occurrences of the infobox.

Patrick 08:51, 27 May 2005 (UTC)[reply]

I changed 500 to 999, and Template:Tic, after reading the message below.--Patrick 10:39, 19 Jun 2005 (UTC)

That's a really ugly hack for a very minor problem with the MediaWiki software. The backlinks page does accept &limit=999 in the URL if you want to see more that 500 backlinks, and probably &offset=999. ed g2stalk 15:25, 18 Jun 2005 (UTC)
Interesting that 999 are possible. However, offset does not seem to work. I think it is a basic limitation if you cannot get a list of all pages that use a template.--Patrick 10:56, 19 Jun 2005 (UTC)

Standardization

There is a new proposal concerning infoboxes: Wikipedia:No infobox standardization. You are invited to comment.--Fenice 18:50, 15 August 2005 (UTC)[reply]

The Human Development Index (HDI) is a standard UN measure/rank of how developed a country is or is not. It is a composite index based on GDP per capita (PPP), literacy, life expectancy, and school enrollment. However, as it is a composite index/rank, some may challenge its usefulness or applicability as information.

Thus, the following question is put to a vote:

Should any, some, or all of the following be included in the Wikipedia Infobox#Countries|country infobox/template:

(1) Human Development Index (HDI) for applicable countries, with year;
(2) Rank of country’s HDI;
(3) Category of country’s HDI (high, medium, or low)?

YES / NO / UNDECIDED/ABSTAIN - vote here

Thanks!

E Pluribus Anthony 01:52, 20 September 2005 (UTC)[reply]

Infobox with Template:Infobox Country within another template

Should we use Template:Infobox Country on Austria or on Template:Infobox Austria. See Wikipedia:Templates_for_deletion#Country_Specific_Infoxboxes_that_only_redirect_to_Template:Infobox_Country. -- User:Docu

Template "lists of films"

Hi! I couldn't find this template here. I would like to know if anyone knows how to add one more genre in this template. It's missing drama films...

fizzerbear 23:57, 2 February 2006 (UTC)[reply]

Stacking and aligning multiple template boxes

Editors of Saint Louis, Missouri would like to use Template:Quotebox to place directly under Template:Infobox City, and I've tried several ways to accomplish this, to no avail. How is it done (if it is possible)? Alternatively, it could be placed inside city infobox, but I'm not sure that is possible or desirable, or how to do it, if it is. Evolauxia 09:30, 26 February 2006 (UTC)[reply]

you want to add "clear:right;" in the styling of the box. I did it. It will automatically be pushed under any preceding floated box(es). Circeus 15:45, 26 February 2006 (UTC)[reply]
there's a problem with that solution... if the second box's containing section is short enough, the second box will overlay the "Edit" link of next section --Millbrooky 07:37, 17 March 2006 (UTC)[reply]

Infobox Instructions

Is there a standard form of usage instructions for infoboxes? Also, is there a stardard that says the instructions should be placed on the talk page. The reason I'm asking is because I think that the best place to put instructions would be on the infobox's main page (inside a pair of noinclude tags, of course). This way when a user goes to the infobox page they don't just see a mess of code or a box with a bunch of inclusion tags in it. A novice may not even realize the instuctions are on the talk page until they go there to ask how to use it. - Trevor MacInnis (Talk | Contribs) 23:28, 7 March 2006 (UTC)[reply]

Proposal for common look and feel for geographical infoboxes

I've created page for discussion about creating a standard look and feel for geographical infoboxes, please contribute at Wikipedia:Geographical infoboxes if you're interested. -- Rick Block (talk) 17:40, 24 June 2006 (UTC)[reply]

Notice of Move discussion

There is a discussion going on at Template talk:Infobox President about moving Template:Infobox President to Template:Infobox Officeholder. Hera1187 09:09, 26 July 2006 (UTC)[reply]

Edit infobox as section

As everyone knows, each section in a wikipedia article has an Edit link which gives a user the opportunity to edit only that section. Is there a way to include an edit link in an infobox which would give the user the opportunity to edit the template call as a section? (I.e., not a link to edit the template itself, but to the infobox within the current article.) I hope this is clear. The Infobox I'm talking about is Template:Infobox baseball team. Thanks in advance. Rolando (talk) 15:19, 14 September 2006 (UTC)[reply]

The infobox content is usually at the very beginning of the article, i.e. section 0, so I think the following does what you're looking for:
<span class="plainlinks">[{{fullurl:{{PAGENAMEE}}|action=edit&section=0}} edit]</span>
This produces an edit link for all of section 0 (i.e. everything before the first heading), not just the template invocation. -- Rick Block (talk) 17:47, 18 February 2007 (UTC)[reply]

unwanted interaction between infoboxes.

Hello - I was wondering if I could get some technical help regarding the interactions of two info boxes. I have been developing the template:mycomorphbox infobox as a way to quickly display identifying characteristics of mushrooms on mushroom pages. These pages tend to also have template:taxobox infoboxes. When the two appear together, the "edit" links in each sub-section of the articles get pushed down to the top of the lower infobox, generally the mycomorphbox. I would like to resolve this. Oyster mushroom is an example.

I believe it has something to do with the "edit" links being positioned using "float:right" as when I make test text with <div style="float:right"> I get the same positioning effect.

Thanks for any tips ! Debivort 08:35, 18 November 2006 (UTC)[reply]

Please see Wikipedia:How to fix bunched-up edit links. -- Rick Block (talk) 17:56, 18 February 2007 (UTC)[reply]

Common Problem

The infobox is very good template to use in any wikki for right side navigation , or content related navigation , but there is a common problem in implentation of infobox template that many time the box doesent appear. I am implementing a wiki [1] here We are implementing the infobox template IPR look through it at [2] the same like a template Intellectual_Property in wiki but no box is appearing. What to do is any one can suggest any solution . —The preceding unsigned comment was added by Siddhast (talkcontribs).

You're missing the styles that are defined here in MediaWiki:Common.css. If you can't figure out how to fix this on your own, I suggest you ask at the mediawiki-l mailing list. -- Rick Block (talk) 18:03, 18 February 2007 (UTC)[reply]

Film Director Infobox

Isn't it time we had a specific film director box? Editors have often used the Actor format (Scorsese, Hitchcock are examples) but it isn't ideal. El Ingles 22:02, 23 March 2007 (UTC)[reply]

I am truly amazed that there isn't one. Nemobius 05:35, 2 April 2007 (UTC)[reply]
I am all for having one.--Adoniscik (talk) 17:12, 10 January 2008 (UTC)[reply]

Placement of InfoBoxes

There is a conflict of guidelines. The InfoBox guideline says to insert the InfoBox in the top right of an article, yet the MoS guideline says that an image should be placed in the top right of an article unless there is a compelling reason not to. There is a discussion about this on the MoS [3]. The MoS guidelines predate the InfoBox guidelines and are overarching. The specific guideline to use a picture or image in the top right predates the InfoBox guidelines. Therefore the InfoBox guideline is inappropriate and in conflict with an existing consensual guideline. I have made the adjustment. Any queries please raise them on the MoS talkpage. SilkTork 17:50, 1 June 2007 (UTC)[reply]

This is being debated at [[4]]; but, for what it's worth, I don't think your changes are justified. Guidelines which fail to reflect common practice will be ignored; if you want to change it, you need to persuade editors to change their practices, not just alter a document which doesn't even have guideline status. TSP 00:05, 2 June 2007 (UTC)[reply]
NOTE: Regarding the guideline conflict noted above, the Infobox guideline has been merged into this article, so the discrepancy no longer exists. And FYI, the previous discussion noted above has been archived here. — TAnthonyTalk 20:48, 22 February 2008 (UTC)[reply]

Is this really the guideline?

So I attempted to "correct" an editor who was adding infoboxes after the lead paragraph in multiple biography articles, and was surprised to discover that this is actually per the MOS guideline in this article (Insert in the main body of articles - either after the intro or in the most appropriate section. Consider putting in the top right only in the most compelling of cases.) As I feel like I've never really seen an article whose infobox isn't right up top, I started choosing featured articles at random, and every one with an infobox that I viewed in fact "violates" these guidelines as far as placement goes. Is this guideline outdated, or just under-advertised and not considered important for article assessment? It seems like a relatively minor aesthetic issue, but if it is so rampantly ignored and unpoliced, I'm wondering who determined this guideline in the first place and why. — TAnthonyTalk 20:48, 22 February 2008 (UTC)[reply]

I know this is belated, but I agree with you. Almost every article out there with an infobox has the infobox at the very top, and (in my opinion) this is the way it should be stated in the MOS. Would anyone reject a change in the MOS to state this? All Hallow's Wraith (talk) 07:03, 22 April 2008 (UTC)[reply]
I would like to hear more of the reasons for placing the infobox in a particular location, whether always at the top or not. At the top is simple to state, simple to implement, yet there are articles where the main text seems to flow better around the infobox and the TOC depending on how they are placed. I prefer to see text wrapping around the boxes rather than a lot of whitespace, and many shorter articles have short introductions which look better above the infobox in my opinion. Is there any previous discussion of this that can be referenced? I like the idea of having some latitude to arrange the top of the article in a compact and effective manner.Leofric1 (talk) 17:24, 22 April 2008 (UTC)[reply]
I think the problem of latitude can create endless discussions and arguments in individual articles about where the infobox should be placed. I also think it's absurd that this MOS somehow ended up stating something that contradicts the location where the vast majority of articles have their infobox (the top), including most if not all featured articles. As for having the infobox anywhere other than the top, most versions of this I've seen look (frankly, to me) terrible, especially the the mix of infobox, TOC, and introduction I've seen in something like this. I also think that having the infobox anywhere other than the top, aside from causing a physical strain to the article, contradicts the basic purpose of an infobox, which is to give you the basic information about the person (or topic), including a picture, things that one would want to see at the beginning of an article (this is especially true about the picture of the subject) All Hallow's Wraith (talk) 17:58, 22 April 2008 (UTC)[reply]
Looking at the history of this:
On the page Wikipedia:Infobox templates, the description stated "Insert at the top of articles and right-align" up until June 1, when User:SilkTork changed it to "Insert in the main body of articles - either after the intro or in the most appropriate section". There was no discussion or consensus to do this on the talk page (indeed, User:TSP stated that he did not think these changes were justified).
On the page Wikipedia:Manual of Style (infoboxes), the header of the article stated "Infobox templates are a broad class of templates commonly used at the top of an article". Once again, User:SilkTork changed it to simply "in articles" [5] on October 11, and later that month merged Wikipedia:Infobox templates into this. Again, there was no discussion or consensus on this page for the change. Therefore it's clear to me that these changes were done without consensus supporting them. All Hallow's Wraith (talk) 18:10, 22 April 2008 (UTC)[reply]

Bug on a template

I don't know where else to report this, but there is a bug on a template, {{Infobox religious building}} that needs fixing. Basically it is adding a - to the upper left of the pages it is on, see the template's talkpage for other descriptions of this bug and any of the pages the template is used on to see the bug. Thanks in advance, D. Recorder 05:00, 5 June 2007 (UTC)[reply]

Fixed. –Pomte 05:25, 5 June 2007 (UTC)[reply]
Many thanks, D. Recorder 05:30, 5 June 2007 (UTC)[reply]

Request for assistance on Template:Infobox book

Is there a clean/simple way to make the ISBN field on infobox book work? There was some discussion about it a couple of months ago on the talk page there, but no clean way presented itself right off, short of saying ISBN again - ie, ISBN ISBN XXXXXXXXX. Thoughts? MrZaiustalk 10:47, 28 September 2007 (UTC)[reply]

References in infoboxes?

I wanted to seek clarification if it is an acceptable practice to include references in infoboxes? See the infoboxes at Ashlee Simpson and Benazir Bhutto for a couple of examples. My view is that including references causes unnecessary clutter and which can be better addressed in articlespace rather than in the infobox. Am I correct? Ekantik talk 20:41, 5 January 2008 (UTC)[reply]

Repetition of information

Since Infoboxes are often made by condensing information spelled out in the article, I was wondering what the policy or consensus on dealing with the repetition it creates is. For example, what to do with External Links sections that merely link to the subject's official Web site when the Infobox already contains a link. If we are tallying, my opinion is that we should allow repetition if the article is short, and not otherwise.--Adoniscik (talk) 17:18, 10 January 2008 (UTC)[reply]

Gaps in list on main page

The list of templates on the MOS (infoboxes) page seems very incomplete. Infobxes I've come across recently which don't seem to be in it include: {{Infobox religious building}}, {{Parish church}} (and {{Infobox church2}} which had various deprecated predecessors like {{Infobox Church}}), {{Infobox Theatre}}, and {{Infobox Hiking trail}}. Would someone like to add them? Or is the list not supposed to be comprehensive? Thanks. PamD (talk) 15:26, 19 January 2008 (UTC)[reply]

I agree, after a fruitless search I came on here to mention {{Infobox Person}} is missing. People may quite rightly assume that a template missing from the list has been made inactive and not to be used - I almost did. -- John (Daytona2 · Talk · Contribs) 09:59, 24 February 2008 (UTC)[reply]

Infobox Samba School

Can somebody create a template infobox#samba school? --Nadir D Steinmetz 13:32, 23 January 2008 (UTC)[reply]

Infobox Actor

A discussion is taking place at Template talk:Infobox actor#Nationality about adding a Nationality parameter to the infobox. Your input would be greatly appreciated. --pete 20:53, 7 February 2008 (UTC)[reply]

This template has little leway in adding parameters, is there a way to change that or should I switch to a more basic template like Infobox person? Benjiboi 20:33, 12 March 2008 (UTC)[reply]

Default infobox styling

A while back I reforged {{infobox}} as a general-purpose infobox metatemplate, and now that it's starting to see more widespread usage there's a discussion underway about what default styling should be used. I set the original defaults based directly off of the default styles used in {{Navbox}}, since I presume they've undergone a very extensive debate and because I personally find them quite useful. However, there are a couple of editors who've requested that the default infobox to be colorless. I'm canvassing here for more input into the discussion over at Template talk:Infobox. Bryan Derksen (talk) 16:49, 1 April 2008 (UTC)[reply]

Lists of infoboxes

Suggestion to Merge the 3 manually-created lists of infoboxes, at Wikipedia talk:WikiProject Infoboxes#Lists of infoboxes. Either to one of the 3 locations, or just deprecate them all in favor of the category. Input there appreciated. -- Quiddity (talk) 21:37, 9 April 2008 (UTC)[reply]

Done. -- Quiddity (talk) 21:47, 30 June 2008 (UTC)[reply]

Wales

Hello page,

Just wondered if watchers here could pass comment at the proposals for a coloured infobox at Talk:Wales --Jza84 |  Talk  12:45, 10 April 2008 (UTC)[reply]

Template:Infobox Country styled has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. — --Jza84 |  Talk  11:59, 14 April 2008 (UTC)[reply]

Okay, Here's a Noodle-Baker

The argument is as follows: do observational details outweigh citation? The argument posed by the anonymous editor is that the nom de guerre 'Scarlet Pimpernel' desperately needs to be in the infobox all by itself, since he saw it in the credits of the film, Fitna. Currently, the article the credit as 'Scarlet Productions.' The anon seeks to have the word 'Production' removed fromt he infobox.
He rejects any compromise ("Scarlet Pimpernel" Productions being the most reasonable) that notes the existence of the citation that identifies the alias as a production company. For lack of ambiguity's sake, it seem important - not to mention encyclopedic - to note that 'Scarlet Pimpernel' in the infobox is not an individual, or a real name - we have reliable citation that specifically identifies that it is not, but rather a pseudonym to protect the actual production company, which goes by another name. Thoughts? - Arcayne (cast a spell) 00:23, 16 April 2008 (UTC)[reply]
This question is probably better addressed by the WP:V people. The infobox aspect is this: it should match whatever the article says.
To be slightly more helpful: Can the anon provide you with a screen shot, or are we trusting some distant recollection? WP:V is not an optional policy. WhatamIdoing (talk) 01:25, 16 April 2008 (UTC)[reply]
Well, I've actually seen the movie as well (its free to view online, or was), and it does not SP without the production company clarifier. I don't mind taking the discussion to V; I brought it here with the understanding that it had more to do with some infobox guidelines that I wasn't immediately aware of. - Arcayne (cast a spell) 03:26, 16 April 2008 (UTC)[reply]
Just for the record... This has been discussed ad nausium at WP:RSN (see: Wikipedia:Reliable_sources/Noticeboard#Movie Credits in the InfoBox). There is a degree of forum shopping going on here, so please familiarize yourselves with that debate before you give a definitive answer to this question. I also have to note that both Arcayne and other editors have been engaging in edit wars over this for quite a while at the article. Finally, if the clear consensus at RSN is contrary to consensus here at MOS, please let us know (it is important that those who answer policy and guideline questions in different forums are in sync and not contradicting each other). Thanks Blueboar (talk) 15:27, 16 April 2008 (UTC)[reply]
With respect to Blueboar, my question was posed here to discover if there were special criteria for what could be listed in an infobox and what could not, not as forum-shopping. As the Lead is an overview/summary of the article, it was my understanding that the infobox represented an even briefer summarization of the article. As the article text references Scarlet Pimpernel as a pseudonym, I wanted to know if my assumption about infoboxes was in fact accurate. Even though the matter has since been resolved, I would still like confirmation of my correct interpretation or an explanation as to how it is incorrect. - Arcayne (cast a spell) 21:20, 16 April 2008 (UTC)[reply]
Arcayne, there has been a tendency on style guidelines talk pages, especially recently, to try to get people to discuss stuff that arguably fits in other categories (such as NPOV) somewhere else first, because those are the kinds of arguments that wind up going on forever if we try to sort them out on a style guidelines page ... it gets all confused. It also makes a huge amount of work for those of us trying to come up with monthly summaries for the benefit of article reviewers. I don't know if this is one of those cases, but I've noticed that Blueboar is rarely wrong about anything :) Please consider what he's saying. - Dan Dank55 (talk)(mistakes) 19:16, 22 April 2008 (UTC)[reply]

Image size

Is the 300px size for infobox images a suggestion or a standard? I've had a problem with another editor repeatedly resizing an infobox image. When I replaced the image with one that is not a close up, the image size was cut down again to 150px. Finally, I cited and linked the manual of style and was told that it's only a "suggestion". The article involved is Chocolate chip cookie and I'd like to find out if I'm mistaken about my understanding of infobox image sizes. Thanks Shinerunner (talk) 14:54, 26 July 2008 (UTC)[reply]

Default thumbnail size (180px) is a good minimum. Anything different is debatable. Wikipedia:Image_use_policy#Displayed_image_size and Wikipedia:Manual_of_Style#Images and Wikipedia:Accessibility#Images are the relevant policies/guidelines. Making it smaller than the infobox's width, is the only certain restriction. -- Quiddity (talk) 20:26, 26 August 2008 (UTC)[reply]
Thanks for the reponse and the cited information. I really didn't want an edit war over a big cookie! Shinerunner (talk) 23:07, 26 August 2008 (UTC)[reply]

Can someone Please Make me an infobox???

I will give you the details if you are up for it. just leave message me or whatever thanks RorikRäikkönen (talk) 06:15, 31 July 2008 (UTC)[reply]

Infobox discussion at WP:EAR

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Move to Village Pump

Please continue this discussion here at the Village Pump. All text below has been copied there. Sswonk (talk) 19:16, 23 August 2008 (UTC)[reply]

Original Posts

EXAMPLES of what is being discussed: Ponte Vecchio and Cellini Salt Cellar - Hidden infoboxes.

Watchers of this page might be interested in this discussion. --AndrewHowse (talk) 14:42, 21 August 2008 (UTC)[reply]

Yes, indeed. And rather than pipe the link secretively, let me add that it's a discussion of a resolution of the infobox issues, one that is meant to offer an elegant display, which will not compete with and crowd encyclopedia text. An example may currently be seen at Ponte Vecchio, formerly an infobox sorepoint: see Talk:Ponte Vecchio.--Wetman (talk) 14:57, 21 August 2008 (UTC)[reply]

We seem to have been pointed here for discussion of this issue. - Denimadept (talk) 20:26, 21 August 2008 (UTC)[reply]

Wetman has come up with a brilliant solution to the dreaded infobox, unfortunately, Ponte Vecchio has been reverted back and you can no longer see his idea and the beautiful image of the medieval bridge is again over shadowed by the box. - Epousesquecido (talk) 21:29, 21 August 2008 (UTC)[reply]
If they really want to see his ugly condensed version of the infobox on that bridge, they can check the article history. I didn't mind him hiding it so much as I did his (or someone's) reducing the content and the format. - Denimadept (talk) 21:31, 21 August 2008 (UTC)[reply]
Denim, would you like to pick a forum and stick to it? I'm happy to discuss all this at length wherever you like, but may we simply refer people to one venue rather than fragment it? Cheers --Joopercoopers (talk) 22:03, 21 August 2008 (UTC)[reply]
We've been told to take it either here or some other place I forget. This seems most sensible to me, and we've already been here, so unless Wetman wants to post his proposal the other place, this seems to be what we've been requested to do. Personally, I'd just as soon drop the issue and leave things alone, but Certain People won't allow that. - Denimadept (talk) 23:59, 21 August 2008 (UTC)[reply]

For the sake of completeness I will simply repost, more or less, what I said at Editor Assistance:

I think a visible infobox, the contents of which reflects a general sense of restraint, is preferable to a hidden one. Two reasons. First, the casual user will never see the "show" button unless it is conspicuously highlighted. I'm *not* a casual user and I missed the button on both the example pages above. An hide / view preference toggle (or a neon 'show' button) would largely fix that problem, but it wouldn't solve the second, which is that once infoboxes can be hidden as a matter of course, infoboxes will - I guarantee it - begin to accumulate cruft and clutter like your crazy aunt's attic. Every time someone proposes adding yet another stray fact to an infobox, they'll defend it in the same way: "*Someone* might find it useful, and, if you don't like the clutter, then just hide it." The only thing keeping infoboxes remotely sensible now is that we all have to look at them. Let's leave them them as they are.
I said two reasons but really it's three. The third is, too many things on line are buried behind hyperlinks already. We click enough as it is. We should just present the text and let the reader simply take in the page, without having to contemplate how they are intended to *interact* with it. Finally, if an infobox looks cluttered or suffers from too much only marginally useful information, fix the infobox. Don't salt it away like we're ashamed of it. JohnInDC (talk) 01:05, 22 August 2008 (UTC)[reply]
I agree completely with JohnInDC. Especially the statement The only thing keeping infoboxes remotely sensible now is that we all have to look at them. olderwiser 12:29, 22 August 2008 (UTC)[reply]
  • In regard to the use of the "Facts-At-A-Glance" hidden infobox at Cellini Salt Cellar, I think that is a really poor option. There are only three facts in the hidden infobox; I think we should default to showing information rather than hiding it. If you want the facts to be shown at a glance, the best way to do so is to actually display the infobox rather than require people to click on it to find them. If people don't like the way infoboxes are now, it would be better to improve the infoboxes rather than have them hidden. --Metropolitan90 (talk) 17:17, 23 August 2008 (UTC)[reply]
  • I also oppose hidden infoboxes, for the reasons I gave at WP:EA, and in agreement with those above. (I've added permalinked-diff examples at the top of this thread.) -- Quiddity 17:52, 23 August 2008 (UTC)[reply]

Tabbed interface

Joopercoopers has posted a solution test page which answers many concerns. It maintains focus on the text and major images of the article as is desired by many opposed to clutter from infoboxes yet allows for presentation of a variety of formated table structures in a tabbed environment. The major concern I suppose would be the additional clicks that would be required to check facts and vandalism. I support Joopercoopers' method as a solution for the issues raised in this discussion, pending further comments from interested parties. Sswonk (talk) 15:19, 23 August 2008 (UTC)[reply]

Joopercoopers' solution is even more elegant than my own.--Wetman (talk) 15:23, 23 August 2008 (UTC)[reply]
While I appreciate the thought and effort that went into it, and agree that it is an improvement over an obscure (and obscuring) Show button, I have two main objections to this latest proposal. The first is both esthetic and practical: The layout (and concept) brings nothing so much to mind as the Windows Control Panel window. And, when you hide so many things behind a so many different buttons, the only way to find out whether any of them are valuable to you is simply to click through to each one - a laborious and time-consuming process. Again I strongly prefer an article that says what it needs to say on a single page that one can read, in its entirety, simply by scrolling. Indeed scrolling is *far* less an imposition on those who dislike infoboxes, than click-previous page, click-previous page, click-previous page, click-previous page is going to be for those who find infoboxes useful. The second objection here is the same as my second objection above, which is that by moving information out of sight, you remove the single greatest constraint on poor content - namely, the eyes of other editors. In all this seems like *way* too much work for clearing out a few infoboxes that some editors don't like. JohnInDC (talk) 15:49, 23 August 2008 (UTC)[reply]
While I like the possible major reformatting of darn near every article on the project, I wonder how practical it is. While I agree to some degree with JohnInDC, I find Joopercoopers' idea to take better advantage of the medium. Is there some reason that hyperlinks in the TOC are more efficient than both a TOC and a kind of meta-TOC? The main problems would be to
  1. determine just how we want to do this
  2. how to present it (look like Windows, look like Linux, look like a Mac, look like something else)
  3. how to do the conversion, and hardest
  4. to convince the rest of the project to do this.
In general, the best change is the least change. For now, unless you really want to attack the big change right now, try concentrating on what you want now. Then air this major reorg in a page where it can be seen by the largest number of editors. I'm very interested in this. "infobox" qua infobox is not my main point: I want a way to see a summary. I've got to think about this. I think a tabbed interface makes sense since pretty much everyone will understand it. Another good thing about it is that it helps split up long articles which go beyond the limits of some browsers without making arbitrary divisions such as exist in some pages. For instance, imagine a South Park article where the List of South Park episodes was on a tab rather than a completely separate article. We could use tabs for such things. This could solve multiple long standing problems. Good work, Joopercoopers! - Denimadept (talk) 16:03, 23 August 2008 (UTC)[reply]
This is all way beyond the scope of an infobox discussion. (Plus, wasn't this originally about achieving simplicity? This solution is the opposite of simple!) Historical note: There have been many suggestions [at WP:VPR] for splitting references/external links/galleries/etc off to new tabs. IIRC they were all thoroughly rejected (you'd have to search the archives, or ask there again, to find out why). -- Quiddity 18:27, 23 August 2008 (UTC)[reply]
That something was rejected in the past is not in and of itself an argument for rejection this time (notwithstanding the notion of perennial proposals) if circumstances are different, or technology has improved. Consensus can change. If particular past arguments are particularly apt, reviewing those particular arguments might well be helpful though. Since you're mooting them, whatever they are, you should feel free to provide the links, rather than suggesting a big search by others. However this proposal should be considered on its merits. Not rejected "because we've always done it that way" or because it was "not invented here". ++Lar: t/c 11:21, 27 August 2008 (UTC)[reply]
This thread has nothing directly to do with infoboxes (it is about tabbed interfaces), and was moved to Wikipedia:Village pump (proposals)#Start of Village Pump discussion days ago. -- Quiddity (talk) 17:57, 27 August 2008 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal: Add a guideline against hiding of infoboxes

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Wording similar to this should be added to to the Implementations section of this article:

Infoboxes are not to be hidden (with the exception of long subsections, eg Toronto or Bertolt Brecht)

The wording may be followed with a sentence confirming the strong opposition to hiding infoboxes by multiple admins and mentioning printing and display problems specifically. For comments in opposition to hiding infoboxes supporting this addition please see this archived Village Pump discussion. Sswonk (talk) 15:48, 26 August 2008 (UTC)[reply]

  1. Admins don't make policy, the community does.
  2. The 'debate' was launched without notifiying me or wetman as far as I can see and so was conducted inabsentia of us making our case (we both had proposals for improvements)
  3. Taking such debate to the MOS infobox now is really forum shopping....again.
  4. Consensus is not a vote it weighs arguments - if the only argument against is its a problem printing collapsed boxes, pehaps there may be a simple and easy technical solution.

Regards --Joopercoopers (talk) 17:22, 26 August 2008 (UTC)[reply]

There were several concerns with hidden infoboxes other than just printing pages. There were what I'd call philosophical objections to hiding otherwise pertinent article information (particularly by default); I noted the likelihood that the ability to hide infoboxes would remove what is probably the strongest incentive for keeping them streamlined now. Those are at least two more issues. All that said, I agree that the issues do not appear to have been fully aired and that possible suggestions need a bit more ripening time before they're ready. I don't by this comment intend to revive the discussion here and now - just to note that there seem to be a lot of different arguments, pro and con. JohnInDC (talk) 17:31, 26 August 2008 (UTC)[reply]
Responses to Joopercoopers above, then let's continue with the wording of a proposed addition as described at top:
  1. Ok.
  2. Nope. The forum outgrew the topic, and was moved from Request for assistance to this spot and finally to WP:VPR at the request of some participants. This was stated clearly at the time of each move. Your proposal got the most buzz at the Village Pump, and then things started to deteriorate through divergence. I suffer for having liked your proposal much better than simply hiding the infoboxes, and subsequently that discussion you wished to develop some more got taken by the wind. I will ask you first to advance your own idea if that type of situation occurs again. But, it was made clear in each forum as a move was made.
  3. Nope. See above, it is back to where a specific proposal against hiding infoboxes needs to be.
  4. Ok. The proposed addition would obviously be superseded by future developments, but infoboxes should not be hidden until then.
Sswonk (talk) 18:32, 26 August 2008 (UTC)[reply]
Point 2. above: the "topic outgrew the forum" didn't seem to fit. The participants broadened the topic is probably better. Sswonk (talk) 18:40, 26 August 2008 (UTC)[reply]
There has been rather a lot of wiggle in where this gets discussed. But more importantly I want to go on record as stating that "strong opposition to hiding infoboxes by multiple admins" is a specious argument. Admins carry no more weight than anyone else in discussion. But if you think they do, how much does being a CU count for? 5 admins? 10? How about being a steward? 50 admins? 100? That's really rather a ludicrous notion, isn't it? We don't decide things based on character classes or hitpoints. (but if we did I think I've got the lot of you trumped all by my lonesome)... I hope this is the last I hear of that particular line of reasoning. ++Lar: t/c 11:29, 27 August 2008 (UTC)[reply]
Lar, that's a lot of question marks for something asked and answered, although you may not have understood that my "1. Ok." in the response to Joopercoopers sought to remove that passage from consideration. Now it is physically stricken. But to provide at least some answer, I think even-handedness, talent and patience are important virtues, often more so than edit counts, adminship or tenacity. I would like to see a few more hours of discourse here, for the record if nothing else, but feel the need to archive this soon if more support is not forthcoming. Thank you for your insights. Sswonk (talk) 13:44, 27 August 2008 (UTC)[reply]
  • Support inclusion of a line stating that "Infoboxes are not to be hidden..." because: 1. Inconsistent (confusing) 2. Accessibility issues 3. Printing problems 4. Can break page layouts 5. Creates edit-war problems 6. Hides vandalism 7. Adds unneeded complexity.
    Note: For anyone who wasn't following along in the thread above, this proposed addition is to prevent future arguments over situations like this (collapsed/hidden infobox in diff). (per WP:ZEN#17) -- Quiddity (talk) 20:16, 26 August 2008 (UTC)[reply]
You're in opposition based in part on quoting yourself on a "humor" page? That seems rather... circular. ++Lar: t/c 11:23, 27 August 2008 (UTC)[reply]
Yeesh! That was a tangential humourous aside. I'll strike it, if that makes you happier. -- Quiddity (talk) 17:53, 27 August 2008 (UTC)[reply]
  • Opppose - This proposal is premature. I think much more experimentation and investigation is needed. And even if this proposal should happen to achieve local consensus here, doing the right thing for the article, taking the article's unique needs and considerations into account, is the right thing to do for the project. The MoS is a guide, not an iron straitjacket. Those mooting this proposal now seem rather... closed. ++Lar: t/c 04:20, 27 August 2008 (UTC)[reply]
Ok. But isn't the place for experimentation and investigation the sandbox and talkpage, not the live article? The infobox collapsed is akin to a point of view, per those previous discussions. When consensus arrives, as I stated above, the proposed MOS guideline above can be deprecated, superseded and booted out altogether. Are there other past experiments you can think of that I can reference? Sswonk (talk) 04:52, 27 August 2008 (UTC)[reply]
Every article, even an FA, is always an "experiment" and a work in progress. Let a hundred flowers bloom, so we can all benefit, rather than stomping through the flower garden with iron boots the way this proposal does. The harm from a bit of minor inconsistency is far outweighed by the continuous improvement that is possible. ++Lar: t/c 11:15, 27 August 2008 (UTC)[reply]
But, apart from mollifying the folks who consider infoboxes to be an eyesore, hiding infoboxes has no tangible benefits, and has many obvious and immediate drawbacks. -- Quiddity (talk) 17:53, 27 August 2008 (UTC)[reply]
  • Oppose Premature per Lar. Hiding infoboxes will be discretionary not compulsory and there may be cases where this is the best compromise between inclusion or non-inclusion of a box. To take Quiddities points in turn: 1. Inconsistency - Infoboxes, despite the claims, are already inconsistent because different projects 'win' the argument for inclusion on different articles see Mission San Xavier del Bac vs. Fatehpur Sikri vs. Sydney Opera House. 2. Accessibility issues - please expand on why this is a problem, it's no worse than collapsible navboxes. 3.Printing problems - still a problem conceeded when in print preview you can click the show/hide box a choose whether you would like to print the box contents as well as the article. The facility to do this is therefore an improved user function. 4. Can break page layouts - so can regular boxes, indeed half their problem is the difficulty of formating normal images around them. 5. Creates edit-war problems - that's an editor behaviour problem, not an endemic problem with the box - infoboxes can do that anyway. (cf. Buckingham Palace) 6. Hides Vandalism - no worse than Navboxes do. 7. Adds unneeded complexity - hardly brain surgery and solves a problem with minimal additional complexity. --Joopercoopers (talk) 11:04, 27 August 2008 (UTC)[reply]
I am skeptical of the naked proposition that a multiplicity of choices, particularly ones designed to satisfy a small subset of consumers, results in an improved user function for the typical user. I am immediately reminded of the problem I face whenever I go to the grocery store to buy orange juice. All I want is the stuff that comes out of an orange when you squeeze it. It isn't a tall order, or *shouldn't* be, but thanks to the many choices provided by orange juice manufacturers desperate to leave no market segment untapped, the task has become time-consuming and exasperating. No pulp, some pulp, *lots* of pulp, calcium added, with or without antioxidants, low acid, with Omega-3, low-cal (with or without calcium). And that's just Tropicana! I find myself buying more apple juice lately. I agree that we should wait to see the proposed implementation of the solution to the infobox issues before trying to achieve consensus on the issue but I have to say, at this point, the solutions all sound like they're going to be *far* more trouble than simply doing a better job of keeping infoboxes streamlined and concise. JohnInDC (talk) 13:27, 27 August 2008 (UTC)[reply]
Point-by-point of the critical issues: 1. We're talking about hidden-vs-non-hidden, not any of the other variables. 2. Collapsible navboxes are bad too, but at least they're at the bottom of the articles. They're only hidden if there are 2 or more, to prevent problems with huge stacks of navboxes. 3. In wiki's printable-mode you can select hide/show, but you cannot see the infobox at all - regardless of which you pick - in firefox's print-preview mode. 5. But hidden-vs-non-hidden is a whole new thing to edit-war over, that the Ponte Vicchio experiment raises. 7. Accessibility again - we're trying to make an encyclopedia anyone can use. Not just for people who know how to tweak interfaces. (We may find these things obvious, but the barely-computer-literate do not). The default view should be the most accessible view.
Again: The only benefit that hidable-infoboxes has, is mollifying the anti-infobox folks; the drawbacks overwhelm this one benefit. -- Quiddity (talk) 17:53, 27 August 2008 (UTC)[reply]
Striking my refutation above regarding printing - Quiddity gets this one. Developer fix? --Joopercoopers (talk) 23:04, 27 August 2008 (UTC)[reply]
I've offered some thoughts as to why you might want to "mollifying the anti-infobox folks" at [6]. Infoboxes don't have problem per se, but there's a fair chunk of subject matter in which they are inappropriate - policy to deal with this would be good.--Joopercoopers (talk) 23:07, 27 August 2008 (UTC)[reply]

As things have progressed, the above revised wording and focus seems more to the point. I consider it moot to state within the wording that disputes surrounding the appropriateness of an infobox for a given article should be discussed on the article's talk page, since I compare infoboxes to images or tabular data. This wording can be revised to change "pages" to "tabs" if a tabbed display implementation for articles becomes available in the future. Sswonk (talk) 23:51, 28 August 2008 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Revised proposal against hiding of infoboxes

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Wording similar to this should be added to to the Design and usage section of this article:

Infoboxes are not to be hidden or made collapsible on pages. Unlike navigation templates (navboxes), which are provided to simplify navigation to related subjects within the encyclopedia, infoboxes are considered to be an integral part of the body of an article, similar to images with captions or tabular data. Larger sections of parameters within an infobox may be collapsible, eg. in Toronto and Bertolt Brecht.

For comments in opposition to hiding infoboxes supporting this addition please see this archived Village Pump discussion. Sswonk (talk) 01:01, 29 August 2008 (UTC)[reply]

  • Oppose I'm awaiting developer feedback on the printing issue - so premature - and disagree that 'infoboxes are an integral part of the body of an article - actually its quite disingenuous - they are typically integral to the summary of the article not to mention, misleading, inaccurate and facile, essentially failing to identify the most important facts of the article. If we want data attached to articles, there may be a better way. In the mean time the ability to hide such disinformation seems a reasonable proposition. --Joopercoopers (talk) 01:06, 29 August 2008 (UTC)[reply]
I actually crafted the proposal with you in mind, as I thought you would see that a box could be vetoed on certain pages as a table or image might on aesthetic grounds you may then so eloquently state on a given talk page. As the proposal states, the hiding solution is a non-starter. On most pages with infoboxes, it includes an unambiguous, usually very high quality and beautiful, image and then the most fundamental statistics, which are of value to many readers. Often these statistics are not included within the article themselves because they can only be stated in long boring passages that don't go well with historical or informative exposition and discussion of the topic.
This discussion should focus on the hiding of infoboxes, not their merit or your opinion of their current usage by other editors within the encyclodia, which you unfortunately have attempted to make the focus here, yet again. Sswonk (talk) 01:24, 29 August 2008 (UTC)[reply]
Actually swonk - in all fairness, I should have said 'in some articles'. There at those, which I readily concede, in which they are appropriate and not with the defects I listed - unfortunately I see no 'hard and fast rule' as to which these may be - context is key. --Joopercoopers (talk) 02:48, 29 August 2008 (UTC)[reply]
  • Oppose - Premature. As above, and this was archived for a reason. Give Joopers, and the developers, some time, eh? There is no way "the hiding solution is a non starter". Let's talk in a month or two, maybe. There is no deadline. ++Lar: t/c 01:55, 29 August 2008 (UTC)[reply]
  • Support - I don't foresee any technical solution to the essential and unreduceable problem, which that hiding infoboxes inherently entails concealing information that by consensus warrants inclusion in the article. Again, if an infobox is superfluous or overburdened with trivia, fix the infobox. Don't use software simply to create a rug under which to sweep them. JohnInDC (talk) 02:50, 29 August 2008 (UTC)[reply]
    • You not foreseeing a solution doesn't mean there might not be one. But a blanket prohibition on hiding is... blanket. And therefore wrong. Every rule has exceptions, except for the rule about every rule having exceptions. ++Lar: t/c 04:21, 29 August 2008 (UTC)[reply]
      • When the unforeseeable technical solution manifests itself, the rule can be amended. As for the argument that the proposal should not be adopted because "all rules have exceptions" - I assume that was tongue-in-cheek, inasmuch as the reasoning would forbid the adoption of any rule about anything at any time. JohnInDC (talk) 11:57, 29 August 2008 (UTC)[reply]
  • Comment - I really wish I could Support this, but the comment about "blanket" rules bugs me and I can't just dismiss it. My position is that a bridge is helped by an infobox, either {{infobox bridge}} or {{Geobox|Bridge}} take your pick. In fact, I'd start using the Geobox if I could figure out how to use it. Anyway, I can't say this about all infoboxes, and in fact I learned of one infobox yesterday which I don't like, so I can't back the blanket statement. In fact, I'd rather like to edit the infobox bridge too, as some items in it seem, shall we say, non-core. I'm a bit hesitant to screw with the code, though. - Denimadept (talk) 14:28, 29 August 2008 (UTC)[reply]
    • In the archived discussion preceding this one, in his comment Lar (talk) writes "The MoS is a guide, not an iron straitjacket." Then here he cryptically states "But a blanket prohibition on hiding is... blanket. And therefore wrong. Every rule has exceptions, except for the rule about every rule having exceptions." Once a coder, always a coder? The proposed guideline could be changed in tone slightly to avoid having it called "blanket" but I suspect Lar is still going to hold firm; just my observations. Sswonk (talk) 15:12, 29 August 2008 (UTC)[reply]
      • Oh, there's an exit condition from his statement. We need to find it. - Denimadept (talk) 15:19, 29 August 2008 (UTC)[reply]
        • I'm confused - Sswonk are you suggesting you'd change the wording so it says hidden infoboxes might be allowed in some cases? Seems like a pointless proposal in that case?????? Blanket is blanket - which is it? Please elucidate. --Joopercoopers (talk) 16:43, 29 August 2008 (UTC)[reply]
          • You're confused! Imaging my driving in rush hour traffic this morning when suddenly my head is filled with beautiful valid CSS that creates a striking little imageless file folder tab that is labeled "Vital statistics" and magically expands to contain any infobox, and seeing you and Wetman grinning broadly in approval. Luckily, I snapped out of it when oncoming traffic grabbed my attention. To apply some Lar style semantics, I meant what I wrote: "to avoid having it called blanket", not actually being blanket. Doesn't IAR have that covered anyway? It would be an all inclusive, "blanket" guideline until a beauty like I describe above that prints and is shown, not hidden, by default comes along. Nice. Sswonk (talk) 17:11, 29 August 2008 (UTC)[reply]
            • Sorry if I was too oracular. At this time I don't think the technical aspects of using show/hide are sorted, especially with regard to printing. (I don't agree with the usability arguments advanced). So I'd be opposed to a blanket requirement that all infoboxes get show/hide functionality at this time. It's premature. However, it's also premature to make a blanket prohibition. If you want a guideline that says "only use this in very limited circumstances, for now, pending resolution of issues, and with the understanding that it's experimental, for now, and in the end it might need changing back." I'd get behind that. But not a blanket prohibition. That stifles innovation, locks in less capable solutions too early and in general is a bad idea. As are all blanket prohibitions. (except the blanket prohibition on blanket prohibitions) ++Lar: t/c 15:55, 30 August 2008 (UTC)[reply]
  • Support, in agreement with Sswonk and JohnInDC throughout. I don't imagine the hiding-code would ever attain consensus for addition to Template:Infobox (especially with the default state as "hidden"), for all the reasons discussed over the last week, hence it shouldn't be used in an ugly div-hack within a single article either. However, I'd happily delegate all opinion to whatever the developers say about it; hopefully they can explain the problems better than I/we have been able to. -- Quiddity (talk) 17:32, 29 August 2008 (UTC)[reply]

I am archiving this discussion pending the development of a viable solution. Development of an experimental infobox at Ponte Vecchio is an example of an attempt at innovation which may improve the project. Sswonk (talk) 18:01, 30 August 2008 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Infobox citations

I have looked through what I was pretty certain were the relevant guideline pages, and have been unable to find an answer to my question. Are citations needed in an infobox? I ask specifically to the infobox in The Dishwasher: Dead Samurai, as I added the fact that there was Multiplayer in addition to the Singleplayer. It is stated in Silva's blog that the game has this, so I thought the information should be added, but didn't know if it needed to be cited or not.

I eventually decided to just rewrite and add the information to the article itself, source it there, and then it won't matter much, but I would still like to know for future reference if citations are needed for infoboxes if the information isn't specifically in the article. --Mike | Contrib 07:48, 3 September 2008 (UTC)[reply]