Wikipedia talk:Manual of Style/Tables/Archive 1

Example table
For something as simple as an album lsiting, I really think the following is more appropriate:

... etc
 * 1980 - Ultra Wave (Warner Brothers)
 * 1988 - What's Bootsy Doin'? (Columbia)

-- Tarquin 14:17 19 Jun 2003 (UTC)


 * I totally agree, actually... I used that mainly because it was a practical example, rather than the abstract "first heading/first cell" stuff that was there before. I wanted the first example to be simple, since it's introductory. If you could supply a better example that is equally simple, that would be great! Feel free to revise the "when tables are appropriate" section, also. -- Wapcaplet 16:37 19 Jun 2003 (UTC)


 * I put a multiplication table in for the first example. Seems like a better use of tables, and it's not overly complex (aside from the abundance of  elements). What do you think? -- Wapcaplet 16:48 19 Jun 2003 (UTC)

I disagree, album listings should be in tables.174.3.101.61 (talk) 00:32, 10 January 2010 (UTC)

I've revised the when tables are appropriate section.174.3.101.61 (talk) 00:32, 10 January 2010 (UTC)

End tags
Why does this page recommend using the end tags,   and  ? They are not required by the HTML 4.01 specification, and I don't know of any browser that needs them. They are the biggest cause of HTML errors in tables, because it's so easy to get one wrong. --Zundark 19:13 19 Jun 2003 (UTC)


 * Partly because the old section about tables (which used to be at How to edit a page) recommended using them; partly because the W3C, and other web standards bodies, in general recommend them, partly because they are required by XHTML 1.0, which Wikipedia may one day switch to (and it would be nasty if all the tables suddenly broke). Other reasons include: because I think it's a good idea; because it is less ambiguous and (IMHO) less error-prone; because some browsers do need them (in particular, tables without proper end tags seem to get messed up in Lynx, though I have not done much testing on it). I've seen no evidence to suggest that their usage causes additional errors; yes, it's easy to get one wrong, but it's just as easy to get any other HTML tag wrong, and in my experience it's easier to find (and fix) errors if the end tags are explicit. -- Wapcaplet 00:32 20 Jun 2003 (UTC)


 * I'm very surprised that you haven't seen any evidence to suggest that using unnecessary end tags causes additional errors in tables. I've fixed many HTML errors in tables on Wikipedia, and almost all of them were clearly a result of using such end tags. (However, I haven't tried to fix the tables used in chemical element articles. These tables have invalid  attributes, and this obviously has nothing to do with using end tags.) In any case, I've added a suggestion to check tables using the W3C validator - if people would do this (and do it again every time the table coding is modified), then their tables should be free of HTML errors even if they use end tags.


 * I don't think we need to worry about XHTML compatibility, because if Wikipedia converts to XHTML everything will have to be run through a conversion script anyway. For this reason I think the remark about XHTML in the article is misleading and should be removed. --Zundark 12:21 20 Jun 2003 (UTC)


 * Fair enough. I've removed the XHTML comment, and rephrased that section to better indicate the optional stuff. -- Wapcaplet 12:40 20 Jun 2003 (UTC)


 * Possibly the sample w/o the optional closing tags makes it easier to grasp. -- User:Docu


 * Wait. I don't get your question... Lemme see here.


 * "Why does this article suggest that closing tags such as,   and   should be used?"


 * Right? You seem to be suggesting that these should simply be left unclosed. That's pointless in my opinion, and using closing tags makes everything look more formal. :-) I'd rather have messy code be rejected than accepted. (In short: Go go XHTML!) --Ihope127 02:07, 10 August 2005 (UTC)


 * I don't know why you're replying to a two-year-old question, but anyway, the point I was making, as I had already explained, was that end tags were causing lots of invalid HTML, because people get them wrong so often. But things have changed since then. In particular, Wikipedia now has wiki markup for tables, so editors no longer need to mess around with HTML for tables. Also, the Wikipedia software now fixes some common mistakes in HTML/XHTML table markup before putting it in the output page, so getting the end tags wrong no longer matters as much as it used to. Of course, tables with lots of end tags are still hard to read (without syntax highlighting), especially if some of the end tags are wrong, but this is a relatively minor point. --Zundark 16:37, 11 November 2005 (UTC)

