Working with tables

Tables should be used for storing tabular information, and not to achieve formatting outcomes.

The principle of the separation of content and form reaches a stumbling block when it comes to tabular information and tables. Tables are both a content structure and a presentational form construct. The content of a table is a set of data organised into rows with a common structure. The form of a table is its column and row widths, its borders, its padding, etc.

As a matter of principle, a DITA topic shouldn't be storing any information about how any content is presented. However, there is a need to specify some formatting information that is specific to an individual table, and that cannot be applied automatically during the publishing process. DITA does therefore include the capacity to store some formatting information alongside content in table elements. When content and form are bound together in this way, re-use of the content becomes more difficult. For example, if I specify that a table should be 25 cm wide, the topic containing the table can't be easily output to a page or column narrower than 25 cm.

For this reason, tables should be treated carefully. They should be avoided where there is no loss of meaning, they should never be used as a formatting device alone, and any unavoidable formatting information should be kept to a minimum.

DITA's table content model is based on the OASIS interchange form of CALS tables. It is not possible to create a table specialisation with a footer based on the thead element, because the underlying content model specifies that a table can only have a thead then a tbody, and not two thead elements or two tbody elements.

In addition, there is a rowheader attribute (of the table element) that nominates whether the first rows contains heading information; this is arguably content metadata rather than form.

DITA does not support table footers.