This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
PROPOSAL: Improve the table that describes the heuristics for determening whether tables are layout tables or non-layout tables by adding more attributes (e.g. table@sortable, table@rules, table@frame, td@axis, etc) and verifying that the effects already described are accurate. SITUATION: The table basically lists some attribtues, and describe each attribute’s most probable effect in heuristic analysis. Both conforming and non-conforming attributes ar listed. And for the conforming attributes, both confonforming values (e.g. border=1) and non-conforming values (e.g. border=0) are listed. NEW INFO: Data regarding tabl@border: In bug 24647, 7th comment, Steve provided some data which he claims questions that the best heuristic effect of table@border=1 is that it is a non-layout tabel <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24647#c7>. However, in comment number 13, 15, 16, 17 and 20, I analysed some of Steve’s data and concluded that it included many incorrect matches (such as frameborder=1 and <img border=1) and that for the correct matches, it was questionable that the data supported Steve’s claims <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24647#c13> However, further analysis might show that Steve’s data could allow us to improve on what the spec states about table@border and layout vs non-layout tables. Data regading table@sortable: HTML5 has recenly introduced table@sortable, which should count as indication (in an heuristic analysis) that the table is a non-lalyout table. Evidence: This is a feature for data tables. Regarding table@rules, table@frame: HTML4 had table@rules and table@frame, both of which should coount as indication (in an heuristic analysis) that the table is a non-layout-table. The attribute’s effects are such that they are unlikely to be used in layout-tables. (With the possible exception of rules="none" and frames="void" - but in that case *only* if there is no conforming border attribute.) Evidence: These are features for data tables. They are somewhat similar to table@border in that they affect borders. Regarding td@axis (and th@axis ?): HTML4 had the td@axis, which was for use in data tables. Evidence: This is a feature for data tables. Regarding a number of other attributes: If <table>, <tr>, <tbody>, <td> etc includes a @lang attribute, likelyhood is that it is a non-layout table. This claim is based on deduction. Evidence: When @lang is added, one should think that the use of tables is a conscious choice and not just a result taking advantage of the layout grid effects of tables.
th@abbr should increase the likelyhood the table is a non-layout table. It seems possible to suggest an algorithm for when tables are layout vs non-layout tables. For instance, the spec currently says that a <th> is indication that the table is a non-layout table. If the <th> *also* has an abbr attribute, then that increases the likelyhood that it is a non-layout table.
(In reply to Leif Halvard Silli from comment #0) > Data regarding tabl@border: In bug 24647, 7th comment, Steve provided some > data which he claims questions that the best heuristic effect of > table@border=1 is that it is a non-layout tabel > <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24647#c7>. ... > analysis might show that Steve’s data could allow us to improve on what the > spec states about table@border and layout vs non-layout tables. CSS borders: If table@border is put under scrutiny with regard to its effect on layout table heuristics, it would also make sense to put under scrutiny the spec’s claim about borders via CSS: ”Explicit visible borders set using CSS | Probably a non-layout table” Zebra striping via CSS nth-child pseudo selectors, e.g. tr:nth-child(odd){background:lime}, should count as indication htat the table is a non-layout table.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: needsinfo Change Description: no change Rationale: a number of assertions are made about the usefulness of attributes to indicate whether a table is a data table or not, please re-open the bug when you have provided some quantitative data to support these assertions.
(In reply to steve faulkner from comment #3) > Status: needsinfo > Change Description: no change > Rationale: a number of assertions are made about the usefulness of > attributes to indicate whether a table is a data table or not, please > re-open the bug when you have provided some quantitative data to support > these assertions. I am not a mechanical duck that does whatever I am told. I need to understand why am supposed to do something. You ask me to provide quantitative data. Please convince why only quantitative data matters. For instance, it borders on absurd to ask for quantitative data for why table@sortable should not count as evidence for non-layout table. Further more, as this this bug also points to table@border, based on a collection of data provided by yourself, be aware that you with the above statement also dismisses your own data. I reopend this bug to have you 1) reevaluate wheter only quantiative data matters 2) to have provide an evaluation of the claims made.
(In reply to Leif Halvard Silli from comment #4) > (In reply to steve faulkner from comment #3) > > > Status: needsinfo > > Change Description: no change > > Rationale: a number of assertions are made about the usefulness of > > attributes to indicate whether a table is a data table or not, please > > re-open the bug when you have provided some quantitative data to support > > these assertions. > > I am not a mechanical duck that does whatever I am told. I need to > understand why am supposed to do something. > > You ask me to provide quantitative data. Please convince why only > quantitative data matters. For instance, it borders on absurd to ask for > quantitative data for why table@sortable should not count as evidence for > non-layout table. > > Further more, as this this bug also points to table@border, based on a > collection of data provided by yourself, be aware that you with the above > statement also dismisses your own data. > > I reopened this bug to have you > 1) reevaluate wheter only quantiative data matters > 2) to have provide an evaluation of the claims made. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: needsinfo Change Description: no change Rationale: a number of assertions are made about the usefulness of attributes to indicate whether a table is a data table or not, please re-open the bug when you have provided some quantitative data to support these assertions. For table@sortable we have no known implementations or known usage data, when information on either of these is available feel free to re-open. "Regarding table@rules, table@frame: HTML4 had table@rules and table@frame, both of which should coount as indication (in an heuristic analysis) that the table is a non-layout-table." Have these been shown to have been used on data tables with more frequency than on non data tables. have they been used with sufficient frequency that they provide a useful heuristic, or would the addition of checking for use of such a feature add unnecessary complexity without benefit? if you have new information to answers such questions please re-open. in regards to border i earlier opened a separate bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=24678 "Regarding td@axis (and th@axis ?): HTML4 had the td@axis, which was for use in data tables. Evidence: This is a feature for data tables." my understanding is that the usage of this attribute was negligible, if you have information to the contrary it may be worth adding, if so please re-open "Regarding a number of other attributes: If <table>, <tr>, <tbody>, <td> etc includes a @lang attribute, likelyhood is that it is a non-layout table. This claim is based on deduction. Evidence: When @lang is added, one should think that the use of tables is a conscious choice and not just a result taking advantage of the layout grid effects of tables." the reasoning doesn't follow, for me. Providing information on use of @lang on data tables vs non data tables would be a useful data point, if you have some please re-open.
What you say about table@sortable strikes me as *incredible* passive. I would propose that you count this a evidence, now, that it is non-layout table usage, and remove that assertation from the spec if the authors starts to do it totally wrong.
(In reply to Leif Halvard Silli from comment #6) > What you say about table@sortable strikes me as *incredible* passive. > > I would propose that you count this a evidence, now, that it is non-layout > table usage, and remove that assertation from the spec if the authors starts > to do it totally wrong. hi leif, If something is not implemented I don't see why it should be added as a suggested heuristic, you may think that passive, your opinion is noted.
(In reply to steve faulkner from comment #7) > If something is not implemented I don't see why it should be added as a > suggested heuristic, Is it mportant to spare AT vendors from thinking about the heuristic effect of @sortable until it has browsers support it and authors use it? If the answer is yes, then your approach makes sense. However, I disagree that that is a good approach beacause I think the spec, for new features, should describe the situation we want to end up with. As implementation takes place - or not - the spec should modify what it says, to match actual implementations, including remove @sortable - from the list of content attributes and from the tabe over layout table heuristics. I suppose the vendors that make use of the heuristics are also aware of the implementation status They might choose to postpone the heuristics until their AT supports @sortable anyway. But I don’t see why this should make us not describe the intended - or most likely - heuristic effect. For other, new features, the default accesibility related features (such as ARIA features) are added in tandem with the very feature itself. E.g. you did not poostpone defining the default @role value for the element <main> until there was evidence that authors used it and browsers had implemented it.
I would add that actual uses of a feature, even if they are side effect in a sense, could boost authors using them (maybe starting with polyfill scripts emulating the intended effect) and as a consequence, vendors will find a way to natively implement the aforementioned feature. It has been done this way for new form controls. Everything starts from an invention and its possible uses. For HTML5 it has always been that way.
http://lists.w3.org/Archives/Public/public-html-a11y/2014Feb/0063 James pointed to Webkit: > Just copy what the open source browsers are doing already. For example: > > AccessibilityTable::isDataTable() > http://trac.webkit.org/browser/trunk/Source/WebCore/accessibility/AccessibilityTable.cpp#L93 What Webkit does, based on that page (summary based on code comments): 1) [L.98] Table is not data table if @role is present. 2) [L.102] Except if table is inside contentEditable secion = always data table 3) [L.108] Heuristic section. Assumption: table is not data tab. unless data table signals present [L.117] CAPTION/@summary/THEAD/TFOOT = most certainly a data table [L.122] // if someone used "rules" attribute than the table should appear [L.126] // if there's a colgroup or col element, it's probably a data table. [L.132] // go through … cell's … check for tell-tale signs of "data" table … // … borders, or … attributes like headers, abbr, scope or axis [L.142] // If there's only one cell, it's not a good AXTable candidate. [L.146] // If there are at least 20 rows, we'll call it a data table. [L.150] Zebra striping and other signals: // Store … background color of … table to check against cell's background … // check enough of the cells to find if the table matches our criteria // Criteria: // 1) must have at least one valid cell (and) // 2) at least half of cells have borders (or) // 3) at least half of cells have different bg colors than the table, and there is cell spacing [L.189] // first row is comprised of all <th> tags, assume it is a data table [L.193] // first column is … all <th> tags, assume it is a data table. [L.197] explicitly assigned a "data" table attribute [double checking to see if @abbr, @axis, @headers, @abbr is empty????] [L.206] // If the empty-cells style is set, we'll call it a data table [L.210] //If a cell has matching bordered sides, call it a (fully) bordered cell. [L.215] // Also keep track of each individual border, so we can catch tables where most // cells have a bottom border, for example. [L.226] // If the cell has a different color from the table and there is cell spacing, // then it is probably a data table cell (spacing and colors take the place of borders). [L.230] // If we've found 10 "good" cells, we don't need to keep searching. [L.237] // For the first 5 rows, cache the background color so we can check if this table has zebra-striped rows. [L.256] // if there is less than two valid cells, it's not a data table [L.260] // half of the cells had borders, it's a data table [L.269] // half had different background colors, it's a data table [L.273] // Check if there is an alternating row background color indicating a zebra striped style pattern. [L.299] // If the developer assigned an aria role to this, then we // shouldn't expose it as a table, unless, of course, the aria // role is a table.
(In reply to Leif Halvard Silli from comment #10) Regarding the code comment on line 299 ... > [L.299] // If the developer assigned an aria role to this, then we > // shouldn't expose it as a table, unless, of course, the aria > // role is a table. ... then James informed me that ”role is a table” or ”TableRole” is, quote: ”the internal WebKit role that most closely corresponds to grid”
http://lists.w3.org/Archives/Public/public-html-a11y/2014Feb/0069.html Steve pointed to Firefox (no summary, for now): > Firefox > IsProbablyForLayout > http://mxr.mozilla.org/mozilla-central/ident?i=IsProbablyForLayout
Link to Alex’ blog post about data table heuristics in Firefox: http://asurkov.blogspot.ca/2011/10/data-vs-layout-table.html
Is the point of the bug we should put the spec's table [1] into sync with browser's implementation? (or vice versa) [1] http://www.w3.org/html/wg/drafts/html/master/semantics.html#attr-table-border
HTML5.1 Bugzilla Bug Triage: This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).