Images
I can't get the &lt;div&gt; thing for images to work right. It sizes itself to the text rather than to the image, which is understandable, but becomes a layout issue if I need to use a large caption. Instead, I've resorted to the use of tables with width= attributes, which have problems of their own. -Smack 20:54 19 Jun 2003 (UTC)


 * Ah, that is a good point. The only solution I know of for this is to explicitly set the  width, like so:




 * (Where the pixel width is equal to the width of your image). CSS also supports a "max-width", which would really be better (so the width could be flexible to a certain extent), but it doesn't seem to work in some browsers (namely MSIE). I will put a comment about this in the article too. Thanks! -- Wapcaplet 00:32 20 Jun 2003 (UTC)


 * What do the other parameter values mean? This really belongs in the Image use policy, maybe even the Boilerplate text. -Smack


 * Yeah, good point. And now that I check Image use policy, I see that it's already mentioned:


 * It seems like some browsers may need to have the explicit width of the image specified, i.e. width:250;, the inclusion of this specification is optional, but recommended if you have a caption longer than a few words. For large amounts of caption text, take out the text-align:center; to make it left-justified.


 * Wouldn't hurt to be more explicit on that point, though. As for the other parameters,  obviously causes the image to be floated to the right; the   parameters are a shorthand for ,  , etc., and are, in order, top/right/bottom/left (clockwise order). That could also stand to be mentioned somewhere, too. The "1em" specifies that the margin at that point should be one "font size" unit (something like 12 point with most fonts, but of course will be proportional to the font size that the user has chosen), and works in most browsers that I know of (except MSIE 3.0 which supposedly interprets it as "1 pixel", but who uses that anymore :) If you are interested in more info, the CSS2 Specification has probably more than you would ever want to know about the subject. -- Wapcaplet 10:24 20 Jun 2003 (UTC)

( moved from User talk:Docu )

In recent days I've been searching out and repairing broken table HTML, and I just noticed that you undid my repairs over at Berlin Film Festival. Removing all the closing tags from the table (&lt;/td&gt;. &lt;/tr&gt;, etc.) may make it seem nicer on the eyes when editing, but in reality that's not valid HTML anymore. Please leave the closing tags intact. Bryan
 * Bryan: Please discuss your changes first on Wikipedia talk:How_to_use_tables, otherwise leave tables intact as they are. Before replacing characters with their HTML named character entity, see Special characters. Both make it more complicated to edit pages. -- User:Docu
 * What's to discuss? Wikipedia talk:How_to_use_tables uses closing tags in all of its examples, and mentions that they're optional - meaning I can put them in if I want to without violating any of Wikipedia's standards. As for the special characters, they're recommended against only because of a bug in the current Wikipedia code that causes difficulty searching for them. The HTML tidy program I'm using automatically substitutes special characters, so I figured I'd leave them in where they occur. I'll take that eactue out of the Berlin Film Festival table, though, in the spirit of compromise; it's just lack of closing tags that I'm going about fixing. Bryan
 * I don't mind if you add them to tables you or someone else made, but I prefer that you leave them out from tables I made, it makes it more complicated to maintain them, if they are in. User:Docu


 * Alright, I'll quit nagging on this particular article - it makes no difference to the end user, after all, and it's largely just an aesthetic hangup of mine that motivates me on this. Bryan
 * It's just that eventually you may want to add them to List of capitals of subnational entities -- User:Docu

(/moved from User talk: Docu)

See also table
Moved from Village pump on Tuesday, July 8th, 02003.

I tend to disagree with what user:Mydogategodshat is currently doing. He has set a 6 links design, and is currently adding them to many articles. First the design is quite different from what is current practice. But more importantly, for some of the articles, it introduces links to articles that have nothing to do with the current topic. If such a practice becomes common, we are gonna find hundreds of links at the bottom of articles. I don't think it is very wise.

For example, he put this new design on the

similarly, I could set a list of six links about ecology, and put them there...till the point where we would have dozen of packages of six links. Here for example, I don't think that List of Marketing Topics is in any way relevant.

As I also told him, I also think it is not a good idea to introduce html code so liberally, as it makes the article edition more scary to non html-introduced people. I think that whenever possible, we should keep editing easy. The improvement does not appear to me so obvious that it absolutely require to introduce this.

I would be glad to have some feedback on this.

