[whatwg] Default scope for table headers

[Nicholas Shanks]

http://www.w3.org/TR/html-markup/th.html#th.attrs.scope Says nothing
about what a UA should do by default, nor when scope can be omitted
due to such defaults.

I suggest explicitly defining defaults for the benefit of both UAs and
HTML authors. I would expect the defaults to be defined something like
this:


Rule 1) If a row begins with zero or more empty TD elements, followed
by one or more TH elements and no further TD elements, and all
previous rows in the table also satisfied this Rule, the default scope
is "col" for each TH in the row.
Rule 2) If a row contains one or more TH elements, followed by one or
more TD elements and no further TH elements, the default scope is
"row" for each TH in the row.
Rule 3) If a table contains two or more columns, and a row in an
implicit or explicit TBODY row group contains a single TH element
which spans all columns, and any previous rows in the row group also
satisfied this Rule, the default scope is "rowgroup" for that TH
element.
Rule 4) If an implicit or explicit TBODY row group contains two or
more rows, and the first row of the group contains a TH element which
spans all rows in the group, and any previous cells in the row also
satisfied this Rule, the default scope is "rowgroup" for that TH
element.
Rule 5) If a TH cell which satisfied Rule 1 spans two or more columns,
and those columns constitute a complete COLGROUP, the default scope is
"colgroup" for that TH element.


This describes the most complex form of an 'obvious' table I can think
of at this time in the morning, where obvious means there can be no
other expected behaviour:

<col><col><colgroup><col><col><col><colgroup><col><col><col>
<thead>
<tr><td><td><th colspan="3">Section1<th colspan="3">Section2
<tr><td><td><th>Col1<th>Col2<th>Col3<th>Col1<th>Col2<th>Col3
<tbody>
<tr><th rowspan="3">CategoryA<th>Row1<td>...<td>...<td>...<td>...<td>...<td>...
<tr><th>Row2<td>...<td>...<td>...<td>...<td>...<td>...
<tr><th>Row3<td>...<td>...<td>...<td>...<td>...<td>...
<tbody>
<tr><th rowspan="3">CategoryB<th>Row1<td>...<td>...<td>...<td>...<td>...<td>...
<tr><th>Row2<td>...<td>...<td>...<td>...<td>...<td>...
<tr><th>Row3<td>...<td>...<td>...<td>...<td>...<td>...
<tbody>
<th colspan="2">Total<td>...<td>...<td>...<td>...<td>...<td>...

Resulting in the following:
The cells containing Section1 and Section2 has default scope "colgroup"
The cells containing Col1, Col2 and Col3 have default scope "col"
The cells containing CategoryA and CategoryB have default scope "rowgroup"
The cells containing Row1, Row2, Row3 and Total have default scope "row"
Without the COLGROUP elements, the cells containing Section1 and
Section2 would have default scope of "col" instead.
Without the THEAD and TBODY elements, the cells containing CategoryA
and CategoryB would have default scope of "row" instead.

For any TH element, an explicitly present scope attribute overrides
the default (duh).
Since this is mark-up based, the rules apply equally to rtl tables
(column order is displayed differently, but mark-up is the same).
Also, personally, I would use empty TH elements in the top left, but
the algorithm should cover either case. An empty TH element would
still satisfy the 'one-or-more TH elements' condition, so doesn't need
to be mentioned in the rule.
When determining 'empty' in the first rule, an anonymous text node
containing only collapsed white space and/or non-breaking space
characters, should be ignored. Some HTML authors and authoring
programmes put   in cells to prevent them from collapsing.
Rules 3 and 4 cannot apply to a single TBODY at the same time. The
example table uses Rule 4.

Characteristics which prevent any defaults from existing in the table:

a) A row of TH elements after some rows of TDs in the same (implicit
or explicit) TBODY.
b) A TBODY element containing a row of two or more TH elements, if a
THEAD or TFOOT exist for this table.
c) The table contains no TD elements.
d) maybe more?

It would not be clear in either (a) or (b) whether the TH[scope=col]
elements from earlier rows apply to the rows under the second set of
headers, so all defaults should be removed, and let the author tell us
what s/he's trying to do.
For (c) there's no point in having defaults anyway :-)

This means that (use_scope_defaults == true) can only be determined at
the end of parsing the table. I hope that this is not a deal-breaker,
or that someone else can propose a better algorithm which does not
depend on unparsed parts of the table yet still does The Right Thing.

-- 
Nicholas.