This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1181 [details] Javascript Table Parser Hi, In the Editor's Draft 4 September 2012, "Section 4.9.6 The thead element" show a method about on how to add a description to a column header cell. The "algorithm for assigning header cells" defined in the "Section 4.9.12.1 Forming a table" do not add any particular meaning to those describing cell because they are parsed with the "internal algorithm for scanning and assigning header cells", the same algorithm for parsing the real data cell. This can create a confusion between the real data cell vs. the describing cell in a table because the "internal algorithm for scanning and assigning header cells" are not considering any column group and/or any row group. ---- Describing cell for a row header cell I would like to propose an addition in the specification about on how to add a description to a row header cell in a data table. That relation can be made by using the colgroup element. See the draft of that technique: http://wet-boew.github.com/wet-boew/docs/tableparser/rowheader-description-techniques.html (FYI, the intention of that technique is for submission to the WCAG 2.0 Techniques) A note in the section "4.9.3 The colgroup element" can be added to say "the first column group (colgroup element) can be used as an header column group if inside the column group there are at least one row header cell defined inside a tbody row group. Otherwise the first column group would be a data column group." With that note, it would be possible to set a descriptive cell to a row header cell. ---- Attached: A javascript table parser that takes in consideration the row group, the column group and the placement, size of the header cell to create the relationship between each cell contained in a table. You can find the most recent version here: https://github.com/wet-boew/wet-boew/blob/master/src/js/workers/parser.table.js The following table validator use the preceding table parser. http://wet-boew.github.com/wet-boew/docs/tableparser/validator-htmltable.html FYI - Here a mailing sent to WAI Interrest Group about a request for comments in regards of the techniques mentioned here. http://lists.w3.org/Archives/Public/w3c-wai-ig/2012JulSep/0310.html Thank you :-) Pierre Dubois
See my proposal about the Table Usability Concept here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037475.html :-)
Moving this to HTML.next as we work to lock down HTML5.0 for CR.
For future reference, it appears that some of the broken links below can be fixed by substituting "demos" for "docs" in the path. E.g., http://wet-boew.github.com/wet-boew/docs/tableparser/rowheader-description-techniques.html Is now at: http://wet-boew.github.com/wet-boew/demos/tableparser/rowheader-description-techniques.html
Mass move to "HTML WG"
assigning this to Ian as it looks like something he would better be able to respond to.
I don't understand the problem here. Can you describe the problem, separate from the proposed solution, ideally with a concrete example?
> Can you describe the problem, separate from the proposed solution, Define and support explanation column in a table. > ideally with a concrete example? * Hide the explanation cell to save space in the view port. Example: Show a simplified version of the table on a mobile device or on small screen. * Be able to provide an alternative way to show explanation cell. Example: Show the explanation in a tooltip when hovering the cell header. * Avoid confusion between a tabular data cell and an explanatory data cell. Example: During cell iteration in a table rows from the DOM Interface to create a new object (charts) from the data.
(In reply to comment #8) > > Can you describe the problem, separate from the proposed solution, > > Define and support explanation column in a table. I don't understand what this means. What is an "explanation column"? Is it just a column with cells that contain text? > > ideally with a concrete example? > > * Hide the explanation cell to save space in the view port. Example: Show a > simplified version of the table on a mobile device or on small screen. This can be done today using visibility:collapse (that's in fact the reason that value exists); why is it insufficient? > * Be able to provide an alternative way to show explanation cell. Example: > Show the explanation in a tooltip when hovering the cell header. This can be done today as well, using title="". > * Avoid confusion between a tabular data cell and an explanatory data cell. Confusion by whom? > Example: During cell iteration in a table rows from the DOM Interface to > create a new object (charts) from the data. Wouldn't such a script know exactly which cells were data and which weren't? Could you show an example of a real Web page that demonstrates this problem? I'm really having trouble understanding what the issue is.