User:anthere


 * It's a table. It's grim. Change to a plain list if these lists are really necessary. -- Tarquin 16:16 5 Jul 2003 (UTC)


 * Agreed. These should be lists, if they should be there at all. See How to use tables (most of which I wrote, I admit, but it's all true, I swear). They're sort of like see-alsos, but aren't really always related to the article... hmm. -- Wapcaplet 03:16 6 Jul 2003 (UTC)

End moved discussion.

Editing should definitely be made easier for html ignorant people.174.3.102.6 (talk) 00:07, 4 December 2009 (UTC)

Alternative: Data objects
Most of the examples above could be handled by having a "data view class". This is not a short-term solution, though, nor will it cover all possible uses of tables. See my suggestion at http://meta.wikipedia.org/wiki/Wiki_markup_tables --AndrewKepert 01:31, 12 Sep 2003 (UTC)

I'd like to revisit the issue of div vs. table. It's clear the div syntax is easier on HTML neophytes, but I've run into so many image align problems with div on various browsers, especially IE on Macintosh, that I wonder if table might be easier and better in the end. Anyone else see this problem with div a lot? It seems to happen almost all the time on certain browser/OS combinations when the image should be aligning left or right amid wrapping text (the image will just sit there in the center). JDG 05:34, 18 Sep 2003 (UTC)

Other options

 * Possibility to convert CSV data to wiki-(HTML)-tables
 * Offer a series of choices in the stylesheets, instead of using, e.g. are much  easier to use. Given that the software supports both, Wikipedians should keep the choice. -- User:Docu


 * html is very hard to work with. When using html to make tables, it requires a lot of pasting, where wikitables are just fill-in-the-blank.  We should not use html.174.3.101.61 (talk) 08:39, 11 January 2010 (UTC)

about id&#61toc
from the Village pump

What's the meaning of id=toc of the table params (apears in Template:JanuaryCalendar and other tables). Guillermo 12:39, 4 Mar 2004 (UTC)


 * It applies the formatting defined in the style sheets, for the automatic TOC to the table. The CSS don't offer another selection of styles for tables. -- User:Docu

Table captions
Is it possible to get effect of the caption in wikicode? HTML equivalent of wanted result would be:

Note that Some caption appears without borders while the cells are bordered. This is how typical countries of the world are formated. --Romanm 19:28, 30 Mar 2004 (UTC)


 * Yep! Check out m:MediaWiki User's Guide: Using tables. -- Wapcaplet 02:07, 1 Apr 2004 (UTC)

Lack of explanation about width of columns
I'm feeling pretty grouchy about the fact that apparently it's not possible for me to set the width of the individual columns in a table. After screwing around for several hours with the tables, plus reading the so-called "help" over and over, I finally discovered that the columns readjust themselves in width according to how many letters are typed into one of the cells. Thanks a lot for making this so obvious to beginners -- I've only used spreadsheets for about 15 years now, and this is the first time I've ever seen one in which the width of the columns cannot be set to whatever figure I want it.

If I'm wrong about this -- and it's entirely possible, I admit -- then I wish someone would go to my new article Professional Tennis Championships and do a little editing so that I can see how the width of columns can be adjusted.

And, of course, someone can delete the paragraph I just inserted at the top of the Help article about tables....Hayford Peirce 03:37, 18 Jul 2004 (UTC)


 * You can specify cell widths. I've added a new section to the page explaining how. See How to use tables. Angela. 14:17, 21 Jul 2004 (UTC)

I've made this request elsewhere before, but is there any chance Wikipedia could allow sortable tables? There is some javascript code on the web which can be used to allow tables to become sortable (by clicking on a column header) if that would help. I think this would be tremendously useful for many sites (also for Wiktionary, etc.). Brettz9 15:54, 9 Aug 2004 (UTC)


 * I'm not sure where you have requested it before, but it doesn't seem to be at SourceForge, which is the only place developers are likely to see it. I suggest you add it there. Angela. 21:20, Aug 11, 2004 (UTC)


 * Excellent, thanks! [[User:Brettz9|Brettz9 (talk)]] 19:39, 12 Aug 2004 (UTC)

Table with solid borders?
How do you make a solid border table when global css is turned off and this doesn't work? 
 * This may be one way where an extra blank row (tr) is added: List of bridges by length

coloured columns
Is there any way (with the wiki-syntax) to make a whole column coloured (the way illistrated only makes one cell coloured)? The bellman 03:58, 2004 Nov 29 (UTC)

A new way to edit tables / Separate table namespace
(I've crossposted this a few times and received no response. Maybe this is the right place for a discussion?)


 * 1) I think tables should have their own namespace, as they are fundamentally different from articles and clutter up the markup.
 * 2) I have an idea for a new kind of editor specifically for the table namespace, to make tables more easily editable in the spirit of a wiki.

Please see the discussion on Proposal for intuitive table editor and namespace - Omegatron 15:29, 26 Jan 2005 (UTC)

Some Help?
Could someone please help me format the table on page: Ajhs?

Thanks, Mickeyreiss 01:20, 24 Mar 2005 (UTC)


 * What's the question? Noisy | Talk 08:01, Mar 24, 2005 (UTC)
 * I'm just trying to get that Table on top to look nicer. Mickeyreiss 21:56, 24 Mar 2005 (UTC)

Hello! My name is the Collector!





 * WHY!?! --Ihope127 15:50, 10 August 2005 (UTC)


 * Why not?  Said: Rursus   ☻   07:54, 9 July 2008 (UTC)

should this page be deprecated?
with a big bad link at the top saying to go to the meta page instead of editing this one? - Omegatron 20:26, Apr 12, 2005 (UTC)

