Re: Systematic approach to layout table heuristics

When Webkit says ”data table” does it mean the same as the proposed 
role=table?

I ask a) because HTML5 talks about ”non-layout” vs ”layout” and b) 
because I myself came to the conclusion that ”non-layout” could be 
applied to anything that isn’t ”layout”. Thus, <table role=grid> is a 
non-layout table. However, Webkit, while not disagreeing, says that, 
quote: 

 ”// Do not consider it a data table is it has an ARIA role.”

First, this rule obviously will not be true once role=table emerges.

Second, this means that Webkit categorizes differently from how the 
spec categorizes. So, to base anything on Webkit,  either the spec must 
reinterpret what Webkit does, in order to decide what it means in spec 
context. Or that the spec should stop talking about ”non-layout”.

It seems to me that it would be useful if the spec more aligned itself 
with Webkit and thus start speaking about data tables instead of 
non-layout table. This will also allow us to speak about non-data 
non-layout tables. And thus the spec would become more specific.

Leif H Silli

James Craig, Fri, 21 Feb 2014 10:29:36 -0800:
> 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

> 
> 
> On Feb 21, 2014, at 2:19 AM, Leif Halvard Silli wrote:
> 
>> After filing bug 24679 [1], which suggests to add more features to the 
>> list of ”possible indicators”[2] for layout tables vs non-layout 
>> tables, I was asked to provide data for the proposals. But how should 
>> one go about providing data?
>> 
>> Web data is of what ultimately matters. But when identifying possible 
>> indicators, it seems that knowing what features AT actually use for 
>> discerning between layout and non-layout tables, would give us a good 
>> shortlist of candidate indicators. Secondly, if we can spot some trends 
>> in the (hopefully correct) data we already have, then that - as well - 
>> could help us identify candidates. 
>> 
>> Today, its appears possible to glean following trends in the spec:
>> 
>> 1) Conformance, completeness amd semantics indicate non-layout
>>   usage. The spec lists borders via CSS or @border=1, <th>,  
>>   <thead>, <caption>, @headers, @scope.
>> 2) Non-conforming ways to disable borders (border=0/cellspacing=0
>>   cellpadding=0) plus role=presentation indicate layout usage.
>> 3) @summary is ”not a good indicator” (this is probably based
>>   *both* on Web data *and* AT behavior analysis
>> 
>>   Trends & AT data applied to: table@border
>> 
>> To me, HTML5’s table over “possible indicators” of (non-)layout usage, 
>> seems correct, but not complete. However, in bug 24678,[3] Steve asks 
>> for data about *one* non-layout indicator, namely border=1. But which 
>> data? Web data? Assistive technology data? The fact that VoiceOver + 
>> Safari matches spec w.r.t. borders as non-layout indication, ought to 
>> put it on the shortlist of non-layout features. In another, somewhat 
>> related, bug, Steve indicated that web data did not support that 
>> table@border=1 indicates data tables.[4] My own toe dipping into same 
>> pool told me the opposite.
>> 
>>   Trends & AT data applied to: <colgroup> with <col/> children.
>> 
>> It seems in line with the conformance & completeness trend that 
>> VoiceOver+Safari treats <colgroup> with <col/> children[*] as indicator 
>> of non-layout usage. What do other ATs do? What does Web data say? 
>> Should the spec change accordingly? (PS: I know one HTML generator 
>> which, for layout tables in XHTML1/HTML4, uses cellpadding=0 
>> cellspacing=0, but which for HTML5 removes cellpadding/cellspacing and 
>> *adds* <colgroup> with children, with bad results in VoiceOver as 
>> result.)
>> 
>>   Trends & AT data applied to: lack of cellpadding=0 cellspacing=0[*]
>> 
>> Is it risky to delete cellpadding=0 cellspacing=0 from a table? 
>> Could it cause an AT to treat a layout table, as a non-layout table? 
>> This question seems relevant since authors are probably simply deleting 
>> these attributes without adding @role=presentation in their place.
>> 
>>   Trends & AT data applied to: presence of sortable attribute
>> 
>> This is good candidate based on its strong link to data tables - it is 
>> a semantic feature. But is is also possible to take the view that we 
>> need implementation and usage before putting into the spec.
>> 
>> Finally: How important are heuristics for identifying data tables? Does 
>> the situation remind about how UAs detect quirks vs no-quirks? (Except 
>> in XHTML and @srcdocs (other exceptions?), no-quirks is triggered when 
>> UAs detect a DOCTYPE that meets certain conformance and completeness 
>> criteria.)
>> 
>> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24679

>> [2] 
>> 
http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element

>> [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24678

>> [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24647#c7

>> [*] I did not check omitting <col/> child or omitting parent <colgroup>
>> -- 
>> leif halvard silli
> 
>

Received on Friday, 21 February 2014 23:13:50 UTC