Template talk:Infobox

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Netoholic (talk | contribs) at 21:12, 31 January 2006 (→‎Conditionals). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Jump to navigation Jump to search

Documentation

Examples

{{Infobox}}


{{Infobox
|name=
|image=
|caption=
|data1=
|data2=
|data3=
|footnotes=
}}


null.png
An example image
data1
data2
{{Infobox
|name= Name
|image= null.png
|caption= An example image
|data1= data1
|data2= data2
|data3= 
|footnotes= footnotes
}}


null.png
An example image
data1
data2
data3
{{Infobox
|name= Name
|image= null.png
|caption= An example image
|data1= data1
|data2= data2
|data3= data3
|footnotes= footnotes
}}

Discussion

HiddenStructure

The hiddenStructure CSS hack has been clearly shown to not work for Lynx, screen-readers for the blind, templates copied to other language wikipedias (where the corresponding style-sheet has not been set up), and other situations. I see no logical reason to continue promoting a bad design. The more pages use this hiddenStructure method the worse Wikipedia will appear to users for whom it does not function. We should be working to limit and undo the damage rather than actively spreading it. --CBD 17:29, 29 January 2006 (UTC)[reply]

Indeed. Use template:qif which produces decent html until we have conditionals in MediaWiki, as expressed by Brion on WP:AUM. There is no good reason to break screen readers on thousands of pages (for which this template is an example to learn from). --Adrian Buehlmann 18:58, 29 January 2006 (UTC)[reply]

I can see the Lynx reader argument. However, the if structure is really messy and hard to follow in general - so I think the hiddenstructure should be used on this example template. This seems to me to be the best solution for "forward compatibility" since the programmers of both Wikimedia and Lynx can use the css designation to fix the problem for users of sreen-readers for the blind. Going back and changing all the existing templates is another (IMO, more complicated) issue. But it seems clear that we should give instructions to users on what generally works now and what will not need to be changed soon. Trödel•talk 19:31, 29 January 2006 (UTC)[reply]