Link to my Table: namespace proposal
I'd like to link to my Proposal for intuitive table editor and namespace as a potential solution to some of the things in "Possible problems" section, but I don't know if such links are really appropriate on style pages. Add if you think it's good. - Omegatron 13:54, May 17, 2005 (UTC)

even and odd CSS
Is there a way to implement even and odd CSS styles in the wiki table markup? Dread Lord C y b e r S k u l l ✎☠ 22:51, 2005 August 29 (UTC)
 * Here is the CSS for striped tables, with a minor color adjustment. This will work in Firefox, Safari, Chrome, Opera and Internet Explorer 9. Dread Lord CyberSkull ✎☠ 13:18, 12 March 2010 (UTC)

wikitable?
where is class wikitable defined? I looked at main.css and commonPrint.css but couldn't find it. dab (&#5839;) 10:55, 8 February 2006 (UTC)


 * Mediawiki:Common.css — Omegatron 17:32, 21 February 2006 (UTC)

Should this be renamed?
Should this article be renamed? It really seems to be more of a "Table use policy" than a "how to use tables". The laster suggests more of a technical how-to. Irrevenant 08:19, 30 March 2006 (UTC)

Needs more examples
This article is not very helpful for newcomers to Wikipedia and HTML tables.

It has a section entitled When tables are appropriate, which lists a lot of typical uses for tables, but gives no examples of how these uses can be implemented.

It has a section on When tables are inappropriate, and gives very nice examples of what not to do.

A newcomer generally comes to this section looking for advice as to how to edit a table. For that it would be very helpful if editors experienced in working with tables considered the various parameters used in designing a table (e.g, line type, line style, table location, column width, row height, line color, background color,...) and wrote up a brief discussion (with a clear explanation and an example) showing how each of these parameters functions.

Sorry if I sound cranky but I just edited a table, made a mess of it, and couldn't find the answers to my questions in either How to use tables or Meta:Help:Table. --SteveMcCluskey 17:33, 3 June 2006 (UTC)


 * What were your questions that you couldn't find answers to? — Omegatron 18:34, 3 June 2006 (UTC)


 * Thanks for the reply.


 * The main issue was the syntax for the opening section where the format of the table was set up and how to set line type and line style. whenever I try to insert them, everything else goes to hell in a handbasket, e.g, the table moves from the right side to the left.


 * If you want to see the table I'm working with it's at Talk:Atomism/Temp; the table I started with is at Atomism. I'd like to restore the lines framing the table and separating the rows and columns of the table -- preferably as thin hairlines.


 * --SteveMcCluskey 20:07, 3 June 2006 (UTC)

Help!
I'm utterly confused about how to make the kind of simple tables that are used on such pages as Homosexuality and religion. The coding text is so simple that it seems like it might be a template, since it seems to be linking to another page. Are these properly called tables, and how do you make them!?!? user:Whoistheroach
 * The tables on the page you mentioned are in fact templates, but Help:Tables has a guide on how to create tables using wiki markup which can be simpler and cleaner to use than html. -- Daduzi  talk  09:03, 4 August 2006 (UTC)

"Table formatting (Don't do this)"
What is the preferred wiki way (if any) for "named lists". I basically want to have something which looks like this (where G1, G2, G3 could for example be the standard names for specific axioms in mathematics):

This was created with a two-column table, which appears to be recommended against on When to use tables. Something similar to this can be done with a definition list, like this:


 * G1. : Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
 * G2. : Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
 * G3. : Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

But this looks ugly if the "defined terms" are very short and also conceals the enumeration character of the list.

The recommended way on this Wikipedia appears to be to use bulletted lists, like this:


 * G1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
 * G2. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
 * G3. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

But this again looks ugly to me. &mdash; Tobias Bergemann 10:37, 6 September 2006 (UTC)


 * It was just a recommendation. Use your common sense: the table looks better, then use a table!  Said: Rursus   ☻   07:56, 9 July 2008 (UTC)

Tables defaulting to white
Does anyone know why tables are now defaulting to white if you don't declare a style="background-color:#xxxxxx"? It has made me had to fix a lot of problems on my userpage! I much prefer the old behaviour where tables not having the code style="background-color:#xxxxxx" default to transparent. --tgheretford (talk) 11:10, 13 October 2006 (UTC)

"Make Table" template
Hey guys, I made a template the other day to prompt where a table needs to be made when you can't be stuffed. the template is make table. Hope you like it. Hope you use it. It adds to a category, so if you feel like creating tables, you can check out the category and create for any that are there (there's none as I type this, mind you, since the category and the template are both new). -- linca linca  15:19, 8 June 2007 (UTC)

