Help:How to use tables

Tables can be useful for a variety of content presentation on Cunnan. If you are familiar with the HTML code needed to create tables, you can simply insert the code directly into the article as you are editing. Table markup is often difficult to edit, however, especially for those unfamiliar with HTML. There are some situations where tables are inappropriate, and simpler markup should be used instead. This page discusses how to create tables in Cunnan articles, and when they are appropriate.

Example table

Cunnan code

<table border="1" cellpadding="2">
<caption>Multiplication table</caption>
<tr><th>×</th><th>1</th><th>2</th><th>3</th></tr>
<tr><th>1</th><td>1</td><td>2</td><td>3</td></tr>
<tr><th>2</th><td>2</td><td>4</td><td>6</td></tr>
<tr><th>3</th><td>3</td><td>6</td><td>9</td></tr>
<tr><th>4</th><td>4</td><td>8</td><td>12</td></tr>
<tr><th>5</th><td>5</td><td>10</td><td>15</td></tr>
</table>

What it looks like in your browser

Multiplication table

×	1	2	3
1	1	2	3
2	2	4	6
3	3	6	9
4	4	8	12
5	5	10	15

Use <tr> (table row) to begin new rows, and </tr> to end each row. For headings within the table (such as the "Album", "Year", and "Label" cells in the above example), use the table heading tag <th>, with a closing </th> at the end of the heading cell. For most cells, you'll probably be using the table data element, surrounded by <td> and </td> ("table data") tags. A caption is a succinct way to describe your table, and should go inside the caption element just after the initial <table> tag.

If your table doesn't look right, make sure that all of the HTML tags are opened and closed appropriately. See that all <tr> has a corresponding </tr>, every <th> has a </th>, and every <td> a closing </td>.

If you are already familiar with HTML tables, you may want to note that the thead, tbody, and tfoot elements are currently unsupported in Cunnan.

Another example

Here's a more advanced example, showing some more options available for making up tables. You can play with these settings in your own table to see what effect they have. Not all of these techniques may be appropriate in all cases; just because you can add colored backgrounds, for example, doesn't mean it's always a good idea. Try to keep the markup in your tables relatively simple -- remember, other people are going to be editing the article too! This example should give you an idea of what is possible, though.

Cunnan code

<table border="1" cellpadding="5" cellspacing="0" align="center">
<caption>'''An example table'''</caption>
<tr>
<th style="background:#efefef;">First header</th>
<th colspan="2" style="background:#ffdead;">Second header</th>
</tr>
<tr>
<td>upper left</td>
<td> </td>
<td rowspan=2 style="border-bottom:3px solid grey;" valign="top">
right side</td>
</tr>
<tr>
<td style="border-bottom:3px solid grey;">lower left</td>
<td style="border-bottom:3px solid grey;">lower middle</td>
</tr>
<tr>
<td colspan="3" align="center">
<table border="0">
<caption>''A table in a table''</caption>
<tr>
<td align="center" width="150px">[[Image:wiki.png]]</td>
<td align="center" width="150px">[[Image:wiki.png]]</td>
</tr>
<tr>
<td align="center" colspan="2" style="border-top:1px solid red; 
border-right:1px solid red; border-bottom:2px solid red; 
border-left:1px solid red;">
Two Cunnan logos</td>
</tr>
</table>
</td>
</tr>
</table>

What it looks like in your browser

An example table

First header	Second header
upper left		right side
lower left	lower middle
A table in a table Two Cunnan logos

When tables are appropriate

Tables are perfect for organizing any information that is best presented in a row-and-column format. This might include:

• Mathematical tables
  • Multiplication tables
  • Tables of divisors
  • Lookup tables
• Lists of information
  • Equivalent words in two or more languages
  • Person, birthdate, occupation
  • Artist, album, year, and label

Many times, a list is best left as a list. Some articles include excessively long lists which would be very difficult to edit if they were in table form. Before you format a list in table form, consider whether the information will be more clearly conveyed by virtue of having rows and columns. If so, then a table is probably a good choice. If there is no obvious benefit to having rows and columns, then a table is probably not the best choice.

