This is an archive of past discussions about Template:Infobox. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
All infoboxes based on this template are no longer floating right for me. Did something change recently here or upstream? → ROUX₪03:20, 8 February 2010 (UTC)
There have been no changes since December, and I don't see anything upstream to change. Also, I'm not seeing any differences in the Infoboxes on my end. Anyone else seeing a different behaviour in the template? — Huntster (t@c)10:06, 8 February 2010 (UTC)
I had this problem for about 15 minutes late yesterday. clearing my browser cache solved the problem. I suspect someone made a change to one of the common CSS files that goofed things up for a short time. --Ludwigs217:44, 8 February 2010 (UTC)
Any point to the navbar?
This template includes Template:Navbar, so every descendant box has a "view - edit" blob in it. Is there really any point to that? I can see the use for boxes that contain lists of things or for templates that are specifically for a small number of pages, but it has caused some head-scratching with people who use Template:Infobox rail, a broadly-used template. Can we at least add an option to hide the navbar? —Mulad(talk)15:57, 24 February 2010 (UTC)
I personally find it very helpful, but it can be supressed on a per-template basis by not passing the |name= parameter. — Martin (MSGJ · talk) 16:09, 24 February 2010 (UTC)
Yup, it's normally omitted. I usually leave it off unless I'm using this meta-template to construct a templatespace sidebar; using it on an inline translusion on articlespace is confusing. Chris Cunningham (not at work) - talk13:57, 2 March 2010 (UTC)
That template and its documentation was not set up correctly. I have now fixed this and the navbar give editors a convenient link to the infobox template. There is some agreement here that these links are confusing. Some possible future options are:
Omitting the navbar completely.
Changing its appearance and position in the infobox to make it less confusing, if possible.
Hide it by default and allow editors to switch them on individually by setting their monobook. (This is what we already do with these navbars in {{asbox}} and {{WPBM}}.
I would oppose the first option as I think these links have the potential to be useful to editors (although not necessarily to readers). — Martin (MSGJ · talk) 12:02, 8 March 2010 (UTC)
Oh, that simple. I must have spent 30 minutes trying to find the problem. IMHO, if those links are meant for seasoned editors they should be made less prominent. What about v • d • e in a corner somewhere like in {{Human anatomical features}} and many other templates. --Fama Clamosa (talk) 12:41, 8 March 2010 (UTC)
I've made the edit, but I'm not completely convinced. Now people are going to be confused about what the v.d.e is for. Let's see what others think. — Martin (MSGJ · talk) 16:55, 8 March 2010 (UTC)
Oppose. Completely unnecessary. The boxes are wide enough as is. As noted in the discussion at Template talk:Infobox company#Minor Changes, the problem you are having with that single article has nothing to do with the width of the box. Nor is that a "minor" change, as the infobox is currently around 240-250px, depending on your monitor. -- AnmaFinotera (talk·contribs) 15:31, 25 March 2010 (UTC)
I think the 22em default size works well for most infoboxes. You have to remember that an infobox take up a lot of real-estate on small screens, so they should only be as wide as they need to be. —Farix (t | c) 01:02, 26 March 2010 (UTC)
I disagree the infobox should only sit next to the lead and the table of contents and on almost all articles there is white space there - even on very small screens - which can be used in part to stop the infobox from taking space from other sections. Gezzza (talk) 02:04, 26 March 2010 (UTC)
The length of an infobox isn't generally a problem for most articles. In fact, intruding into the first few sections isn't an issue unless the article itself is formatted poorly (such as excessive use of images in the first few sections. There is plenty of vertical space to work with. However our horizontal space is limited, so an infobox should minimize it's footprint horizontally.
Would it be feasible to set the width so that is was dependent on the size of the screen. For example 25% of the width of the total. — Martin (MSGJ · talk) 08:52, 26 March 2010 (UTC)
It can easily be set proportional to the width of the browser window using CSS. however, I suspect that would produce some fairly unpleasant results - structured material with a variable width often looks bad at some widths and good at others.
The width of an infobox can already be changed on a page-by-page basis. just add |bodystyle=width: 290px to set the width of the infobox to 290px. --Ludwigs215:19, 26 March 2010 (UTC)
Yep, I do know about that but I thought it will be a better idea to keep the same width for all articles. But at least it will be something to fall back on. Gezzza (talk) 17:02, 26 March 2010 (UTC)
It already is dependent on the size of the screen, as it uses em, which is a relative measurement, rather than a fixed pixel width. One can also just add their own custom monobook.css to their account if they want infoboxes to be larger. The article that prompted this question, however, did not need any changing or expanding of the width, it simply needed some very basic MoS fixes which solved the "problem" it was having. The OPs main issue appears to be an issue with the infobox "protruding" past the menu, which is not something that can be "fixed" as has been explained to him in discussions in two other places. -- AnmaFinotera (talk·contribs) 16:22, 26 March 2010 (UTC)
AnmaFinotera, I already know your view on this change - as does everyone else - and I for one want to hear from what other people think about this change not just you. Also you need to do more research on em as it doesn't change because of the size of the screen but on what font is used by the browser and the zoom level. Both of which now happens to px in the latest browsers anyway. Gezzza (talk) 16:56, 26 March 2010 (UTC)
I am entitled to respond here and continue both clarifying my views and respond to others responses, the same as you. I also think its important that others participating know the entire picture, as you neglected to mention that you first brought this issue up in one place, then another and now a third. You've also made your view clear on this in three different places, but you also continue to respond. EM is considered the best font to use for accessibility and readability because it is a relative measurement. Yes, relative to the font and browser font, which is set by the user. Sorry if I did not write that more clearly. -- AnmaFinotera (talk·contribs) 17:03, 26 March 2010 (UTC)
Where was the third one? Because I don't remember a third one. I first bought this up here but I was told - and later I confirm by looking at the code - that Template:Infobox_company template didn't actually set the width but this one did which is why I asked this here. Also maybe you should recheck what you posted "dependent on the size of the screen, as it uses em". Gezzza (talk) 17:16, 26 March 2010 (UTC)
*HEY PEOPLE! please keep it civil. I don't think there is any consensus for this change at the moment, but the conversation still has a right to continue. please focus on the question, not the contributor.--Ludwigs217:32, 26 March 2010 (UTC)
it would be a little helpful to brain dead people like me if it could somehow indicate that when 'all three' (header, label, data) are defined, that they dont show up in the infobox. it just seems counterintuitive. i know it 'says it' right below the example, but a little note within the code (ie "this wont show up") wouldn't hurt some of us dunderheads who skip over the 'wall of text' and just look at the code. i think the problem is that in most computer situations, the header is the header and the body is the body and they both show up .. and i cant figure out why you would call something 'header, label, data' if one would hide the others. anyways thanks. Decora (talk) 01:04, 12 May 2010 (UTC)
I'm having difficulty adding show/hide functionality to infoboxes at the top of articles, specifically at iPhone. Copying PlayStation 3, I jury-rigged iPhone using raw div classes (that I don't really understand). This took some trial and error with the show preview button, and I found that {{show}} and presumably {{hidden}} do not work, and that I can only hide one header (Connectivity, CPU, Input, etc.) per copy of code. I would like to hide several consecutive headers all tied to a single show/hide switch. Is this possible? And as a side question, is it possible to make adding this functionality easier? Thanks, HereToHelp(talk to me)16:46, 6 May 2010 (UTC)
Not that I know of. The modular nature of the template really should make this trivial, but it's a case of finding someone who has a firm grasp of how our collapsing code works to have a look at it. Chris Cunningham (not at work) - talk21:47, 7 June 2010 (UTC)
If you can decide how you want it to work I can probably work out how to code it. Is it just individual rows that you want to make collapsible (like on iPhone) or do you foresee a need to collapse entire sections as well? — Martin (MSGJ · talk) 09:20, 8 June 2010 (UTC)
New "child" option
I have added a new "sub-infobox" feature which was being tested in the sandbox. This will allow this infobox to be nested, if the "child" parameter is set to "yes". The documentation will be updated shortly. Please revert (and let me know) if this causes a problem. It was added to deal with issues that came up at {{Infobox person}}. See articles transcluding {{Infobox person/Internet info}} (e.g., Matt Harding) for examples. Thanks! Plastikspork―Œ(talk)19:48, 5 June 2010 (UTC)
Looks okay to me. Could we use such an approach to hook extra rows on to an infobox? Then perhaps we could simplify this template by removing support for, say, rows 41-80. — Martin (MSGJ · talk) 18:30, 6 June 2010 (UTC)
That should be possible. It also simplifies "renumbering problem" when one wants to insert new rows into a template, since only the numbers in a particular subsection would have to be renumbered. Do we know which templates are using high row numbers? I know {{infobox martial artist}} is using around 70. Plastikspork―Œ(talk)19:43, 6 June 2010 (UTC)
I just reverted someone else who added a parameter to this template without discussion. Would you mind making the case for this parameter and getting a consensus before editing this highly visible template? — Martin (MSGJ · talk) 08:51, 9 June 2010 (UTC)
I've reverted the change for now pending consensus. And I might take up the offer to slap Dinoguy with the trout ... — Martin (MSGJ · talk) 11:59, 9 June 2010 (UTC)
Trout well-received; I should've known better. =) Would it perhaps be more acceptable to add another header under the image, or should I simply see if there is any consensus to change the order of elements in {{Infobox road small}}? 「ダイノガイ千？！」? · Talk⇒Dinoguy100017:06, 9 June 2010 (UTC)
The small version of the infobox was developed as a companion to the larger, main {{infobox road}}, which has had that ordering for several years. You likely will not get consensus to change the ordering of either infobox. The small variant is in use on articles like Business routes of Interstate 196 that merger several separate, but related, highways together into one article. Imzadi1979→18:03, 9 June 2010 (UTC)
You could achieve the same appearance by moving the name to "header1", but I agree that this doesn't seem to be semantically correct. Plastikspork―Œ(talk)20:10, 9 June 2010 (UTC)
I'm not sure why a change is required anyway, to be honest. There's no hard requirement that images are only added to image attributes: indeed, there's nothing specifically "imagey" about them from a code point of view. That said, the layout of that template is rather idiosyncratic, and (as has been pointed out to several wikiprojects recently) wider community concerns like infobox accessibility are not subordinate to local consensus as found on WikiProject discussions. Chris Cunningham (not at work) - talk20:55, 9 June 2010 (UTC)
Let me ask this then, what's wrong with the current {{infobox road}} and {{infobox road small}} regarding the location of highway road marker images? {{jct}} generates a <graphic> <highway name> combination that conforms to MOS:FLAG guidelines. The only difference with the combination at the top of the infoboxes is that the <highway name> is on a separate line and not abbreviated. The infobox subtemplates have even been extended to add alt text to the infobox. What's the issue then? Imzadi1979→21:08, 9 June 2010 (UTC)
The carriage return should allow wiki bullet and list formatting to work correctly in data cells. currently the first item in any list is not wikified if it's on the first line of the of the parameter specification - example at right. —Preceding unsigned comment added by Ludwigs2 (talk • contribs)
Unintended consequences in Template:Infobox knot details
Is there a way to override this new behavior? The content in field data10 of Template:Infobox knot details are ABOK reference numbers which, by convention, always begin with a '#' character. This field is now being incorrectly rendered as a numbered list. Given the above comments, and since the knot details infobox has not been changed in quite a while, it appears this new behavior resulted from the above change (diff). As an example of what has gone wrong, see the infobox on Constrictor knot. The list should read "#176, #355, #364...", not "1. 176, #355, #364...".
I am not a wiki markup expert and would appreciate help/advice on the most appropriate way to override this new behavior in this field of the knot details infobox. The content does include bold and possibly other markup, so I just want to be able to override the new list behavior in this field and not disable all markup. Any recommendations would be appreciated or, failing any reasonable workaround, consideration of a reversion of this change. Thanks much... --Dfred (talk) 20:04, 6 July 2010 (UTC)
I have a version in the {{Infobox/sandbox}}. The changes are very minor but it has been on my mind for a long time. I created a couple of synonymous parameter names so that the coder can use subheader1 and subheader2 instead of subheader and subheader2. This is consistent with image1 and image2. No big thing but the way it is now bugs me a little. Other differences are just code beautification and are not substantial. –droll[chat]23:42, 29 June 2010 (UTC)
Would it be possible to add a tracking category for templates that make use of the subclassing option? It would be useful to know which infoboxes make use of this feature. PC78 (talk) 07:57, 10 September 2010 (UTC)
The only issue I can see is reliably restricting it to only templates. If the template in question uses a <includeonly>...</includeonly> around the template, or something like that, it won't necessarily show up in the tracking category. A more reliable method would be to have a bot run through all the templates which use this template and check (or use an equivalent database dump check). However, if you aren't worried about completeness, then it should be possible. Plastikspork―Œ(talk)20:57, 11 September 2010 (UTC)
{{editprotected}}
Please update Template:Infobox/row according to the update - reviewed by an accessibility expert - of Wikipedia:Manual of Style (accessibility)#Data tables. Updating this template is a top priority for accessibility since it is included in more than 670.000 pages. This update won't have any effect on the layout and such, it is an invisible code change. But important nonetheless. And because of its invisibility it is a consensual change, so you admins can go ahead without fear. It consists of adding scope="row", which is important for screen readers for example, but has also many useful uses like reuse of data.
Thank you so much, this is awesome. Such a small edit that made a tremendous improvement. I so love standardised and well-structured templates! :-) Dodoïste (talk) 16:17, 15 October 2010 (UTC)
Thoughts on subclassing
From a recent discussion with Chris Cunningham, my understanding is that when the subclassing option is used, title is converted into a header and above is hidden. After some consideration I have the following comments:
title and above tend to be used interchangeably for the same thing (i.e. a |name= parameter or similar); in fact, from my own observations it seems that above is by far the more common styling. I don't think it's a good idea for subclassing to necessitate a preference for using title as it currently does.
Chris commented about using title in order to keep all the logic in one place and avoid using a seperate header. But I diasgree with this. The two things are essentially different, and any benefit in lumping them together is surely negligible since it requires an if statement to toggle between the two (as was done here). IMO, it would be simpler, cleaner and more user friendly to have a seperate |childheader= parameter for this purpose, with both titleandabove hidden by subclassing.
I've made some changes in the sandbox; it seems to test ok, but one of you guys will need to check it over. Some additional thoughts:
Should |childheader= be accompanied by |childheaderstyle= and |childheaderclass=, or are these best dictated by |headerstyle= and |headerclass= to keep all headers in sync? (I'm thinking the latter myself.)
Interesting. I really don't have a strong opinion, so long as it renders correctly. I have noticed that subclassing does add to the transclusion depth, which can cause problems with deep templates like {{convert}}. However, that is more of an issue with convert than it is with this template.Plastikspork―Œ(talk)00:24, 25 October 2010 (UTC)
I keep getting Template:Safesubst: appearing on the wikia. Please help
All of the infobox templates have the same error on all the wikias. Template:Safesubst: appears above the otherwise perfectly functioning infobox. example: http://manga.wikia.com/wiki/Asuka_Langley_Soryu Any way to fix this? I asked around for awhile now, and no one on the wikia community center can figure it out. DreamFocus17:30, 29 October 2010 (UTC)
Safesubst is a relatively new feature of MediaWiki. Most probably, the version running on Wikia may not support it yet. — Edokter • Talk • 21:24, 29 October 2010 (UTC)
They just recently completed a forced mandatory update to wikia, so it should have all the latest features Wikipedia does. This error has also been around for months now. Anyway to alter the infobox template so that problem doesn't happen on Wikia? DreamFocus02:18, 30 October 2010 (UTC)
You could always just create a template with just the text subst: in it, which might work. Or a completely blank template could also temporarily work around the issue. Plastikspork―Œ(talk)02:31, 30 October 2010 (UTC)
Tried both. It still appears, and as a red link. I hover the mouse over it, and it says Template:Safesubst: doesn't exist. But I click on it and find the page I made. Did this hours ago, so the wikia had plenty of time to update its server or whatever it needs to do to notice it. Any ideas? DreamFocus11:47, 30 October 2010 (UTC)
Try purging the template and the page it appears on. Caching can take days to catch up. I just purged it, and now it shows a black "subst:". — Edokter • Talk • 12:10, 30 October 2010 (UTC)
By purge you mean reload? I hold Shift and click the Reload button on Firefox, but that not doing it for me. I saw the black Subst: so I then edited the template page to be blank. Got to wait for the Wikia server to reload I suppose, it sometimes taking awhile. I don't think there is a command I can send wikia to make them reload things straight away. DreamFocus13:01, 30 October 2010 (UTC)
This is weird. I looked through some of the many pages that link to this template. [1] It quite a long list. Some show nothing at all now, the Asuka page shows "subst" and the rest show either blankness, or show the red link template:safesubst: [2]. DreamFocus13:12, 30 October 2010 (UTC)
Update: From the way I see it, it seems possible; just a matter of replicating the entries in the template. I will request an admin to deal with it shortly. Rehman(+)07:47, 30 October 2010 (UTC)
A 150 ??? That will double the already high amount of parser commands and make any page that uses an infobox slower to render after editing. In my opinion, any infobox that needs 150 rows, needs a redesign in itself. Perhaps use some subtemplates or something ?—TheDJ (talk • contribs) 11:05, 30 October 2010 (UTC)
(edit conflict) It should be possible to achieve the same effect with subclassing, rather than by extending this template for the sake of a single infobox. Check your sandbox now, hopefully it should do what you want. PC78 (talk) 11:06, 30 October 2010 (UTC)
I think TheDJ has a point with his comment above. In addition, there was some enthusiasm in past discussions for reducing the number of rows in favour of using the subclassing method. PC78 (talk) 11:12, 30 October 2010 (UTC)
Good points and good idea. Thank you, both of you. P.s. PC78: You may ignore my 100-row comment at your talkpage. ;) Kind regards. Rehman(+)11:15, 30 October 2010 (UTC)
Font size: readability
Summary: A large number of readers - like elders, and people won't doesn't know how to zoom with the Ctrl-+ key - experience difficulties to text text in small font size such as infoboxes. Plus, scientific studies proved that text in small font size takes longer to read, and reduces usability. Thus, this is a proposal to set the font size of infoboxes (88%) back to default (100%).
The default text size in infoboxes is reduced, with "font-size:88%". Small font size are hard to read, and thus reduce usability. This was proved by scientific reading studies, small text size can lengthen the reading rate by 1.5. For example, a text that you could read in 20 seconds in normal size (12 points) could take you 30 seconds in smaller size (10 points). See Wikipedia:WikiProject Usability/Readability guidelines.
The web designer community promotes design that are beautiful whatever the size of the text. And most of them try to avoid small text and such, as it doesn't make the Webiste beautiful, it only makes it hard to read. Small text is used only for elements of the interface that we want to keep almost invisible, that we intentionally want to set aside. It's the opposite for infoboxes. Infoboxes are a prominent content, useful, that users want to read. So we shouldn't reduce its size, and set it back to default.
Since this is a layout change, I suspect some users might oppose it for some reasons. So I suggest to ensure we get enough consensus about it before making the change. What do you say? Kind regards, Dodoïste (talk) 22:34, 17 November 2010 (UTC)
Given the incredibly large number of transclusions, I would suggest starting an RFC. The rationale for 88% is that it is the largest percentage below 100% which generates consistent results across browsers. I personally use the Ctrl-+ key in my browser, which allows me to increase the font size and circumvent the issue. Your observation that the infobox is prominent and useful is not shared by all, although may be the view of editors who watch this page. Just a few thoughts on the matter. Thanks! Plastikspork―Œ(talk)02:54, 18 November 2010 (UTC)
OK, let's go for a RFC.
I also use the Ctrl-+ key, and in fact I always keep the zoom at 120% or 130% on Wikipedia, because the text size is so small here. On other Websites I don't need to do that.
The real issue is for users that are not proficient with keyboard shortcuts, which represents a huge amount of users. Among elders and people over 40 years old, many users does not know how to zoom into the page using the Ctrl-+ key, they don't even know such a feature exists, so don't won't try to find it.
I've seen numerous Wikipedia users who simply couldn't read small text because they did not know the Ctrl-+ key, and thus avoided small text. For example, a user at the French Wikipedia learned about the Ctrl-+ key after 3 years of editing, and then was finally able to read the small texts that she couldn't read before. Personally, now I'm a "tech guy" so I know how to use the Ctrl-+ key. But when I was a Wikipedia reader in 2007, and during my first year of editing in 2008, I was just your average Wikipedia user who didn't know a thing about the Ctrl-+ key. And I was having some really hard time to read.
Most internet users doesn't know the Ctrl-+ key, only geeks and power users do. We should take it into consideration, and stop making a widespread use of small font sizes. Dodoïste (talk) 02:42, 19 November 2010 (UTC)
While the consistent font size issue is no longer apparent under the Vector skin, 88% still is the largest fontsize to trip Windows into using a smaller typeface (90% uses the same typeface with tighter spacing). But we also have to take window sizes into account. Enlarging the font will either enlarge the infobox, detrimenting readability of the surrounding text on small screens, or cause unwanted linebreaks within the infobox itself, also detrimenting readability. I don't think the reading studies apply here, as infoboxes are nor running text, but a collection of isolated terms, so reading speed should not be an issue. — Edokter • Talk • 12:31, 18 November 2010 (UTC)
Most readability testing is made with a paragraph of text, yes. Because it's easier to test it that way. But it doesn't mean that it isolated terms are not concerned. Any small word takes longer to read, in fact.
Slightly enlarging the infobox will not be detrimenting readability on small screens. A difference of a mere 10px will never be detrimental.
Linebreaks would reduce readability indeed. But if we enlarge the infobox by one or two ems, there is no way it could happen. Dodoïste (talk) 02:55, 19 November 2010 (UTC)
"No way" is a strong statement, especially considering variability between browsers. However, I will say that not all infoboxes are using the default either, often for the purpose of reducing line breaks. So, any changes in the default would most likely be met by tweaking of the individual boxes by disgruntled editors. I can point you to extended discussions about font size for music/single/chronology infoboxes for example. The point being that there is no way to make everyone happy, as one would naturally expect in a large project. Plastikspork―Œ(talk)03:20, 19 November 2010 (UTC)
These days, the rendering in browsers concerning the layout is extremely similar, approaching pixel precision. My statement is accurate, and reflects the improvements of browsers in this domain. This was already the case in fall 2009, so it should be a safe bet today.
I can teach users how to modify their vector.css to reduce the font size in infoboxes if they want to. Or we could even provide a gadget for that if necessary. The point is, the default font size should be normal, and not reduced.
I would appreciate links to discussions about font size for music/single/chronology infoboxes, as it would help me to understand the motives of these users to reduce font size. Yours, Dodoïste (talk) 03:44, 19 November 2010 (UTC)
It's worth pointing out that there are infobox templates which use the larger font size and have resisted following the standard we've got here, in particular {{taxobox}}. My primary concern is consistency: if there's consensus to simply drop the font size declaration I'd be all for that. I'm not convinced that increasing the font size is going to seriously distort the infobox's prominence in articles. How about a trial run, bumping the default size for a couple of weeks and collecting feedback? Chris Cunningham (user:thumperward: not at work) - talk15:03, 19 November 2010 (UTC)
Your "trial and feedback" idea seems great, I support it. Besides, it seems to be the only way to get significant attention from users. :-) Dodoïste (talk) 18:09, 19 November 2010 (UTC)
Well, we never had complaints before, so I'm sceptical. No offense Dodoiste, but you are the only one complaining at the moment. Even though you have the best intentions in mind, it does seem this is motivated more from a personal preference then from a broader goal with regards to accessability. So I would like more input before we start any trail, because changing anything without a broad consensus if bound to fail. — Edokter • Talk • 20:23, 19 November 2010 (UTC)
Of course you never saw any complaints before. Such complaint from end users are really scarce. A really large number of users experience difficulties, but they are not accustomed to report such complaints for various reasons. For example, they often believe it's their fault for not knowing how to deal with small text, and feel stupid. They may not be sure if the problem comes from the Wikipedia interface, their personal hardware, or else. They experience one difficulty among many others, and they have no prominent place to report such issues with the certainty they will be listened to.
Plus, the number of users who knows enough about readability is exretremely low, so few user know that Wikipedia is at fault here. Usability in general is not understood by end users, so don't count on it.
This proposal is not supposed to improve accessibility, but usability. The purpose of this change is to improve readability for elders and users not familiar with the Cltr +- shortcut. I fit in none of these categories, so this proposal is not a personal preference. I've read books about usability and readability, which is not common for Wikipedia users nor most developers. But if you were to discuss this proposal with the WMF employee interaction designer Parul Vora for example, she would agree with this proposal without a doubt because she knows a lot about usability. Dodoïste (talk) 13:16, 20 November 2010 (UTC)
It is a really big assumption that most people with visibility problems don't know how to fix their fontsize on their display, or don't complain; I think most of them do know. And most of them that don't know are able to ask question here or on other websites. If those people indeed have a problem, they would most certainly have made that clear is some form. Asuming they don't complain is, in my view, arrogant. It creates the appearence of arguing for "the silent majority", and I'm kind of allergic to that. The fact is, many elements of wikipedia use a smaller font size, mostly inline notes, sometimes even too small (below 85%), and I'm all for fixing that. But if we end up getting grid of all smaller elements, Wikipedia would end up being one dull website. — Edokter • Talk • 13:44, 20 November 2010 (UTC)
It depends on the severity of their visual impairment. Users with slight visual impairments won't experience blocking or critical problems most of the time, only small issue repeatedly. And more issue on websites like Wikipedia that uses small text size, and have several prominent content that is small. Thus, they might not feel that they are experiencing something abnormal, or might not feel the need to desperately find a solution by all means. Most inexperienced users might not even think that a solution could exist, so why would they look for it?
This happens on other websites too, and other websites do not receive complaints either. Simply because there is almost no website that provides an explicit link like "you are having problems to use the site? Contact us." Readers are not used to do such a thing. Lots of readers do not know Wikipedia can be edited, nor that talk pages exists. And for those who knows, where would they report it? There is no prominent page dedicated to it.
Small is not beautiful. A tremendous amount of Websites do not display text in such a small font size, and do not look dull at all. Designers says that a Website should look beautiful whatever the font size it is displayed in. It's OK to have unimportant information and details that nobody looks for in small. But such small sized texts are usually placed at the bottom of the page, or someplace where it's not supposed to be seen except if the user is specifically looking for it.
Now, either there is consensus to decide that infoboxes are useless and should be moved to the bottom of the page, either we decide it is useful and we set its font size back to default. Yours, Dodoïste (talk) 18:02, 20 November 2010 (UTC)
Which is exactly what I'm affraif of... I don't like this change and I don't like the way you handle the situation. Instead of going through all templates that use small fonts (infobox isn't the only one), maybe a site-wide solution is more appropriate. Many sites have a so called 'font size button' (A A A) that immediately increases the site's font size. Would that not be a better solution? — Edokter • Talk • 20:05, 20 November 2010 (UTC)
A font size button is a good idea, sure. I'm not sure how it would fit in the Wikipedia design though, there is no appropriate place for it. However, such a button is not meant to compensate for this issue. The main issue is consistency. Infoboxes have no valid reason to be smaller than the rest of the website. A user will set the font size they are comfortable with. When they will find such infoboxes, the text will still be smaller than the size they feel comfortable with.
Edokter, if you want to keep infoboxes at a small font size, just add a CSS class in your vector.css for infoboxes. Yours, Dodoïste (talk) 20:54, 20 November 2010 (UTC)
Break
Infobox was indeed designed to have a smaller font, so yes, it is intended to have a smaller font the other text. Many templates are designed that way. It is intended to seperate the main content from the supporting material. And please don't turn issues around as if I am the exception; I am not. You are the one advocating a change, so you have to make the case. Readability is good, but don't abuse that cause by speaking for a group by claiming they don't know how to speak for themselves. — Edokter • Talk • 21:26, 20 November 2010 (UTC)
I don't agree with a 100% font size for infoboxes. But I do agree that 88% is too small. In Chrome 8 (Windows 7, 1280x800, default fonts), 88% (and 89%) corresponds to 11px font-size. 90% to 98% corresponds to 12px and 98% to 100% to 13px. --Locosepraix ~ Beastepraix23:52, 20 November 2010 (UTC)
The width is not a problem; it scales. But I still oppose the change. For one, the text is not unreadable. If we were to change to 90%, other templates will need to be changed as well, because a mixture of different font sizes will look horrible. We now have a setup of normal, small and big. If we are going to change this, we either loose the distinction, or end up with a pleatoria of different font sizes, which really hurts aesthetics. Now, like I said before, I'm all for readability, and solutions exist to improve it. But why should Wikipedia fix it for a small minority that can, and do fix it themselves? — Edokter • Talk • 11:00, 22 November 2010 (UTC)
We did it for the output of {{reflist}} during the move to Vector precisely because people complained about the font size, so it's hardly unprecedented. And again, when you've already got the likes of {{taxobox}} deployed with the larger font without too much grumbling, it's difficult to argue that people are really opposed to it. Chris Cunningham (user:thumperward: not at work) - talk11:18, 22 November 2010 (UTC)
That happened long before Vector. Still, it is the change that requires consensus when opposed. I'm just trying to keep a consistent look accross the project, and with everyone having diferent font requirements, it is a hopeless battle. — Edokter • Talk • 13:13, 22 November 2010 (UTC)
I know width in ems is a relative size, but a small increase won't hurt. At least is not as big as two years ago. And what do you mean with other templates needing to change? Which ones? --Locosepraix ~ Beastepraix15:21, 23 November 2010 (UTC)
Because it adds to the already growing list of different font sizes for different elements. Apart from the headers, there should ideally be only three font sizes; normal, big and small. We now have several degrees of 'small(er)' and 'big(ger)', and that does not help in maintaining a professional look. — Edokter • Talk • 23:18, 24 November 2010 (UTC)
Italic titles
I am contemplating merging the functionality of Template:Italic title infobox with this template as it is used by several highly-transcluded infoboxes now and it would seem to be a cleaner way to code it. Does anyone see any disadvantages of this? — Martin (MSGJ · talk) 09:38, 19 November 2010 (UTC)
Sure thing. Main other could be avoided, but I'm not sure I understand the concern of using meta-templates in the way they were designed. — Martin (MSGJ · talk) 12:30, 19 November 2010 (UTC)
How about something like this? It would allow the following functionality:
Turning on italic titles by passing |italic title={{{italic title|}}} from the infobox.
Turning off by default but allowing some instances to be made italic by passing |italic title={{{italic title|no}}}
Not making any titles italic by not passing the parameter at all.
Hey. Is it possible to add collapsible headers in infoboxes? For example, at this infobox, is possible to collapse the "Reservoir information" header, to display a [show]/[hide] link on the right of the header? Rehman07:44, 21 November 2010 (UTC)
Hmm, looks ah neat? How hard or damaging is it to "officially embed" such a feature in {{Infobox}}? Or is it nothing to do with this template, instead to do with the infoboxes that use this template? Rehman13:37, 22 November 2010 (UTC)
In this case, it was hardcoded in the article. Adding this to infobox is not trivial. A better solution would be to create a sub-template ({{Navbox collapsible header}}?), but even that requires extensive work in navbox itself. — Edokter • Talk • 13:57, 22 November 2010 (UTC)
Indeed. The basic problem is that the collapsing code is designed to collapse an entire table, not just individual rows, and there's nothing in this template's logic which connects individual rows with each other. Hacks like the one used in {{infobox athlete}} work well enough, but they're inelegant. Chris Cunningham (user:thumperward: not at work) - talk14:22, 22 November 2010 (UTC)
The current script for collapsible boxes is badly coded, not easy to reuse in different contexts, poorly accessible and has poor usability. I have two JQuery scripts for collapsible contents ready to be deployed and to replace the current scripts. They provide similar interface to the usability initiative's left side collapsible menu. If an admin is willing to deploy it, it could easily be added to infoboxes in a neat fashion. Dodoïste (talk) 17:42, 22 November 2010 (UTC)
You could make something similar work here, but some tweaks to this code would be required to make the cellpadding optional, if you want it to fit tightly. Plastikspork―Œ(talk)05:22, 23 November 2010 (UTC)
This is neat. How easy is it to get this into the infobox template? Is it possible to get it to the level where you could just enter a field Collapsible=yes into the header code? Rehman13:32, 23 November 2010 (UTC)
No. As I said above, building this into {{infobox}}itself is too much work; we would have to change every field to accommodate collapsing, which is disproportional to its use. This is best implemented on those infobox templates that want to use it. — Edokter • Talk • 13:38, 23 November 2010 (UTC)
Hmm. I really think we should work on adding the collapsible feature to {{Infobox}} though. Obviously doing it means work, as with any other change, but it would definitely help. If you meant modifying each of the ≈80 fields in "change every field", then I don't think thats too much work. Anyone else think this should not be done? Rehman06:31, 25 November 2010 (UTC)
It is slightly more complicated. And I'm against it too, unless you use an good collapsible script (not the current one). I've made an example of the new script I suggest to use at User:Dodoïste/Sandbox3. First add the linked scripts to your corresponding monobook/vector CSS/JS, clear your cache, and then test it. Dodoïste (talk) 13:42, 26 November 2010 (UTC)
I think the way to do this, if at all, is basically embedding an collapsible box inside of this one, which is how it being done right now. I could see making it possible to turn off cellpadding parameter, which would allow the embedded box to fit more tightly inside of the parent box. I agree that it would be less desirable to make major changes to this template, if you can achieve the same thing by other means. Plastikspork―Œ(talk)16:18, 26 November 2010 (UTC)
My reason for asking this is because the lengthy {{Infobox power station}} need to collapse some of its headers, and I am sure many other long boxes needs it too. If there is an better way to directly fit it "tightly" in to {{Infobox power station}} without changing any styles or anything, then I'd be happy to hear it. Reason why I want the change to take place here is because, it would make it easier for other infoboxes to collapse its headers with a simple parameter or two (right?), instead of going through the hassle to make more complex changes to each box that needs it. Rehman02:42, 27 November 2010 (UTC)