Cell alignment
Is there any policy against the use of the "style=text-align:center" tag? This article does not necessarily imply that (I believe only the use of standard HTML tags such as


 * Proposed version markup:


 * Current version markup:


 * Reasons for change:


 * As you can see, wikimarkup is more robust and integrated with the other wikimarkup in formatting then the html. (Specifically, the "::" makes the html change the appearance of the html table where as "::" does what we want with the wikimarkup.)
 * With html, the formatting is lost when we indent (using the colon, at the start of a line (":")). In our illustrated case, the boarders are lost.
 * Wikimarkup is simpler and easier-to-use.
 * Help:Table says "All three are supported by MediaWiki and create (currently) valid HTML output, but the pipe syntax is the simplest.".
 * According to When_to_use_tables, it says html should not be used when wikimarkup is available.


 * Regarding my elaboration:


 * The toolbar is not unlike a toolbar that you find in many office programs. In wiki, the toolbar is located above the edit window.  This toolbar is composed of squares with background swagways from the top in a light blue to a darker blue descending.  In the foreground are graphics:
 * The first one on the left shows a capital "B" in times new Roman in bold (Boldface). Clicking on this square will insert Bold text with "Bold text" highlighted.
 * The second one from the left shows a capital "I" in times new Roman in italics. Clicking on this square will insert Italic text with "Italic text" highlighted.
 * I can go on and on but if you need more clarification, please do not hesitate to ask.


 * With all this in light, we can understand why having the table function in the toolbox can encourage users to use tables:
 * What I mean is not to OVERUSE them, but many editors do not know HOW to use them.
 * It is easier to use a table that is easy at hand; thus using this function in the key on the guideline is an example of using them on pages.
 * Help:Table says "All three are supported by MediaWiki and create (currently) valid HTML output, but the pipe syntax is the simplest.".
 * According to When_to_use_tables, it says html should not be used when wikimarkup is available.


 * I looked back when I was mentioning merging ("The reason I used merge was so it can help demonstrate the use of merge."). That was totally a mistake on my part.  I should have took that out.  No cells in my table were merged ("If you use single bars, then what might appear to be the first cell is in fact a format modifier applied to the cell, and the rest of your "cells" will be merged into one:" I don't know how to use the :wb so this will have to do).174.3.102.6 (talk) 19:29, 28 November 2009 (UTC)


 * I waited a day or two before commenting again, as this really isn't something that interests me a lot... but since no one else is commenting I may as well continue to say what I think....
 * Sure; switching this example to the wikitable format is a good idea; not that it makes much difference. The page will still look the same, but it will use the same table coding that it recommends, which is more consistent. Good idea. &mdash;Duae Quartunciae (talk · cont)  06:07, 2 December 2009 (UTC)

Regarding Additional Clarification
"Also, when compared with computer-/wikisyntax, computer-/wikisyntax is more flexible, easier to use, and less exoteric than tables when used for desktop publishing/page elements and page orientation & page positioning."

This helps to explain and clarify the use of tables: when not to use them, comparing easier modes of markup, and explain disadvantages of page design when using tables by using comparisons with code.


 * Just to be clear; the first paragraph above is a sentence you propose to add to the guideline. The phrase "computer-/wikisyntax" is not an established term. The proposed sentence mixes up the syntax used for tables with the idea of tables themselves.


 * The existing section on syntax for tables in the guideline reads as follows:

Table Coding — Reduce clutter

Where a table is genuinely necessary and desired, use the preformatted  class="wikitable"  format, or one of the related formats, instead of manually coding a complex HTML table directly in the article. This will make the table, and the article itself, much easier for other people to edit in the future.


 * This uses the more standard term for the preferred syntax: "wikitable". I think it could be useful to add a link to Help:Tables, which goes into a fair amount of background on the syntax of wikitables. I've personally found this a useful resource. The heading of this section might be better as Recommended table syntax. &mdash;Duae Quartunciae (talk · cont)  02:44, 25 November 2009 (UTC)


 * I agree with this Name change. But according to the content of the section, and having the usage of table established in above sections, the phase "Where a table is genuinely necessary and desired," needs to go.174.3.102.6 (talk) 19:59, 28 November 2009 (UTC)


 * How do you feel about this change:


 * "Also, when compared with wikimarkup, wikimarkup is more flexible, easier to use, and less exoteric than tables when used for desktop publishing/page elements and page orientation & page positioning."?


 * The other alternative is


 * "Also, when compared with wikisyntax, wikisyntax is more flexible, easier to use, and less exoteric than tables when used for desktop publishing/page elements and page orientation & page positioning."


 * Please comment.174.3.102.6 (talk) 20:04, 28 November 2009 (UTC)


 * I feel it is much better as it stands, using the proper term wikitable for the syntax in question. &mdash;Duae Quartunciae (talk · cont)  06:07, 2 December 2009 (UTC)


 * I'm a little confused: How do you like "Also, when compared with wikimarkup ... " or "Also, when compared with wikisyntax ... "?174.3.102.6 (talk) 23:45, 3 December 2009 (UTC)

Regarding Deleted Redunancy
", and is not really what tables were designed to do"


 * According to wp:guideline, it says that guidelines "should ... emphasize the spirit of the rule. Verbosity is not a defense against misinterpretation. Be unambiguous and specific: avoid platitudes and generalities.".
 * With the addition of "Also, when compared with computer-/wikisyntax ... ", we no longer need this text because "Also, when compared with computer-/wikisyntax ... " already explains it's use of tables, offering alternatives to tables.
 * According to wp:guideline, it says that guidelines "should ... emphasize the spirit of the rule. Verbosity is not a defense against misinterpretation. Be unambiguous and specific: avoid platitudes and generalities.".


 * Again, you are not clear about what you are proposing. Be specific. For example, "I suggest deleting the following phrase:" following by the phrase you want to delete. However, I don't think there's a problem here. The full paragraph in the existing guideline is as follows, with the disputed phrase in bold:

Tables should not be used simply for layout, either. If the information you are editing is not tabular in nature, it probably does not belong in a table. Try not to use tables for putting a caption under a photograph, arranging a group of links, or other strictly visual features. It makes the article harder to edit for other Wikipedians, and is not really what tables were designed to do.
 * I don't see any problem with the phrase; it helps underline that this is not what tables are really designed to do, which is a good reason for not using them in this instance. It is a useful phrase to retain in the guideline. &mdash;Duae Quartunciae (talk · cont)  02:52, 25 November 2009 (UTC)
 * It is useful, but the issue is not the issue of the design of tables, it just has to do with what tables are used for. Table can really be used for formatting, but because there are other ways of formatting, that will be easier for editors that are not as well acquainted with html, the addition of this phrase is moot.174.3.102.6 (talk) 20:12, 28 November 2009 (UTC)


 * Since it is useful, it should be retained. My feeling on this phrase remains as I have given, for the reason given. &mdash;Duae Quartunciae (talk · cont)  06:07, 2 December 2009 (UTC)


 * But the design of the table (whatever it may be, weather true or false), the history, the origin of tables, has nothing to do with the application of tables.174.3.102.6 (talk) 23:48, 3 December 2009 (UTC)

Regarding Deleted Redundant Sentence
"If the information you are editing is not tabular in nature, it probably does not belong in a table."


 * According to wp:guideline, it says that guidelines "should ... emphasize the spirit of the rule. Verbosity is not a defense against misinterpretation. Be unambiguous and specific: avoid platitudes and generalities.".
 * Because of the addition of "Also, when compared with computer-/wikisyntax ... ", we no longer need this sentence.
 * Per "This helps to explain and clarify the use of tables ... ", it explains when and, in those cases, why tables should not be used.
 * According to wp:guideline, it says that guidelines "should ... emphasize the spirit of the rule. Verbosity is not a defense against misinterpretation. Be unambiguous and specific: avoid platitudes and generalities.".
 * According to tabular, it defines "tabular" in English as:


 * 1) having a flat, plane surface
 * 2) organized as a table or list
 * 3) calculated by means of a table
 * 4) (geology) tending to split into thin flat pieces, such as slate

