Help: How to use tables

DCCWiki, a community DCC encyclopedia.
Jump to: navigation, search

Tables can be useful for a variety of content presentation on DCCWikipedia. Traditional HTML table markup is often difficult to edit, especially for newcomers. It has been replaced by a simplified wiki syntax.

For details on how to create tables on DCCWikipedia, see Working with tables .

Converting from HTML tables to wiki table syntax

This can be done automatically with several of the tools:

These tools converts tables from HTML online: cnic.org - wackyboy.com - uni-bonn.de - diberri.dyndns.org - pyDCCWikipediabot

NeoOffice / Open Office

Another method of working with tables is to use Neo Office. From the website:

NeoOffice is a full-featured set of office applications for Mac OS X. Created in 2003 when there was no Mac OS X version of OpenOffice.org available, Patrick Luby and Ed Peterlin have devoted their decades of Mac software engineering experience to create an office suite that is adapted to the unique needs of Mac users.

NeoOffice has the ability to export a file in mediawiki format. You can create, format and edit a table just as you would with a word processor, save it, then export it in the mediawiki format.

The result can be opened with a text editor, the content selected and pasted into the DCC Wiki. Instantly, a beautiful table.

There are free and paid versions available for download at the NeoOffice Home page.

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 very long lists which might be 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 DCCWikipedians, 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 DCCWikipedia list formats. Long lists can be hard to maintain if they are inside a table, and simple lists do not 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. An exception to this may be if the table would be an ideal candidate for having either column be sortable (see sorting tables below).

Table formatting (Don't do this)

1980Ultra Wave
1988What's Bootsy Doin'?
1994Blasters of the Universe
1994Fresh 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 DCCWikipedia:Image use policy and the DCCWikipedia:Image markup gallery. Here's a brief example, though:

Table formatting (Don't do this)

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

Without tables (Do this instead)

[[Image:Covalent.png|right]]

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.png

Covalent bonding is a form of chemical bonding characterized by the sharing of one or more pairs of electrons between atoms, in order to produce a mutual attraction, which holds the resultant molecule together. Atoms tend to share electrons in such a way that their outer electron shells are filled. Such bonds are always stronger than the intermolecular hydrogen bond and similar in strength to or stronger than the ionic bond.

Covalent bonding most frequently occurs between atoms with similar (high) electronegativities, where to completely remove an electron from one atom requires too much energy. Covalent bonds are more common between non-metals, whereas ionic bonding is more common between a metal atom and a non-metal atom.

Covalent bonding tends to be stronger than other types of bonding, such as ionic bonding. Unlike ionic bonds, 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 DCCWikipedia. 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. You might also add a comment (which won't appear in the rendered page) like "<!-- To edit the text of this article, skip past the table. -->" in order to reassure editors.
  • 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 (large version) 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.
  • In some browsers, tables which are right-aligned allow justified text to run right up to the edge of a border. This can look unsightly. One solution is to use style = "margin-left: 0.5em;" in the table header.