I'm sorry, but I don't get it. Why use something that 'generally' works over something that actually works? CSS works for alot of people... but not everyone. QIF, '|if=', and other wiki-markup methods work for everyone. I don't understand what you are saying about 'forward compatibility'... at some hypothetical future point hiddenStructure may actually work for everyone so we should use it now? Not knowing what the future holds it is impossible to say what will actually be 'forward compatible' but it certainly seems far more likely that what works now will work in the future than something which doesn't work currently.
As to the 'messiness' of QIF... I don't find it so, but it could actually be made exceedingly simple. There is no reason conditionals couldn't be handled with calls of the form: {{if|{{{parameter|}}}|Text to print if 'parameter' is non-blank}}. Far simpler than the equivalent: <div class{{{parameter|}}}="hiddenStructure">Text to print if 'parameter' is non-blank</div>. I've been sticking to QIF because most people say it isn't confusing and they prefer it. --CBD 19:48, 29 January 2006 (UTC)[reply]
I must admit to some confusion - CSS doesn't work for some - then how are they browsing the internet in general? This is what I thought the problem was - class ="hiddenstructure" ends up not hiding the structure for Lynx browsers so they have to skip over the text that shouldn't be there - which I acknowledge as annoying.
By forward combatible I mean that the class="hiddenstructure" tags the information in some way that the browser, or the server could be use to hide that information from display to the user. Since the information to be "hidden" is clearly identified through a tag, it can be resolved without editing it again. If on the other hand one uses {{{if templates that are going to be depricated, then every template that uses them going forward will have to edit. Therefore, we should 1) discourage the use of conditionals until a real mediawiki solution is available, and 2) tag them so that they can be programattically excluded rather than manually edited after a solution is available.
However, I see how {{if|{{{parameter is easier to implement for the creator of the template, but since most infoboxes use tables, the <div </div structure is not necessary - only the addition of a style to the row. And to implement something that "works" for all users but requires that every use be edited in the future is less efficient, than avoiding the use or using something that can easily be identified and filtered out programmatically or manually. Trödel&#149;talk 20:43, 29 January 2006 (UTC)[reply]
Non-CSS browsers and screen-readers generally just ignore unrecognized tags. For the most part that means that they lose formatting details... font sizes, colors, double line vs single line borders, text alignment, et cetera. However, in most cases these things aren't particularly important... a blind user doesn't really care whether the text is vertically aligned to the top of the cell. Thus they can 'browse the internet' just fine. The exception are the 'display: none' and 'speak: none' values set by hiddenStructure on English Wikipedia (but not other language Wikipedias which frequently copy our templates - and now find them not working). These are meant to suppress the indicated text, but when CSS is ignored the text is simply displayed... so instead of not getting a font style which isn't particularly relevant they get extraneous text, brackets, punctuation, et cetera. As opposed to using wikipedia parameter switch methods (whether by 'qif', '|if=', or some other form) the information is sent correctly for everyone.
I still don't understand how 'hiddenStructure' is more forward compatible than 'qif'. For one you assume that 'qif' will be deprecated... I can only see that happening if some built-in conditional functionality is developed. However, every method of such suggested thus far would require 'hiddenStructure' to be removed/replaced just as much as 'qif' or any other method. Using a 'tag' format vs a 'template' format doesn't make the templates any more easily updated to whatever future hypothetical replacement there might be. If we were to suppose that a built-in replacement would soon be available and that it would be easier to convert 'hiddenStructure' to that method than 'qif' then maybe it would be ok to continue to disenfranchise users for a short time... but I don't see any evidence that either of those things are true. We have the situation in front of us... and presently 'qif' works and hiddenStructure doesn't. --CBD 21:09, 29 January 2006 (UTC)[reply]
Foreign language use of english templates. Since any admin can edit MediaWiki:Common.css or for another language es:MediaWiki:Common.css, fr:MediaWiki:Common.css, dk::MediaWiki:Common.css, nl:MediaWiki:Common.css etc., I don't see why they can't just fix the issue quickly by bringing the common.css file up to date. Breaking for some users: (are blind users the only ones affected?) we should decide based on some measurable criteria - using something that may hurt server load so that users of specific browsers aren't effected needs to be evaluated by looking at how many users are effected? is the server load really effected? by how much? how many templates are involved? what is the impact for the effected users? is there a easy workaround? In the meantime we should, IMHO, remove all reference to the use of hiddentext or if in the example template and not encourage its use until a real mediawiki solution is available. Trödel&#149;talk 21:40, 29 January 2006 (UTC)[reply]
We have a solution that works perfectly well. It's called qif and produces decent html, the same html we would produce if we had conditionals in MediaWiki. What's not optimal with qif is that it is not efficient. But it is not that ineffiecient to the extent that we must say: yes it is intolerable to use it until we have conditionals in MediaWiki. Why make an extra trip in creating bad html and possibly damage the reputation of Wikipedia only because we fear an abstract non-proven claim that qif hurts the servers? If we do not play araound editing qif every half-an-hour then I see no danger to wikipedia at all. In fact it serves damn well as a intermediate solution until we have conditionals in MediaWiki which will be trivial to do (once there is consensus on the devs how to do it). I do not think that anybody still believes we will never have conditionals built into MediaWiki, do you? --Adrian Buehlmann 22:10, 29 January 2006 (UTC)[reply]

The intent of this basic example template is for users who are not template wizards. Both developers that have commented on WP:AUM have said to avoid meta-templates, so it is not at all appropriate to introduce them to new template creators. Anything used incorrectly is bad, but Wikipedia:hiddenStructure describes the appropriate minimalist usage. -- Netoholic @ 03:31, 30 January 2006 (UTC)[reply]

No, that is untrue. Brion said to avoid meta-templates if they are hard to understand and/or fragile... both of which apply far more to 'hiddenStructure' than they do to 'qif'. The 'hiddenStructure' method does not work... and thus all applications of it are "used incorrectly". --CBD 11:54, 30 January 2006 (UTC)[reply]

Conditionals

As the point of this template appears to be to demonstrate good practices for template newbies, I think it's important that {{qif}} be shown as one of the examples. —Locke Coletc 21:02, 31 January 2006 (UTC)[reply]

Your idea presumes that any conditional rows in an infobox is a "good practice". It seems that may not be the case, and I have trouble seeing any consensus being reached as to which conditional method to standardize on. Let's avoid that headache on this page. -- Netoholic @ 21:12, 31 January 2006 (UTC)[reply]