Only Sense 2 and Sense 3 applies to our casehere. Both of these definitions are great. These definitions are very applicable but in an article discussing when to use tables, it is not very helpful.
 * This guideline page does not define the word "tabular" for the purpose of using tables.
 * This lends confusion to readers, and editors when when applying this guideline.
 * In a page discussing when-to-use-tables, it is confusing and contradictory when it is ruled that a table should not be used when it is not in a table.
 * Nifboy says "Well yes, data that naturally fits into a table should be tabled ... ". This would be helpful if parameters were set, i.e.: when tables should be used.
 * His argument is circular.
 * Nifboy says "Well yes, data that naturally fits into a table should be tabled ... ". This would be helpful if parameters were set, i.e.: when tables should be used.
 * This argument is circular.174.3.102.6 (talk) 10:01, 23 November 2009 (UTC)


 * You are apparently proposing to delete the sentence quoted in the start of this section. The claim of circularity is false; it is entirely possible to have information that is tabular in nature, but which is expressed in other formats; or information that is not tabular in nature and is expressed as a table. There are already examples in the guideline of where tables are using for data or information that is not tabular in nature; as in the cases where you try to use a table in order to add borders or floating or captions. There are better ways to do all these things. The sentence is in fact a key part of the existing guideline; tables should be used when the nature of the information is intrinsically tabular; and not simply for a way to get visual effects or a way of adding certain layout rules.


 * The guideline is not a formally prescriptive phrase which can be unambiguously define what is and is not information that is tabular. This is appropriate for a guideline. The key point is that you should be looking at the nature of the information itself, and whether it is naturally arranged as information in rows and columns.


 * This is a very important sentence in the guideline, and it is weird that you call it circular. As Nifboy correctly points out, it is no such thing. The sentence should be retained. &mdash;Duae Quartunciae (talk · cont)  03:01, 25 November 2009 (UTC)


 * Ok, I understand now: I have one small retrospective proposal. It is just a change of punctuation:


 * "... belong in a table. Try not to use tables for ..."


 * to


 * "... belong in a table: Try not to use tables for ...".174.3.102.6 (talk) 20:20, 28 November 2009 (UTC)


 * That is inferior punctuation. The guideline reads better as it stands. &mdash;Duae Quartunciae (talk · cont)  06:07, 2 December 2009 (UTC)


 * Can you please explain why that is "inferior punctuation"? As it now stands, I do not agree with these two sentences, because the 1st sentence (" ... belong in a table.") does not have a relationship with the 2nd sentence ("Try not to use tables for ... ").174.3.102.6 (talk) 23:34, 3 December 2009 (UTC)


 * No. I do not think it helps to have endless explanations or demands for further justification of everything you disagree with. If there was any indication that anyone else agreed with you, it would be different. As it stands, I am content to give this as my personal subjective judgment on good writing. &mdash;Duae Quartunciae (talk · cont)  23:44, 3 December 2009 (UTC)

