...
> +------++----------------------------+
> | Temp ||January|February|March|April| Note single, double and
> +------++-------+--------+-----+-----+ absent borders.
> |Place || C F | C F | C F | C F |
> +======++=======+========+=====+=====+ Temperature conversions are
> |London|| 1 2 | 3 4 | 5 6 | 7 8 | not accurate.
> +------++-------+--------+-----+-----+
> |Paris || 1 2 | 3 4 | 5 6 | 7 8 |
> +------++-------+--------+-----+-----+
> In a typesetting language like LaTeX, I am accustomed to indicating these
> strong and loose bindings by omitting and doubling the border respectively
> as indicated in the above ASCII picture.
I received replies from Bruce Morris <[email protected]> and from
[email protected] which both suggested the use of nested TABLEs.
Having given this some thought, I have decided that nested TABLEs, whilst
they may approximate the required presentation in most browsers, don't
represent the semantic structure of my data. In particular, the semantic
link between the corresponding data in two parallel embedded TABLEs is
broken.
On the other hand, the same thought convinced me that I was wrong to think
of this structure in terms of strong and weak semantic binding between
adjacent pairs of columns or rows. It is better modelled as the grouping
of rows or columns and the concept that the binding betwen adjacent rows and
columns in different groups is weaker than that between rows and columns in
the same group.
I then pondered the difference. A nested TABLE can group rows (say) in a
tighter binding, but only by grouping columns (or a single column) as a
side-effect. It is this side-effect which breaks the data correspondence.
The syntax also becomes messier, but that isn't a structural issue.
A markup which grouped rows (or columns) together without creating a
nested TABLE with the suggestion that the border/spacing between them be
thinner or absent would seem to fit the case.
I can't think of a good syntax for that, so I'll suggest one based on
ROWSPAN/COLSPAN, which I've never liked. TD and TH shall have two new
attributes, ROWGROUP and COLGROUP with numeric value. This indicates that
that cell and the succeeding n-1 rows or columns have a tighter semantic
binding than normal. It is suggested that browsers set the cells closer
together or use a thinner border. Browsers could also set such cells
further from adjacent cells, expecially if they in turn are grouped in the
same dimension.
A moot point is whether the grouping of rows or columns should imply the
equivalent groups of all corresponding cells in the same column or row.
Returning to my example, it might have the source:
<TABLE>
<TR><TH ROWGROUP=2>Temp</TH>
<TH ROWGROUP=2>January</TH>
<TH ROWGROUP=2>February</TH>
<TH ROWGROUP=2>March</TH>
<TH ROWGROUP=2>April</TH>
<TR><TH>Place</TH>
<TH COLGROUP=2>C</TH> <TH>F</TH>
<TH COLGROUP=2>C</TH> <TH>F</TH>
<TH COLGROUP=2>C</TH> <TH>F</TH>
<TH COLGROUP=2>C</TH> <TH>F</TH>
<TR><TH>London</TH>
<TD COLGROUP=2>1</TD> <TD>2</TD>
<TD COLGROUP=2>3</TD> <TD>4</TD>
<TD COLGROUP=2>5</TD> <TD>6</TD>
<TD COLGROUP=2>7</TD> <TD>8</TD>
<TR><TH>Paris</TH>
<TD COLGROUP=2>1</TD> <TD>2</TD>
<TD COLGROUP=2>3</TD> <TD>4</TD>
<TD COLGROUP=2>5</TD> <TD>6</TD>
<TD COLGROUP=2>7</TD> <TD>8</TD>
</TABLE>
Gavin