Writers are conditioned to using tables. We are creatures of habit, and using tables in DITA seems to come naturally if you are used to writing in Word or FrameMaker.
Bottom line: When you need to present information that will be table-like when read, your default preference should be for definition lists.
We know that you are used to using tables. And love merging cells and doing all the cool stuff that oXygen Author and XMetaL Author can help you do with DITA tables. Get past it. Consider using definition lists wherever possible.
What’s wrong with tables in DITA?
Telling a technical writer to try and avoid tables is a bit like telling Genghis Khan to avoid conquering. It’s just what we do. This is true — but we want to get past it. Using tables in DITA is sometimes necessary, but often we can get ahead by avoiding use of tables.
Tables invite endless tampering with settings for column width. In most cases, get over it and get past it. Go for <dl>, definition lists.
The key point here is “most cases”. Most, but not all. If it’s absolutely critical that you display content (such as images and descriptive text side-by-side), and you don’t want to configure <dl> so that <dt> and <dd> display side-by-side in general, or if you absolutely must have a large number of columns, or if you need to merge cells. then go for tables.
Your next steps
A definition list sample — an alternative to tables in DITA
A sample definition list with a heading:
<dl> <dlhead> <dthd>Image File View Selection</dthd> <ddhd>Resulting Information</ddhd> </dlhead> <dlentry> <dt>File Type</dt> <dd>Image's file extension</dd> </dlentry> <dlentry> <dt>Image Class</dt> <dd>Image is raster, vector, metafile or 3D</dd> </dlentry> <dlentry> <dt>Number of pages</dt> <dd>Number of pages in the image</dd> </dlentry> <dlentry> <dt>Fonts</dt> <dd>Names of the fonts contained within a vector image</dd> </dlentry> </dl>