Empty cells in HTML tables

Content:

Empty cells in tables often cause problems to HTML authors. Browsers may display such cells without border even if the other cells have borders. This document discusses various ways to deal with this issue as well as to avoid it by making cells nonempty. 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 (in the middle) and the IE 7 rendering (on the right). For clarity, table cell borders have been set to be solid, red, 2 pixels.

<table border="1" bgcolor="#ffcc99">
<tr> <td>foo</td> <td>bar</td> </tr>
<tr> <td>zap</td> <td></td> </tr>
</table>
foo bar
zap
(Rendering where the last cell has no border.)

On some browsers, the example 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 back­ground 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: &nbsp;

The usual trick is to put &nbsp; (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 syntactically conforms to the specification of HTML. Our trivial example looks as follows, when the &nbsp; 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>
foo bar
zap  

The &nbsp; trick is not very logical, since the basic role of the character denoted by &nbsp; 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 had 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 &nbsp;.

The entity reference &nbsp; 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 char­ac­ter itself directly, e.g. using print chr(0xA0); in Perl, assuming that the document is ISO-8859-1 encoded.

Newer HTML specifications are silent about the matter.

The CSS way: empty-cells

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. Previously, it worked less often than the &nbsp; hack, but due to better CSS support, the situation has changed: the empty-cells is supported by the great majority of browsers now.

You could use both methods, but then you may need to deal with issues raised by the use of a no-break space, discussed later in this document.

Modern browsers generally have borders around empty cells by default, as suggested in the CSS 2.1 specification. This implies that if you do not want to have borders around an empty cell, you need to set empty-cells: hide or explicitly set the border style to none or the border width to 0.

Such settings are relevant, for example, when a table has both column and row headers, making the very first cell dummy. The following tables illustrate this. The second one uses empty-cells: hide, which is effective here, since border-collapse is defaulted to separate. The third one simply sets border: none on the first cell, and this is effective even when border-collapse has been set to collapse.

abc
1a1b1c1
2a2b2c2
abc
1a1b1c1
2a2b2c2
abc
1a1b1c1
2a2b2c2

In CSS3, there is also the :empty pseudo-class, which refers to any element with empty content. It is not useful for the purpose discussed here, but it can be used e.g. to set the background color of empty cells different from other cells, e.g. th:empty, td:empty { background: gray; }.

What if the cell needs to be made smaller?

foo bar
 
zap zip

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 pur­poses, so that it should be just a few pixels high, or just a few pixels wide. The example here 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 old 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.

A newer issue is that modern browsers, such as IE since version 8 (when not simulating older versions), seem to treat even single-pixel image as if it were text. This imposes a minimum height. You can try to override it by setting font size and line height to 1px, but this is ineffective on Firefox if the browser settings impose a minimum font size that the author cannot circumvent.

foo bar
zap zip

If we simply leave the cell empty, we get a suitable rendering on modern browsers. It fails on old browsers that do not use a background color for such an element, but this problem is probably not practically significant any more.

Better alternatives

Nonempty cells

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 &nbsp;. Here normal blanks and newlines are regarded as empty, but for example the digit 0 or the hyphen (-) 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 (-) or, better, the en dash 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.

Conventional notations in statistics

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 pre­sented (e.g. due to measured value being outside the range representable in a particular pre­sen­ta­tion).

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 en dash () character.

You could apply e.g. the following principles:

notation meaning
..data not available
figure = 0 (exactly)
0.0 figure less than half of unit employed
.category not applicable

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. In a large table, emptyness may signal absence of information, or maybe more exactly non-empty­ness signals availability of information. In a matrix-like presentation, a notation like “N/A” or even a hyphen may disturb this.

Such considerations, which favor the use of &nbsp;, 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 the texts 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.