Clarificantion
Please decide on ==Guideline Cleanup==.174.3.102.6 (talk) 10:35, 23 November 2009 (UTC)

Deletion
"', and is not really what tables were designed to do.' (own emphasis)"

When was this decided? This needs to be go. Failing that, "were" needs to be tagged citation needed, failing that, when.174.3.102.6 (talk) 00:02, 4 December 2009 (UTC)

Punctuation Proposal
"... belong in a table. Try not to use tables for ..."

to

"... belong in a table: Try not to use tables for ...".

Rationales

 * "Try not to use tables for ... " is an expansion of the previous sentence.


 * According to Wikipedia style manual: "Sometimes, more in American than British usage, the word following a colon is capitalized, if that word effectively begins a new grammatical sentence, and especially if the colon serves to introduce more than one sentence.".
 * This is an Amereican article
 * According to Colon (punctuation): "In English, a colon may be followed either by a capital letter or by a lower case letter, depending on usage.".


 * Thus, both cases accept the camel case in the sentence.174.3.102.6 (talk) 20:03, 4 December 2009 (UTC)

"wikisyntax" or "wikimarkup"
What is more appropriate:

"Also, when compared with wikimarkup, wikimarkup is more flexible, easier to use, and less exoteric than tables when used for desktop publishing/page elements and page orientation & page positioning."

or

"Also, when compared with wikisyntax, wikisyntax is more flexible, easier to use, and less exoteric than tables when used for desktop publishing/page elements and page orientation & page positioning."

?174.3.102.6 (talk) 00:34, 25 December 2009 (UTC)


 * Neither is appropriate. Wikisyntax redirects to wikimarkup, so presumably the latter is preferred. In either case, though, the proposed wording is unacceptable: "when compared with wikimarkup/wikisyntax, wikimarkup/wikisyntax is more flexible..." is virtually nonsensical because it's comparing something to itself. Also, exoteric is not a word. Rewrite pending... gimme a sec and done. I changed the sentence to read: "Also, when compared with tables, wikimarkup is more flexible, easier to use, and less esoteric when used for desktop publishing, page elements, and page orientation and positioning." If this obscures the intended meaning in any way, please advise. Rivertorch (talk) 07:02, 7 January 2010 (UTC) (via RFC)


 * Oh, thanks. I missed "esoteric".  It was something that I had wanted to changed.  Forgot about it because noone would comment.174.3.101.61 (talk) 02:14, 9 January 2010 (UTC)

More undiscussed changes
This is horrible. The guideline has become a mess. To take one example, why the heck is there any mention of CCS??!!&%# This is wikipedia, not an html tutorial. We don't HAVE ccs. Sheesh! There's a lot more that's degraded the guideline as well. Does anyone else think the undiscussed changes have for the most part made this guideline much worse? &mdash;Duae Quartunciae (talk · cont)  16:47, 10 January 2010 (UTC)


 * Can you explain the why CCS should not be included/how is CCS atopical to this page? I haven't changed any policy related text.  I've only changed the placement of sections, naming of sections, and if you are concerned that it was an html tutorial, I took out that irrelevant information as well.174.3.101.61 (talk) 21:44, 10 January 2010 (UTC)


 * The policy verbatim established above in this talk page has not changed.174.3.101.61 (talk) 21:45, 10 January 2010 (UTC)


 * The IPs edits have been reverted. No idea what they are up to, but their changes go completely against actual community consensus. -- AnmaFinotera  (talk · contribs) 05:42, 11 February 2010 (UTC)


 * Community consensus ≠ consensus on this page.174.3.98.236 (talk) 07:30, 11 February 2010 (UTC)

