Empty cells in HTML tables

Empty cells in tables often cause problems to HTML authors, especially since browsers often display such cells without border even if the other cells have borders. There is an often-mentioned trick to solve that problem: put   into an empty cell. Although it works, there can be better ways in many cases, indicating what emptyness really means in a particular cell. For example, in statistics there are conventions for presenting different kinds of missing data.

The problem of no borders around an empty cell

Frequently people ask questions like the following:

I need to make tables which contains some empty fields. But there are no borders around empty fields, only around fields with a content, even though I use <TABLE BORDER=1>. What can I do?

As a trivial illustration of the problem, consider the following simple two by two table element with the last cell empty (on the left) and the way your browser displays it (on the right):

<table border="1" bgcolor="#ffcc99">
<tr> <td>foo</td> <td>bar</td> </tr>
<tr> <td>zap</td> <td></td> </tr>
</table>

The example above may illustrate another phenomenon too: a browser could also suppress the use of a background color for the cell, even when it otherwise follows the author's suggestion for a background color for the table. The same may apply to a background image too. The example above uses the deprecated bgcolor attribute; but similar things may happen when style sheets are used for such purposes.

The usual trick:  

The usual trick is to put   (which is a so-called escape sequence, or formally entity reference, for a character called no-break space) into a table cell.

That is, instead of writing
<td></td>
you would write
<td>&nbsp;</td>

This seems to work rather widely, and it is not known to have caused problems, and it syntactically conforms to the specification of HTML. It was even mentioned in the HTML 3.2 specification.

Our trivial example looks as follows, when the   trick is applied:

<table border="1" bgcolor="#ffcc99">
<tr> <td>foo</td> <td>bar</td> </tr>
<tr> <td>zap</td> <td>&nbsp;</td> </tr>
</table>

The   trick is not very logical, since the basic role of the character denoted by   is to act as no-break space. (That is, it is comparable to normal space but when occurring between words it prevents a browser from dividing text into lines at that point. So no-break space "glues" words before and after it together as far as division into lines is considered.)

However, in addition to working quite well as a rule, the trick has a semi-official status in the sense of being described in the HTML 3.2 specification. The wording there is somewhat unclear, so it's probably not a requirement on browsers, just description of typical browser behavior. The wording is the following:

Tables are commonly rendered in bas-relief, raised up with the outer border as a bevel, and individual cells inset into this raised surface. Borders around individual cells are only drawn if the cell has explicit content. White space doesn't count for this purpose with the exception of  .

The entity reference   is just one way of including the no-break space character into an HTML document as data. For example, if you are generating a document programmatically, you could as well write the character itself directly, e.g. using print chr(0xA0); in Perl, assuming that the document is ISO-8859-1 encoded.

The CSS way: empty-cells:show

Using CSS, you can use just
table { empty-cells:show; }
in a style sheet, to suggest that all empty cells be displayed as normal cells.

This approach is preferable in principle, since presentational issues should be handled in CSS, not HTML. It also avoids the problem to be discussed next. However, it still works less often than the   hack.

What if the cell needs to be made smaller?

Sometimes the inclusion of a no-break space makes the cell larger than the author wants to. This is probably relevant only if you are using the cell for layout purposes, so that it should be just a few pixels high, or just a few pixels wide. The attached example illustrates this: we try to put a "divider row" into a table, using the markup

<tr> <td colspan="2" bgcolor="#009966" height="5">&nbsp;</td> </tr>

However the cell's height is not the suggested five pixels but considerably more.

Since the no-break space is a real character, it has some intrinsic width and height requirements, which depend on the font size. Attempts to hack the dimensions small enough by using font level markup or CSS to make the font size as small as possible have turned out to be a bit clumsy and not very effective.

foo	bar
zap	zip

The workaround is to use a single-pixel image (in GIF format) of the desired color, or a transparent single-pixel image. Then there's no character inside the cell, just a 1 pixel image. Thus, if cellpadding for the table is set to zero, you can make the cell down to one pixel wide and one pixel high. In our example, that would mean the following markup:

<tr> <td colspan="2" bgcolor="#009966" height="5"><img src=
"../images/transp.gif" alt="" width="1" height="1"></td> </tr>