Tables shouldn't be used simply for layout, either. If the information you're editing isn't tabular in nature, it probably doesn't 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 Cunnanns, and isn't really what tables were designed to do.

When tables are inappropriate

Very long lists, or very simple lists

If a list is quite long, or is relatively simple, use one of the standard Cunnan list formats. Long lists can be hard to maintain if they are inside a table, and simple lists are (simply) too simple to need the row-and-column format that a table provides. Here are some examples of things that might be better done with lists instead of tables.

Table formatting (Don't do this)

Year	Album
1980	Ultra Wave
1988	What's Bootsy Doin'?
1994	Blasters of the Universe
1994	Fresh Outta 'P' University

Without tables (Do this instead)

• 1980 - Ultra Wave
• 1988 - What's Bootsy Doin'?
• 1994 - Blasters of the Universe
• 1994 - Fresh Outta 'P' University

Layout of images

Many times, images in an article are placed using a quirk of table rendering. Because a table can be floated to the left or right side of the screen, it has become common practice to utilize a simple one-celled table to place an image in a particular part of the screen. This was a necessary workaround for old browsers, since it generates a consistent rendering of images in browsers which do not adequately support Cascading Style Sheets. By far, the majority of browsers in use today, however, should do just fine with style sheets. The recommended practice now is to arrange images using an element called div.

For detailed instructions, see Cunnan:Image use policy. Here's a brief example, though:

Table formatting (Don't do this)

<table align="right" border="0" cellpadding="0"><tr><td>[[Image:Wiki.png]]</td></tr></table>

Without tables (Do this instead)

<div style="float:right; margin: 0 0 1em 1em;">[[Image:Wiki.png]]</div>

How it looks

In both of these cases, the result is essentially the same; the image is floated to the right-hand side of the screen, and the surrounding text wraps around it. Here is what it looks like in your browser (with text added):

Covalent bonding most frequently occurs between atoms with similar electronegativities, where neither atom can provide sufficient energy to completely remove an electron from the other atom. Covalent bonds are more common between non-metals, whereas ionic bonding is more common between two metal atoms or a metal and a non-metal atom.
 
Covalent bonding tends to be stronger than other types of bonding, such as ionic bonding. In addition unlike ionic bonding, where ions are held together by a non-directional coulombic attraction, covalent bonds are highly directional. As a result, covalently bonded molecules tend to form in a relatively small number of characteristic shapes, exhibiting specific bonding angles.

Possible problems

Tables may cause other difficulties, even when used appropriately. Here are some issues you may want to consider if you use tables in your articles:

• Tables may be hard for other people to edit, especially for people who are new to Cunnan. New editors may be daunted if they click "Edit this page" and see a large block of unintelligible (to them) HTML code. Try to keep your tables simple, and well-formatted in the code.
• It is tricky, even for experienced HTML authors, to make sure that tables render correctly on all (or even many) web browsers. Even the slightest typographical mistake can cause drastic visual problems with the table. You may be confident of your abilities to prevent this from happening, but future editors may not be. Again, keep tables simple and well-formatted, and this is less likely to be a problem.
• Large tables, with lots of information, may run off the right side of the screen on lower resolutions. This is sometimes acceptable, especially if the user is warned beforehand (for example, Periodic table/Huge Table is deliberately very large). If you find it necessary to create a very large table for an article, you may want to consider creating a simpler, smaller version for users who cannot effectively use the larger version (for example, the periodic table is also available in a smaller version).
• If you include fixed-width text inside a table (using the HTML code, pre, or tt elements, for example), it may force the page to be wider than necessary. Whenever possible, avoid using fixed-width text inside tables, so the text can flow naturally. A similar problem can happen if you include images inside tables (since images are usually constrained to be a fixed width).
• Cells containing a great deal of information may cause rendering problems on some browsers. In particular, a cell containing a large paragraph may jumble the formatting on text-only browsers such as Lynx. This is often necessary, depending on what sort of table you're creating, but if at all possible, try to limit the amount of content you place in table cells.