[OT] Re: Systematic approach to layout table heuristics

OFF TOPIC

On Feb 21, 2014, at 3:13 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote:

> 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.

Keep reading… There is more than that. If it ends up with a grid role it is a data table, but specific implementation details are probably off topic for the general subject of this discussion. I just referenced that file as a starting point.

> 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 Saturday, 22 February 2014 00:32:59 UTC