- From: Pierre Dubois <duboisp2@gmail.com>
- Date: Fri, 28 Sep 2012 15:16:22 -0400
- To: whatwg@lists.whatwg.org
Hi there,
This email is to complete my proposal sent earlier this month.
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037185.html)
Unfortunatly the URL that I provided on that email are now brokens.
The examples and the documentation have been moved from the "docs"
folder to the "demos" folder. You will find at the end of this email
the updated URL.
This proposal is to solve relationships issue when it is about
designing a complex accessible table. This proposal is backward
compatible and allow extensibility.
This proposal would help to resolve the following W3C HTML WG issue
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=7260
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=17943
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=18791
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=18790
You will be able to find the latest version of the table usability
algorithm along with his API on github here:
https://github.com/duboisp/Table-Usability-Concept
I know my algorithm can be optimized and may needs some clarification,
any feedback and contribution are welcome. With your help I would be
able to provide a polyfills for the Table Usability Concept. Any
complex table example that are not covered by this Table Usability
Concept are welcome for discussion on Github.
The proposal of the new API would help current and future project.
That would reduce the need of having several custom table parser.
For example:
* Generating a charts from a data table
* Reducing a large data table to make it fit on a small screen device
without lost of tabular information
* Easier access and more accurate information about the tabular data
for people with disability
* Possibility to navigate within the column of the tables, while
maintaining the ability to navigate within the rows
Note regarding the Table Usability Concept explained below: The
markdown markup is used. The documentation, algorithm and API attached
in this email represent today's content, September 28, 2012. You can
find the same information on github inside my project named: Table
Usability Concept project at
https://github.com/duboisp/Table-Usability-Concept
Proposal: Remove the headers attribute on the th element and td element
=======================
The Information, structure, and relationships conveyed through
presentation of a table can be programmatically determined with the
table usability algorithm provided below.
The HTML Table Validator show that by adding the id/headers attribute
on the analyzed table the relationships are programmatically
determined. (http://wet-boew.github.com/wet-boew/demos/tableparser/validator-htmltable.html)
Proposal: Remove the scope attribute on the th element
=======================
The Information, structure, and relationships conveyed through
presentation of a table can be programmatically determined with the
table usability algorithm provided below.
Currently, as per my understanding, the scope set to "rowgroup" or
"colgroup" needs to be anchored in a rowgroup or a colgroup. So, the
scope are just repeating the information about the grouping element.
That are not providing any extra *useful* information on the concerned
table.
The Table Usability Concept explained below use the grouping markup to
provide new scopes that are not supported by the current scope
attribute. Those new scopes are defined as a combination of Element
Classifcation with the Element Category. Here the new scopes defined
in the Table Usability Concept: "header", "data", "summary", "key",
"description", "group header" and "layout".
About the Table Usability Concept
=======================
The following is wrote in markdown markup. You can find an HTML
Version here: https://github.com/duboisp/Table-Usability-Concept
The Table Usability define a concept on how to create the relationship
between the informative elements versus the tables structure elements.
That is accomplished with guidance of the [Table Processing
model](http://dev.w3.org/html5/spec/attributes-common-to-td-and-th-elements.html#processing-model-0)
defined in the HTML 5 specification and the WCAG 2.0 Technique [G57:
Ordering the content in a meaningful
sequence](http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G57).
The Table Usability Concept is supported by a Javascript Parser build
with the jQuery framework and integrated in the [Web Experience
Toolkit Project](https://github.com/wet-boew/wet-boew).
There is an existing implementation variant of this Table Usability
Concept. You will find the documentation to the attention of any web
editor on the [Web Experience Toolkit (WET) - HTML Tables and WET
Table Parser](http://wet-boew.github.com/wet-boew/demos/tableparser/index-eng.html)
working examples.
The [HTML Table
Validator](http://wet-boew.github.com/wet-boew/demos/tableparser/validator-htmltable.html)
show how this table usability concept are interpretating the
relationships between cells and the markup used.
Javascript Table Parser source code: [Original location in the WET
Toolbox](https://github.com/wet-boew/wet-boew/blob/master/src/js/workers/parser.table.js),
[Working copy version](https://github.com/duboisp/Table-Usability-Concept/blob/master/Polyfill/parser.table.js)
##Element Type
* **Informative:** The informative element is related to the visual
look of the table. In the HTML the table informative element are:
_caption, th, td_
* **Structural:** A structural element is used to classify and give a
particular sementic to the informative element and their styling would
affect the informative element associated to them. In the HTML the
table structural element are: _table, colgroup, col, thead, tbody,
tfoot, tr_.
##Element Classification
The Informative and Structural element are classified in forth category
* **Matrix:** The matrix is the global container for a givin table.
The matrix have a reference to all the group, all the vector and all
the cell. The _table_ HTML element is used to represent the matrix.
* **Group:** A group is a data-set or a header-set inside a table. A
group is normally represented by a cell header (th). The _colgroup_,
_thead_, _tbody_, _tfoot_ is used to represent each group. Here, the
grouping concept is related but not directly associated to the visual
representation of the data inside the table. Special note regarding
the attribute _scope_: With this concept of element grouping, I
recommend to do not set the scope attribute because a summary row
group may don't have a representive header and this create
inconsistancy in the table structure.
* **Vector:** A vector is the linear representation of the table as
per his column and row. The _col_ and _row_ is used to represent a
vector.
* **Cell:** A cell is a visual element in a table. The _caption_, _th_
and _td_ is used to represent a cell.
##Element Category
The category is use to give a particular sementic to a classified element.
* **Header:** Basicly used to represent a header cell (th) and a
header row group (thead), this concept is applied to the Group, Vector
and Cell classification.
* **Data:** Basicly used to represent a data cell (td), this concept
is applied to the Group, Vector and Cell
* **Summary:** Always preceded by a "Data", the summary
category is determined on how the group and the cell is defined in a
table. The _tfoot_ element belong in the summary category.
* **Key:** Similar to a primary key in a relational database, the key
cell can only be defined for a row (Vector). The header cell
associated is alway next to the key cell. Generally the key is not to
intended to provide actual data but to provide a faster access to the
data or to give a unique name for a cell header as reference. It's
important that the key cell have the same width and height of his
assoicated cell header.
* **Description:** Used to provide additional information for a cell
header. The description are not part of the actual tabular data. The
description help to understand the cell header and/or provide
additional information about the Vector. For a row (Vector), the cell
description is next to the cell header for witch is providing a
description. For a column (Vector), the cell description is directly
bellow the cell header in the next row. It's important that the cell
description have the same width and height of his assoicated cell
header.
* **Layout:** Only applicable to a cell, a layout cell don't provide
any information. His location can only be at the intersection of two
header group or at the insection of two summary group. His width and
height need to correspond to the group intersection. Also to be
considerated as a layout cell, the element _th, td_ identified at the
intersection need to be an empty tag.
##Combinaison of Element Classification with the Element Category
* **Header Group:** Represent a set of heading. In a row perpective
this are represented by the _thead_ element. In a column perpective
this are represented by the first _colgroup_ element. The key and the
description is defined in the header group.
* **Data Group:** Represent a data set. In a row perpective this are
represented by the _tbody_ element. In a column perpective this are
represented by the first _colgroup_ element if no column header group,
Or by the second _colgroup_ if a column header group exist. A table
always have at least one data group for the column and one data group
for the row. A Data Group can be represented by a group header cell.
* **Summary Group:** Often smaller than his associated data group, the
summary group include all the vector that show information like
sub-total, total. The summary group share with his associated data
group the same group header cell. However, it's possible, for a
summary to do not share a group header cell with a data group. In this
particular case the summary is set at the level 0 and no other group
is allowed after.
* **Header Vector:** A row or a column that is last cell is a header cell.
* **Data Vector:** A row or a column that is last cell is a data cell.
The only exception is a vector contained inside a header group, that
define the concept of the key and description cell.
* **Summary Vector:** Similar to a data vector but defined inside a
summary group.
* **Key Vector:** Only defined inside a column header group, the key
vector is simply the column of key cell.
* **Description Vector:** Only defined inside a header group, the
description vector represent the column or/and the row that is used to
describe a cell header.
* **Header Cell:** Represent a group or a vector. The table _caption_
and _th_ element is considerated to be header cell.
* **Group Header Cell:** Derivated from a header cell, a group header
cell represent a data group or a combinaison of a data group with a
summary group. The table _caption_ is considerated to be a group
header cell.
* **Data Cell:** Defined inside a data group and represented by the
_td_ element.
* **Summary Cell:** Defined inside a summary group and represented by
the _td_ element.
* **Key Cell:** His relation is defined by the column header group.
Similar to a primary key in a relational database, the key cell can
only be defined for a row (Vector). The header cell associated is
alway next to the key cell. Generally the key is not to intended to
provide actual data but to provide a faster access to the data or to
give a unique name for a cell header as reference. It's important that
the key cell have the same width and height of his assoicated cell
header.
* **Description Cell:** His relation is defined by the header group.
Used to provide additional information for a cell header. The
description category is not a data but help to understand the cell
header and/or provide additional information about the Vector. For a
row (Vector), the cell description is next to the cell header that his
providing a description. For a column (Vector), the cell description
is directly bellow the cell header in the next row. It's important
that the cell description have the same width and height of his
assoicated cell header.
* **Layout Cell:** A layout cell don't provide any information. A
layout cell need to be empty tag without any spaces inside. His
location can only be at the intersection of the header group or at the
insection of summary group. His width and height need to correspond to
the group intersection. The layout cell can be a _th_ or a _td_
element.
Proposal: Table Usability API
=======================
You can find an HTML Version here:
https://github.com/duboisp/Table-Usability-Concept/tree/master/API
## table element
interface HTMLTableElement : HTMLElement {
attribute HTMLTableCaptionElement? caption;
attribute HTMLTableGroupElement? rowHeaderGroups;
attribute HTMLTableGroupElement? colHeaderGoups;
readonly attribute HTMLCollection rowGroups;
readonly attribute HTMLCollection colGroups;
readonly attribute HTMLCollection keys;
readonly attribute HTMLCollection descriptions;
readonly attribute HTMLCollection layouts;
readonly attribute HTMLCollection rows;
readonly attribute HTMLCollection cols;
};
## caption element
interface HTMLTableCaptionElement : HTMLElement {
attribute HTMLElement header;
readonly attribute HTMLCollection descriptions;
};
## colgroup element
interface HTMLTableGroupElement : HTMLElement {
readonly attribute HTMLCollection vectors;
readonly attribute HTMLCollection headers;
readonly attribute DOMString scope;
readonly attribute long level;
};
interface HTMLTableColgroupElement : HTMLTableGroupElement {
readonly attribute long start;
readonly attribute long end;
}
## col element
interface HTMLTableVectorElement : HTMLElement {
readonly attribute HTMLCollection cells;
readonly attribute HTMLCollection headers;
readonly attribute HTMLCollection headersGroup;
readonly attribute long level;
readonly attribute long index;
readonly attribute long groupIndex;
readonly attribute DOMString scope;
};
interface HTMLTableColElement : HTMLTableVectorElement {
readonly attribute long start;
readonly attribute long end;
}
## thead element
interface HTMLTableGroupElement : HTMLElement {
readonly attribute HTMLCollection vectors;
readonly attribute HTMLCollection headers;
readonly attribute DOMString scope;
readonly attribute long level;
};
HTMLTableGroupElement, defined in the colgroup elements.
## tbody element
interface HTMLTableGroupElement : HTMLElement {
readonly attribute HTMLCollection vectors;
readonly attribute HTMLCollection headers;
readonly attribute DOMString scope;
readonly attribute long level;
};
HTMLTableGroupElement, defined in the colgroup elements.
## tfoot element
interface HTMLTableGroupElement : HTMLElement {
readonly attribute HTMLCollection vectors;
readonly attribute HTMLCollection headers;
readonly attribute DOMString scope;
readonly attribute long level;
};
HTMLTableGroupElement, defined in the colgroup elements.
## tr element
interface HTMLTableVectorElement : HTMLElement {
readonly attribute HTMLCollection cells;
readonly attribute HTMLCollection headers;
readonly attribute HTMLCollection headersGroup;
readonly attribute long level;
readonly attribute long index;
readonly attribute long groupIndex;
readonly attribute DOMString scope;
};
HTMLTableVectorElement, defined in the col elements.
## th element
interface HTMLTableCellElement : HTMLElement {
readonly attribute HTMLCollection cols;
readonly attribute HTMLCollection rows;
readonly attribute long rowIndex;
readonly attribute long colIndex;
attribute long height;
attribute long width;
readonly attribute DOMString scope;
};
interface HTMLTableHeaderCellElement : HTMLTableCellElement {
readonly attribute DOMString context;
attribute HTMLTableCellElement description;
attribute HTMLTableCellElement key;
}
## td element
interface HTMLTableCellElement : HTMLElement {
readonly attribute HTMLCollection cols;
readonly attribute HTMLCollection rows;
readonly attribute long rowIndex;
readonly attribute long colIndex;
attribute long height;
attribute long width;
readonly attribute DOMString scope;
readonly attribute DOMString context;
};
# td element - descriptive cell and key cell
interface HTMLTableDescCellElement : HTMLTableCellElement {
attribute HTMLElement describe;
}
Proposal: Table Usability Parser Algorithm
=======================
The following is wrote in markdown markup. You can find an HTML
Version here: https://github.com/duboisp/Table-Usability-Concept/tree/master/Algorithm
* While the current element is not one of the following elements,
advance the current element to the next child of the table:
* _caption_
* _colgroup_
* _thead_
* _tbody_
* _tfoot_
* _tr_
* If the _current element_ is a _caption_, run the [Long Description
Extract algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//LongDescriptionExtract.md)
* While the current element is not one of the following elements,
advance the current element to the next child of the table:
* _colgroup_
* _thead_
* _tbody_
* _tfoot_
* _tr_
* If the _current element_ is a _colgroup_, run the [colgroup-col
algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//colgroup-col.md)
* _Rows:_ While the current element is not one of the following
elements, advance the current element to the next child of the table:
* _thead_
* _tbody_
* _tfoot_
* _tr_
* If the _current element_ is a _thead_, run the [thead
algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//thead.md)
* While the current element is not one of the following elements,
advance the current element to the next child of the table:
* _tbody_
* _tfoot_
* _tr_
* If the _current element_ is a _tbody_ or a _tfoot_, run the [tbody
algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//tbody.md)
* If the current element is a tr, then run the [algorithm for
processing rows](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//row.md),
advance the current element to the next child of the table, and return
to the step labeled rows.
* If there exists a row or column in the table containing only slots
that do not have a cell anchored to them, then this is a table model
error.
* Return the table.
## Long Description Extract - Table Parsing Algorithm
* The first text node found is considerated as the title.
* If that text node is wrapped inside a node element, the parent node
element would be considerated as the title.
** ? _If the text node are not wrapped, do an auto wrapping with a
strong element._
* Other node that is next to the caption would be considerated as the
description of the caption element.
## colgroup / col
* Set the appropriate colgroup starting position, based on the
previous parsed colgroup element. _(used for internal reference)_
* For each col element
* Set the appropriate colgroup starting position, based on the
previous parsed colgroup element and on the previous parsed col
element. _(used for internal reference)_
* Set the appropriate column width if application with his span attribute.
* Add the HTMLTableVectorElement in the HTMLTableGroupElement
* If No col element found
* Calculate the width of the colgroup with his span attribute.
* Create an virtual column for each column that his colgroup are convering.
* Let the virtual column to have a with of 1
* Stack this parsed colgroup. _(The colgroup structure would be
validated later)_
## thead
* [Digest each row](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//row.md)
* Stack the digested row for future use in the gobal algorithm
## tbody
* Run the [algorithm to initiate an row
group](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm/rowGroupInitialize.md).
* [Digest each row](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//row.md)
* Run the algorithm for [Finalizing a row
group](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupFinalize.md)
* Discard any cell that is spanned outside this row group
## Row Parsing
* Get an array where the length is the table width and each items are
refering to an cell. This is based on the cell contained in the
current table row.
* If the row is processed under the [thead
algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//thead.md):
stack the row and exit
* If the last cell is an header cell
* Mark the row as an header row
* If the first cell not equal the last cell
* If the row header are not defined, and current no data row is found
* Stack the row in the thead stack
* exit
* else
* Raise an structural error, the column can only defined into the
first rows of the table
* exit
* else (this means we have a cell that is colspanned for the full table width)
* Stack the row in the header cell row group for future processing
by the row group setup algorithm
* exit
* The last cell is an data cell
* Mark the row as data row
* Flag that the header row group is finished
* If the previous row is a header row and it's contain a group header cell
* If the first cell equal the last cell
* Associate this cell as the description of the previous group header cell
* exit
* if the current group have not being processed: Run the [row group
setup algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupSetup.md)
* Get the last highest column position of the cell header (called here
lastHeadingColPos) _(last th element column position)_
* If there the colgroup element is used, let the lastHeadingColPos to
be the width of the first colgroup if the first colgroup width is the
same as the lastHeadingColPos or the lastHeadingColPos plus "1".
* If the current row is the first data row, the value of
lastHeadingColPos would be used to determine if there is an change
about data vs summary row
* If the current row is the second or subsequent data row
* If the lastHeadingColPos do not equal to the lastHeadingColPos of
the preceding data row
* If the lastHeadingColPos do not exist for a data summary row
* Let the current lastHeadingColPos to be the patern for a data summary row
* [Finalise the row
group](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupFinalize.md)
* [Initiate the row
group](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupInitialize.md)
* [Row group
setup](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupSetup.md)
* If a summary partern is know and the current lastHeadingColPos
match the lastHeadingColPos for the previous data row
* [Finalise the row
group](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupFinalize.md)
* [Initiate the row
group](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupInitialize.md)
* Force the [row group
setup](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupSetup.md)
to be a data row group
* Raise a warning that this data row group are not identified by a
group header cell
* else
* Raise an structural error, only two row partern can be defined
per data table
* From the column 1 until the lastHeadingColPos
* If the current cell is a data cell
* If the cell at column pos minus 1 is an header cell
* If both cell get a match as per his height
* Mark the current cell as a description cell
* If the current cell is an header cell
* From column position 1 to the current cell column position
* If there is a data cell that match his height
* Let the first cell found to be his associated key cell
* For subsequent matching cell, Raise an structural error because
may be those cell can be data cell.
* If there is a header cell that his height is higher or equal to
the current cell
* Set the relationships between both header cell. The current
header cell would be a children.
* If there is lastHeadingColPos is undefined and there is no colgroup
element defined
* Create one colgroup with column that cover the table width
* Run the [row group header
algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//processRowGroupHeaders.md)
based on the lastHeadingColPos _(This would validate the colgroup
structure)_
* From the column lastHeadingColPos more "1" to the last column
* Navigate along with the corresponding column group for the current cell
* Let's the data cell type to match the row type (summary or data)
with the column group type (summary or data)
* If the row type is summary and the colgroup type is summary and
the current cell cover both group as per width and height
* If the current cell is an empty cell, mark it as a layout cell
* If there is column group, assume we have data column group
* Set the associate any row cell heading that is out of scope of the
current cell when the current cell height is larger than 1 row
* Associate each cell from the current row to the appropriate column
* Associate the row and column level to each cell from the current row
* Set any additional column header associated to the current cell
when his width is larger than 1 column
## Initiating a Row Group
* Finalise the current row group with the algorithm for [Finalizing a
row group](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupFinalize.md),
if applicable.
* Initiate a new HTMLTableGroupElement interface
## Row Group Setup
* With the header row array
* if the cell cover the full table width
* Mark the cell as group header cell
* If the current row group is the first row group, excluding the
header row group
* Check if the current row group need to be initiated. This is to
handle simple table markup without row grouping
* Set the default data level at "1" and mark the current row group as
a data row group
* Check agains the column group if an header column group exist
* If exist: Check if the row group can be marked as a summary row
group. The header row array should be empty before the execution of
this algorithm
* Otherwise: mark the row group as a data row group
* Calculate the data level if not set
The data level is based on the current and previous row group.
* if the current row group is marked as a data row group
* if the number of header group cell is equal for both row group:
The level is the same as the previous group.
* if the number of header group cell is lower than the previous row group
* The current level is calculated based on the level of the
previous row group minus the number of header group cell of the
current row group
* Update the relationships of the header group cell than is also
represented in the current row group
* The current level would be the same as the previous row group
* if the number of header group cell is greater than the previous row group
* Increase the current row group level by the number of header
group cell more "1"
* if the current row group is marked as a summary row group
* if the previous row group are a summary row grou
* Reduce the level by "1"
* else
* The level is the same as the previous row group
* Associate the appropriate header group cell for the level based on
the previous row group
* If there are no previous row group
* The level is calculated based on the number of header group cell more "1"
* Empty the header row array
At the end of this algorithm, a level greater or equal to zero should
be defined for the row group. If the calculated level are under "0",
this is an structural error.
## Finalizing a Row Group
* Ensure the [Row Group Setup
algorithm](https://github.com/duboisp/Table-Usability-Concept/blob/master/Algorithm//rowGroupSetup.md)
has be run on the current row group
* Add the current row group in the HTMLTableElement
## Process Row Group Headers
* If the there is an lastHeadingColPos, the first colgroup should match.
* if false: Raise an structural error and reset the colgroup structure
* Associate any descriptive cell with the cell header above.
The following algorithm are not considerating any row included in the
row group header that are providing a description for cell headers.
* If the table markup do not have any colgroup defined
This can result to one colgroup or two colgroup only
* Create the new colgroup and col structure by taking in
consideration the lastHeadingColPos
* else the table markup have colgroup element defined
* For each colgroup element
* If a summary group at level 0 already exist
* Raise an structural error
* return
* If is the first colgroup and lastHeadingColPos is greater than 0
* Mark the current colgroup as the header group
* go to the next colgroup
* Get the colgroup data level
The colgroup level is calculated by the row position of the larger
(width) cell header that cover the colgroup but closer to the colgroup
width.
* If the colgroup data level is undefined, let the colgroup data level to be 1
* If the cell bellow the colgroup data level found is larger than
the current colgroup: raise an structural error
* Create virtual colgroup for the group cell header that is on lower
data level of the current colgroup data level
This identify the group header cell for the column grouping
* Set the relationships between the group header cell for the
current group and the virtual column group
* If the number of virtual column group is lower than the current
colgroup level
* Let the current colgroup to be a data column group
* If the preceding colgroup are in the same data level or the
current colgroup level is higher to the preceding colgroup
* Let the current colgroup to be a summary column group
* If the current colgroup level is 1 and it's exist other colgroup at level 1
* Let the current colgroup to be a summary column group
* If there exist summary colgroup at level 1
* Let current colgroup to be at level 0
* For each col defined in the current colgroup
* Assign the type and the level defined by the current colgroup
* Create the relationships between the column header cell and the
columns that a match can be found
Email sent earlier this month with the broken link fixed
=======================
On Thu, 6 Sep 2012, Pierre Dubois wrote:
>
> Hi there,
>
> I developed a javascript table parser based on my research. The parser is
> able to understand complex relationship in a data table. The relationship
> association is based on the current algorithm and take in consideration how
> the header cell (th) is structured, positioned and spanned. All of this is
> combined on how the column grouping (colgroup) and the row grouping (thead,
> tbody) is structured.
>
> My research was based on usability and common use of table. My goal was to
> find how the HTML markup can be used to represent a complex table based on
> how a person would understand the complex table by viewing it in a user
> agent and on paper.
>
> My research led me to extend the current definition of the table elements
> (table, caption, colgroup, col, thead, tbody, tfoot, tr, th, td) and I
> tried to understand the table without discriminating row and column. See
> the Extended definition of HTML 5 table
> elements<http://wet-boew.github.com/wet-boew/demos/tableparser/ExtendedDefinition.html>
> .
>
> Described in the extended definition, here is a quick list of the 7
> different types for a cell (th and td) can have.
>
> Header cell (th) types
>
> * Header
> * Layout
> * Header group
>
> Data cell (td) types
>
> * Data
> * Summary
> * Key
> * Description
> * Layout
>
>
> This concept use the row grouping (thead and multiple tbody) and the column
> grouping (colgroup) to define data summaries. This can be used to reduce
> the table size when it's needed to be displayed in a smaller screen, like a
> mobile device.
>
> I would also like to propose adding a method on how data table size (the
> visual aspect) can be reduced by an user agent instead of just overflow off
> screen in the specification.
>
> Based on the table usability concept, I developed the javascript table
> parser and drafted 12 techniques to help web editor to understand and use
> this concept.
>
> 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>
>
> *(FYI, the intention behind of those techniques are for a future submission
> to the WCAG 2.0 Techniques*)
>
> As part of the Web Experience Toolkit (WET) project, I enhanced a zebra
> widget to support those complex table as well.
>
> Here are some examples:
>
> * Column highlight
> table<http://wet-boew.github.com/wet-boew/demos/tableparser/zebra/columnhightlight.html>
> * Simple table<http://wet-boew.github.com/wet-boew/demos/tableparser/zebra/simple.html>
> * Simple grouping
> table<http://wet-boew.github.com/wet-boew/demos/tableparser/zebra/simplegrouping.html>
> * Invoice table<http://wet-boew.github.com/wet-boew/demos/tableparser/zebra/invoice.html>
> * Row level with summary
> table<http://wet-boew.github.com/wet-boew/demos/tableparser/zebra/rowlevelwithsummary.html>
>
>
> I documented 3 case studies on how a current table can be updated to create
> a more usable table.
>
> * Case Studies #1<http://wet-boew.github.com/wet-boew/demos/tableparser/Table-CaseStudies.html>
> * Nutrition Facts
> table<http://wet-boew.github.com/wet-boew/demos/tableparser/Table-CaseStudies-2.html>
> * Ottawa Senators vs. Buffalo Sabres - Game ID #
> 270519002<http://wet-boew.github.com/wet-boew/demos/tableparser/Table-CaseStudies-3.html>
>
>
> Here is the latest source code of the table parser :
> https://github.com/wet-boew/wet-boew/blob/master/src/js/workers/parser.table.js
>
> The following table validator use the table parser and show structural
> table error and provide a revised version of the table with the
> ids/header/aria-describedby auto set :
> http://wet-boew.github.com/wet-boew/demos/tableparser/validator-htmltable.html
>
> I also I submitted two bugs in the w3c public bug database related to this
> topic that can be seen below.
>
> * Reducing data table size based on the row grouping, column grouping
> combined with the table header cell
> structure<https://www.w3.org/Bugs/Public/show_bug.cgi?id=18791>
> * Describing cell for an header cell in a data
> table<https://www.w3.org/Bugs/Public/show_bug.cgi?id=18790>
>
> I would be open to comments and suggestions that could results in future
> improvements. I would also be willing to share the outcome of my research
> to be included in the specifications.
>
Thank you
:-)
Pierre Dubois
Received on Friday, 28 September 2012 19:17:10 UTC