Content


"**match the table contents;": "**not be too narrow or too broad;"
 * I have seen the headings of rows and columns not match the contents of the cells, or the cells have information, that would seem unrelated to the title of the table, row, or column. This should be included.  If you need examples, ask.
 * Some titles (of tables, rows, or columns) are too long and become irrelevant to the table.

cf.: Mos

This is a guide to writing, and specifically, naming, articles and sections. Tables are similar: It's table name, rows, and columns name the contents on its table, row, and columns, respectively.174.3.98.236 (talk) 23:49, 9 February 2010 (UTC)


 * If you feel those points should be taken out, I'll leave them be.174.3.98.236 (talk) 01:07, 10 February 2010 (UTC)

Guideline Conflation
A discussion about the conflation of lists, stand-alone lists, embedded lists, and WTUT is occuring at Village_pump_(proposals). If you decided to contribute please contribute there.174.3.98.236 (talk) 23:58, 10 February 2010 (UTC)

Moving
This page needs to be moved to Tables, or Manual of Style (tables). I'm not sure which one.174.3.98.236 (talk) 04:54, 11 February 2010 (UTC)

174.3.98.236 (talk) 08:12, 11 February 2010 (UTC)
 * From " " to "  "
 * User friendlyness.
 * Addition of "==Format==[line break]There are 2 table formats:[line break]*sortable tables[line break]*unsortable tables (this includes tables with merged cells)[line break][line break]The reason there is a clear division between these two types of tables is because even when just 2 cells are merged in any direction, the table becomes unsortable.[line break][line break]*There are tradeoffs for both formats, so use the one that:[line break]**conveys the most information[line break]**is the most clear
 * Harmonizing article with other wikipedia article
 * Guidance to use when choosing the format to use
 * Removal of " and"
 * Clarity
 * Delinking sortable
 * Included in the hatnote
 * "a, an, or the" to "a, an, or the"
 * If the template changes, the text does not get altered.
 * html to wiki
 * Established on talk


 * Reverted yet again. You should not be making all of these changes that have absolutely no consensus and when you clearly disagree with the usage of the term lists on Wikipedia and are arguing that all lists be deleted, including tabled lists, in other places. -- AnmaFinotera  (talk · contribs) 14:27, 11 February 2010 (UTC)


 * There are some agreements with the points
 * I did not argue to have tabled lists deleted. That was the beginning of a discussion.
 * I am not arguing to have all lists deleted.174.3.98.236 (talk) 04:22, 12 February 2010 (UTC)
 * Yes, you did. "we really need to get rid of lists for all and for once" That is an argument to delete ALL lists, and then you argued specifically against lists that are "tabled" claiming they aren't real lists. You've already been blocked once, and your filing a "30" without bothering to reveal that you were blocked by administrators for your edits is not showing any well meaning behind your cross page attacks on lists. -- AnmaFinotera  (talk · contribs) 07:09, 12 February 2010 (UTC)


 * Although it is an argument to delete all lists, you still have yet to prove that I made even one vandalizing edit. Your vitriolic language and edits are in bad faith.174.3.98.236 (talk) 07:44, 12 February 2010 (UTC)

Third opinion
I came here due to a request posted on Third opinion. Here goes:

The third opinion plea referred to WP:DRNC. This is an essay that doesn't have the weight of a policy or a guideline. Anyone can write an essay on any subject. Someone can just as easily write an essay in opposition to WP:DRNC.

Official Wikpedia guidelines such as Manual of style and associated child articles such as this one became official guidelines through consensus. While editors are encouraged to be bold in articles, official Wikipedia documents that serve to govern how all editors work on Wikipedia are another matter. One should not unilaterally make a substantial change to an official guideline. The proper way to make a change to such a document is to propose the change on the talk page.

The changes have been proposed, above. That's good. Making those changes unilaterally without prior discussion isn't. ~Amatulić (talk) 06:57, 12 February 2010 (UTC)

Should entries in a table be capitalized?
I get that we want the headers in sentence case, but what about entries? For instance if the header is "Color", should the entries be "Blue", "Green", or "blue", "green". And would it make a difference if I had sentence or sentence frag or two part noun entries (e.g. "chef's knife" or "Chef's knife"). Double super extra credit if the answer actually refers to how things are done in the real world and is not just a how we do it on wiki. Minus points if the answer is not even at that level and is a "what I like" form. (pardon flippancy, long day of writing wiki articles). TCO (talk) 03:53, 23 January 2011 (UTC)