[whatwg] Default scope for table headers

Mon Oct 1 11:30:20 PDT 2012

Nicholas Shanks <contact at nickshanks.com>, 2012-10-01 09:53 +0100:

> [...]
> 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.

Your proposal look similar to the rejected "Smart Algorithm".
(http://www.w3.org/html/wg/wiki/IssueTableHeaders#2._Hierarchical_headers_with_Smart_Algorithm)
>From my point of view, the "Smart Algorithm" it not a bad algorithm,
it just needs improvement.

The Table Usability Algorithm support your kind of table, backward
compatible and provide valuable information regarding how to use the
grouping tabular element (COLGROUP and TBODY). See my proposal:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037475.html

> 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>...

Based on the Table Usability Concept, what do you think about the
following alternative markup ?

<table>
<colgroup><col>
<colgroup><col><col><col><col><col><col>
<thead>
<tr><th rowspan="2"><th colspan="3">Section1<th colspan="3">Section2
<tr><th>Col1<th>Col2<th>Col3<th>Col1<th>Col2<th>Col3
<tbody>
<tr><th colspan="7">CategoryA
<tr><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 colspan="7">CategoryB
<tr><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>...
<tfoot>
<th>Total<td>...<td>...<td>...<td>...<td>...<td>...

And, what do you think of having sub-summary information for row
group, like sub-total? The sub-total row group is determined by the
absence of having a row group header cell. The Table Usability
Algorithm establish a relationships between the sub-total row group
and the related data row group.

<table>
<colgroup><col>
<colgroup><col><col><col><col><col><col>
<thead>
<tr><th rowspan="2"><th colspan="3">Section1<th colspan="3">Section2
<tr><th>Col1<th>Col2<th>Col3<th>Col1<th>Col2<th>Col3
<tbody>
<tr><th colspan="7">CategoryA
<tr><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>Sub-Total<td>...<td>...<td>...<td>...<td>...<td>...
<tbody>
<tr><th colspan="7">CategoryB
<tr><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>Sub-Total<td>...<td>...<td>...<td>...<td>...<td>...
<tbody>
<th>Total<td>...<td>...<td>...<td>...<td>...<td>...

Try the HTML Table Validor
(http://wet-boew.github.com/wet-boew/demos/tableparser/validator-htmltable.html)
by adding the class "wet-boew-zebra" to the table element. Once
analysed, you will get a visual interpretation of your tabular data.
eg.
<table class="wet-boew-zebra">
[...] // Your table markup here

Nicholas Shanks <contact at nickshanks.com>, 2012-10-01 12:04 +0100:

> It struck me that the scope attributes should have default values for
> such a simple table.

I think a web editor do not needs to use the "scope" attribute and/or
"id/headers". Even to make their table accessible WCAG 2.0 Level AA
compliant. The Tabular Usability Concept is essentially based on how a
person would understand the complex data table based on the visual UA
rendered layout and based on how the table grouping markup TBODY and
COLGROUP is used to provide real, useful and additional information to
the user.

On Mon, Oct 1, 2012 at 7:13 AM, Michael[tm] Smith <mike at w3.org> wrote:

> [...]
> > [...]
> > Are there use cases where the value of the scope attribute matters
> > other than as an intermediary for computing the headers applicable to
> > each cell? If not, are there use cases where either the data cell
> > headers have not yet been computed or they are unavailable (perhaps
> > while Javascript DOM tree walking?) where access to the scope
> > attribute would be helpful?
> >
> > If either of these can be answered in the affirmative, then I believe
> > a bug could be raised. Anyone care to chime in?
>
> Dunno the answers myself but will ping somebody who I think does

>From my point of view, the table cells relationships can be
programmatically determined. Having the scope attribute as currently
defined in the spec are not providing any useful and/or additional
information. As currently defined, the scope attribute are just
repeating the same information provided by the table grouping markup
COLGROUP, TBODY. Take a look in the spec, the scope "rowgroup" and
"colgroup" need to be anchored in a grouping elements.
(http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#attr-th-scope)

As per the current DOM API for tables, only the simpliest table is
supported. For an example, if a developper want to create a graphic
from a complex data table, he would be required to reinvent the wheel
by creating it's own table parser. That is why I developped the Table
Usability Concept. I know the complex table can be accessible to
screen reader by using id/headers or scope attribute but that are not
providing any useful information to the javascript developper who
needs the tabular information.

In the following link, you would find several complex table example.

1. Defining a Key Cell
(http://wet-boew.github.com/wet-boew/demos/tableparser/keycell-techniques.html)
2. Defining a Data Row Group
(http://wet-boew.github.com/wet-boew/demos/tableparser/rowgrouping-techniques.html)
3. Summaries a Data Row Group
(http://wet-boew.github.com/wet-boew/demos/tableparser/summariesrowgroup-techniques.html)
4. Structuring the Header Row
(http://wet-boew.github.com/wet-boew/demos/tableparser/headerrowgroupstructure-techniques.html)
5. Describing a Row Header Cell
(http://wet-boew.github.com/wet-boew/demos/tableparser/rowheader-description-techniques.html)
6. Describing a Row Group Header Cell
(http://wet-boew.github.com/wet-boew/demos/tableparser/rowgroupheader-description-techniques.html)
7. Defining Column Group Header
(http://wet-boew.github.com/wet-boew/demos/tableparser/colgroupheader-techniques.html)
8. Structuring the Header Column Cell
(http://wet-boew.github.com/wet-boew/demos/tableparser/headercolgroupstructure-techniques.html)
9. Defining a Data Column Group
(http://wet-boew.github.com/wet-boew/demos/tableparser/datacolgroup-techniques.html)
10. Summaries a Data Column Group
(http://wet-boew.github.com/wet-boew/demos/tableparser/colgroupsummary-techniques.html)
11. Describing a Column Header Cell
(http://wet-boew.github.com/wet-boew/demos/tableparser/colheader-description-techniques.html)
12. Defining a Layout Cell
(http://wet-boew.github.com/wet-boew/demos/tableparser/layoutcell-techniques.html)

I you have a HTML table where the above techniques can not be applied,
let me know here:
https://github.com/duboisp/Table-Usability-Concept/issues/new

Cheers

:-)

Pierre Dubois