You could copy transp.gif for example from http://www.cs.tut.fi/~jkorpela/images/transp.gif

Note that due to some browser bugs in HTML parsing and other oddities, there should be nothing (not even a line break) between the <td ...> tag and the <img ...> tag, or the <img ...> tag and the </td> tag. There can be line breaks inside the <img ...> tag though, as in the example above.

Better alternatives

It should be noted that according to typical browser behavior described above, any nonempty content in a td (or TH) element has the same effect on border as  . Here normal blanks and newlines are regarded as empty, but for example 0 or - are nonempty, of course - even if they semantically indicated absence of relevant data, in a particular context.

Thus, it is worth considering the use of some appropriate character or string for "empty cells". Notice that if a cell is completely blank, some people under some circumstances may suspect that it is not intended to be blank; after all, popular browsers are known to have a lot of bugs in rendering tables! And using a hyphen is probably less distracting than a text like "this cell intentionally left blank".

Besides, when tables are presented in non-graphic ways, as in speech synthesis or text-only mode, empty cells may cause mysteries. In particular, in simple text-only presentation, a data table can be understandable if each row contains the same amount of items, but if some rows have fewer items, how do you know which of the columns are empty?

For textual cells, one might use the hyphen character - to denote absence of text. This might work well e.g. when a column is for various notes and there are some rows for which no note is needed.

In statistics there are conventions and common practices on the presentation of missing values or unrepresentable data. There are two different main categories: numerical and character missing values. In addition to truly missing data (e.g. a measument has not been made), a "missing value" might also be an existing data value which however is not presented (e.g. due to measured value being outside the range representable in a particular presentation).

The representation of various missing values may vary, but it is of course important to be consistent within a document. It is also important to explain the notations when needed, i.e. when the meanings are not intuitively clear or well-known to the audience. (If you expect that some readers need an explanation and others would be distracted by it, you can use the hypertext approach: write the explanation into a separate small document and just provide a link to it near the table.)

If a table presents data to be used as input to a program, it is natural to use the same representation of missing values as in the actual data, according to conventions which the program obeys.

Missing observations are often represented as a period (.) for numerical values and blank field for character values. A missing character value could also be speficied verbally and descriptively, such as missing, cannot say, no observation. Naturally, you should be careful in selecting the words so that readers will not take them as actual data values! You can give a visual hint, such as using italics (I element in HTML) if normal cells are in normal font, but you should not rely on such hints alone. (For instance, a browser might be unable to present text in italics at all.)

Sometimes it is logically or practically impossible for a data item to have any meaningful or relevant value. Consider, for example, a table which contains information about people, each row containing data for one person. If the columns are for items like age and marital status, what should an entry for a baby contain in the column for marital status? It might look strange to have not married there, so something like not relevant or not applicable (perhaps abbreviated as N/A) might be better.

As a final example, consider a table containing the distances between various cities (with the same cities appearing in the same order both as column headers and as row headers). What should you put into the diagonal cells? A value of 0 is conceivable, and so is the - character.

You could apply e.g. the following principles:

The notations used by the UN Statistics Division correspond to the table above, except that they use "..." (instead of "..") to indicate that data is not available and that plain "0" may be used as synonymously with "0.0".

Reasons to avoid the suggested notations in special cases

It should be noted, however, that there are cases when blank cells are probably the best choice, even if it would be theoretically possibly to provide more explanatory content. As Michael David McCrea explained one situation in an article in the c.i.w.a.h. newsgroup as follows:

In the case I worked with <http://www.osborn.com/brush/cup>, we had tables listing both characteristics and order numbers of a bunch of products... for some of the models, you could get a brass item, but not a stainless steel one. - - If you look at tables like those, using something as simple as N/A in each cell would have overshadowed all of the pertinent information.

Such considerations, which favor the use of  , especially apply to large non-statistical tables where empty cells occur frequently and in irregular patterns.

Sometimes one might consider putting notations like N/A in table cells into SMALL elements (e.g. <td><SMALL>N/A</SMALL></td>) to suggest to browsers that they should be rendered in smaller font, to make them less distracting.

Acknowledgement: I am indebted to Janne Mannfors for information on presenting missing data in statistics.