E-mail List Archives
Thread: correct markup of empty cells in a data table
Number of posts in this thread: 8 (In chronological order)
From: Steven Faulkner
Date: Mon, Mar 21 2005 8:09PM
Subject: correct markup of empty cells in a data table
No previous message | Next message →
I have a data table that contains an empty cell "<td
rowspan="5"> "
I am not sure if it is best marked up as a TH (as the other cells in the row
are th) or as a TD
any ideas? does it matter?
example code:
CBF Case by Status
Case Status
Total
Draft
0
Suspended
0
Returned from Suspension
0
Duplicate
37
CBF Starts and Exits
Number of Cases Exited
0
Number of Cases Started
0
best regards
stevef
__________________________________________________________________
> has removed Spam messages and set aside Later
for me
You can use it too - and it's FREE! http://www.ellaforspam.com
From: Jukka K. Korpela
Date: Mon, Mar 21 2005 11:20PM
Subject: Re: correct markup of empty cells in a data table
← Previous message | Next message →
On Tue, 22 Mar 2005, steven.faulkner wrote:
> I have a data table that contains an empty cell "<td
> rowspan="5"> "
Empty cells tend to cause problems. Quite often there is a better way,
typically the use of some characters that indicate _why_ the cell
does not contain normal data. In this case, I'm not sure.
> I am not sure if it is best marked up as a TH (as the other cells in the row
> are th) or as a TD
The HTML specification says that TD is a cell that contains table data
only, TH is a cell that contains a table header only, and for cells that
contain both should be marked up as TD. So a TD cell can be dual-purpose,
and could have a SCOPE attribute that tells how it acts as a header.
Somewhat oddly, the spec says this in a DTD comment only:
"TH is for headers, TD for data, but for cells acting as both use TD"
Ref.: http://www.w3.org/TR/html4/struct/tables.html#edef-TD
Thus, in borderline cases, TD would be more suitable in principle.
> does it matter?
Not much. It's difficult to say how it could matter. The spec says:
"Table cells may contain two types of information: header information and
data. This distinction enables user agents to render header and data cells
distinctly, even in the absence of style sheets. For example, visual user
agents may present header cell text with a bold font. Speech synthesizers
may render header information with a distinct voice inflection."
But how could such things matter when the cell contains a no-break space
only? And if a browser lets the user specify which data is to be presented
to the user, it may use TH elements and their attributes to decide how
this would take place. There's not much it could do with a TH cell
containing just a no-break space, could it?
> example code:
I think I understand the intended structure of the table, but it might not
be that obvious. How would you describe it in a SUMMARY attribute?
(I'm not saying you should write one; but it's often useful to think
what you would put there if you wrote it.) If the intent is that the
second cell in the first column emphasizes the meaning of the last two
rows, then this might work visually, but it makes the table somewhat
odd-looking, and would make aural rendering a little more confusing.
So I would suggest removing the entire first column, making the table
structure. For emphasis, you could use STRONG markup for the words
"Exited" and "Started" on the last two rows.
By the way, columns containing numbers are visually a little easier to
understand if they are right-aligned. It's easier to compare the numbers
that way.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Jens Meiert
Date: Tue, Mar 22 2005 1:53AM
Subject: Re: correct markup of empty cells in a data table
← Previous message | Next message →
> [...] " "
> I am not sure if it is best marked up as a TH (as the other cells
> in the row are th) or as a TD
Jukka perfectly pointed out some issues, but in practice (if the cell really
ain't "motivated by visualization") you'd use "", I fear.
- By the way, you can use CSS 2's "empty-cells" property [1] to control the
way those cells (without a no-break space!) appear (in respect to borders).
HTH,
Jens.
[1] http://www.w3.org/TR/CSS2/tables.html#empty-cells
--
Jens Meiert
Information Architect
http://meiert.com/
From: Jens Meiert
Date: Tue, Mar 22 2005 1:53AM
Subject: Re: correct markup of empty cells in a data table
← Previous message | Next message →
> [...] " "
> I am not sure if it is best marked up as a TH (as the other cells
> in the row are th) or as a TD
Jukka perfectly pointed out some issues, but in practice (if the cell really
ain't "motivated by visualization") you'd use "", I fear.
- By the way, you can use CSS 2's "empty-cells" property [1] to control the
way those cells (without a no-break space!) appear (in respect to borders).
HTH,
Jens.
[1] http://www.w3.org/TR/CSS2/tables.html#empty-cells
--
Jens Meiert
Information Architect
http://meiert.com/
From: Jukka K. Korpela
Date: Tue, Mar 22 2005 3:15AM
Subject: Re: correct markup of empty cells in a data table
← Previous message | Next message →
On Tue, 22 Mar 2005, jens.meiert wrote:
> Jukka perfectly pointed out some issues, but in practice (if the cell really
> ain't "motivated by visualization") you'd use "", I fear.
That would be a mistake. Formally that markup would be invalid in classic
HTML and equivalent to _but not recommended_ in
XHTML. And in any case it would be both in theory and in practice distinct
from .
> - By the way, you can use CSS 2's "empty-cells" property [1] to control the
> way those cells (without a no-break space!) appear (in respect to borders).
You could, but IE does not support it, so it's not very useful mostly.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Jens Meiert
Date: Tue, Mar 22 2005 3:43AM
Subject: Re: correct markup of empty cells in a data table
← Previous message | Next message →
> That would be a mistake. Formally that markup would be invalid in
> classic HTML and equivalent to _but not
> recommended_ in XHTML. And in any case it would be both in theory
> and in practice distinct from .
"" or "" is nonetheless "less worse"
than " ", correct me if I'm wrong. And this must
not belie that these scenarios usually need to be checked - I suspect
anything to be "suboptimal" if you need larger spanning cells.
--
Jens Meiert
Information Architect
http://meiert.com/
From: Jens Meiert
Date: Tue, Mar 22 2005 3:43AM
Subject: Re: correct markup of empty cells in a data table
← Previous message | Next message →
> That would be a mistake. Formally that markup would be invalid in
> classic HTML and equivalent to _but not
> recommended_ in XHTML. And in any case it would be both in theory
> and in practice distinct from .
"" or "" is nonetheless "less worse"
than " ", correct me if I'm wrong. And this must
not belie that these scenarios usually need to be checked - I suspect
anything to be "suboptimal" if you need larger spanning cells.
--
Jens Meiert
Information Architect
http://meiert.com/
From: Jukka K. Korpela
Date: Tue, Mar 22 2005 4:49AM
Subject: Re: correct markup of empty cells in a data table
← Previous message | No next message
On Tue, 22 Mar 2005, jens.meiert wrote:
> "" or "" is nonetheless "less worse"
> than " ", correct me if I'm wrong.
Well, since you asked... your first alternative is simply
_wrong_, as I explained. The second one has an empty cell as
opposite to a cell containing a no-break space. Why would either
of them be less worse than the other, since logically neither of
them says why the cell lacks actual content, and in practice
most browsers treat them the same way, except perhaps for background
and border. And these visual details, which are the reason for
using , make the table clearer, or less obscure.
> And this must
> not belie that these scenarios usually need to be checked - I suspect
> anything to be "suboptimal" if you need larger spanning cells.
Spanning cells, whether used for layout or due to the structure of the
data, are problematic indeed. The mere fact that the table's structure
is not a simple matrix (grid) any more makes the table more difficult,
and sometimes considerably more difficult to some people. Various
accessibility-oriented extra attributes to the elements in the table
don't solve much, and besides, most authors don't know how to use them.
So the question is what one might achieve, in a particular case, and to
weigh this against the problems.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/