- From: Pierre Dubois <duboisp2@gmail.com>
- Date: Fri, 19 Oct 2012 22:02:47 -0400
- To: whatwg@lists.whatwg.org
Hi folk,
Proposal: new table Boolean attribute named "hassum".
It was bring to my attention of a possible backward compatibility
issue in regards of the interpretation of having multiple subsequent
group in a table.
The issue:
Sometime the subsequent row grouping under the same data level and the
subsequent column grouping under the same data level don't necessary
mean a summary group but still a data group.
The solution:
To fix that the solution would be to have a new attribute set on the
table element to know if the table contains summaries group.
Addition to my initial proposal:
Add new boolean attribute for the table element called "hassum" for
"has summary group". See bellow, from my previous post, the updated
API and Algorithm.
The justification:
This table concept define the relationships between multiple table
groups (tbody, colgroup). The data level calculation stay the same by
default except the data level can be only decreased when the table are
in "has summary group mode" (new "hassum" proposed attribute). Having
the support for summary group is important and with that concept it
would be possible to have a better representation of a common used
table like the invoice table.
The possibility to define summary group in a table would allow a
responsive design support for tables. That could result by showing
only the summary group and show, on user request, the associate data
group, intentionally hidden, for a given data level group.
Invoice example with the "hassum" attribute
<table hassum>
<caption>Invoice Table 3</caption>
<colgroup> <!-- Header column group -->
<col />
<col />
<col />
</colgroup>
<colgroup> <!-- Data column group at level 1 -->
<col />
<col />
</colgroup>
<colgroup> <!-- Summary column group at level 1 -->
<col />
</colgroup>
<thead> <!-- Header row group -->
<tr>
<th>Product ID</th>
<th>Product</th>
<th>Description</th>
<th>Quantity</th>
<th>Unit Price</th>
<th>Total</th>
</tr>
</thead>
<tbody> <!-- Data row group at level 1 -->
<tr>
<td>Key</td>
<th>Item</th>
<td>Description</td>
<td>2 times</td>
<td>25.99 $</td>
<td>51.98</td>
</tr>
<tr>
<td>Key</td>
<th>Item</th>
<td>Description</td>
<td>2 times</td>
<td>25.99 $</td>
<td>51.98</td>
</tr>
<tr>
<td>Key</td>
<th>Item</th>
<td>Description</td>
<td>2 times</td>
<td>25.99 $</td>
<td>51.98</td>
</tr>
</tbody>
<tbody> <!-- Summary row group at level 1 -->
<tr>
<th colspan="5">Subtotal</td>
<td>155.94</td>
</tr>
<tr>
<th colspan="5">Taxes (10%)</td>
<td>15.59</td>
</tr>
</tbody>
<tbody> <!-- Summary row group at level 0 -->
<tr>
<th colspan="5">Total</td>
<td>171.53</td>
</tr>
</tbody>
</table>
For different visual rendering if the attribute "hassum" is present or
not, check http://wet-boew.github.com/wet-boew/demos/zebra/invoice.html
Please see bellow, from my previous email, the revised table API, the
revised Row Group Setup Algorithm and the revised Process Row Group
Headers Algorithm.
On Fri, 28 Sep 2012, Pierre Dubois wrote:
> [...]
>
> 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;
attribute boolean hassum;
>
> 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;
>
> };
> [...]
>
> Proposal: Table Usability Parser Algorithm
> =======================
> [...]
>
> ## 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
* Check if the current row is a summary group and if the table is not
in "hassum" mode
* Mark the current group as a data group
* Use the same data level as the preceding row group
* exit
> * 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.
>
> [...]
>
> ## 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 table is in "hassum" mode Or the number of virtual column
group is lower than the current
> colgroup level
> * Let the current colgroup to be a data column group
* Else 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
* Else 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
>
> [...]
Everything else (table parser algorithm, table API, removal of the
header, removal of the scope attribute) from my previous proposal
email stay the same.
Have a nice day
Cheers
:-)
Pierre Dubois
Received on Saturday, 20 October 2012 02:03:17 UTC