The Table Cell That Looks Empty

An empty cell in a table looks like nothing, and that is exactly why it needs care. Under the W3C standard for tabular data on the web, an empty cell is not simply nothing; it is a null value, at least when no other rule replaces it. And null is a technical state, not a shrug.

The standard is clear about what maps to null. A column’s metadata can declare which source strings mean null, and by default the marker is the empty string. So a cell with nothing in it becomes null unless metadata says otherwise. A separate default property can supply a replacement value when the original string is empty, and that default is itself empty unless you set it. The point is that this interpretation always follows the applicable metadata, and the standard defaults apply even when no declaration is present. An empty cell is null by default, whether or not you wrote anything down.

That matters because empty cells get used for several different things. Missing data. A value nobody has looked up yet. A value that does not apply. Under the default rules those collapse into one null, and the reason for each is gone.

Consider a hypothetical household inventory. One column, replacement_cost, holds an integer: how much it would cost to replace an item. One row holds 150, a real value. Another holds 0, and because the column is declared as an integer datatype and “0” is not among its declared null markers, that zero is retained as the number zero. A different declaration could have named “0” itself as a null marker, which is exactly why the declaration matters. A third row is blank; the empty string is the default null marker, so that cell becomes null. A fourth row holds “n/a”; that text is not a declared null marker, so it cannot parse as an integer, and the model produces a string value carrying a validation error rather than a clean number.

So the column can already tell zero from null from a bad string. What it cannot do is tell you why the blank cell is blank and why the “n/a” is not applicable. To keep those reasons, give the table a separate status column: one column holds the value, and another holds values like unknown or not-applicable. Let the value column hold the value and the status column hold the reason.

One more subtlety about the empty string. The data model notes that the presence or absence of quotes around a value in a CSV file is a syntactic detail not reflected in the model: there is no distinction between the second value in a,,z and the second value in a,"",z. Wrapping an empty cell in quotes does not turn it into a distinct non-empty value. The quotes are about parsing, not meaning.

An empty cell cannot remember why it is empty. If the reason matters, write it down in a column of its own.