[whatwg] Feedback on a variety of elements

[Ian Hickson]

On Mon, 31 Dec 2012, Pierre Dubois wrote:
> On Fri Dec 14 2012, Ian Hickson wrote:
> > 
> > I don't think this works for all tables. For example, the first 
> > example in the spec in the <th> element's section does not get handled 
> > correctly by your algorithm -- it treats the ID column as important, 
> > instead of the second column.
> 
> [Maybe I] did not [use] the correct word to identify that kind of cell 
> that I named "Key cell". The objective of the "Key cell" is to identify 
> a "td" cell that have [...] relationships to a "th" cell at his right 
> side in the same row. The "td" rowspan attribute would need to match or 
> be lower than the corresponding "th". The inverse would show a data cell 
> "td" used as an heading cell "th".

If I understand correctly, you mean that you want to be able to 
automatically determine that the <th> here is a heading for the <td>:

  <table>
   <tr>
    <td> <th>
  </table>


> The current relationships algorithm create a relationship for the 
> preceding "th" cell not following "th" cell.

Assuming you mean the one in the spec today: correct. That's partly 
because you never want to do this vertically, and the algorithm is 
direction agnostic (it uses the same steps for going left as going up), 
and partly because it's not clear how often you want to do this going left 
either. In particular, sometimes tables are of the form:

   +-------------+-------------+-------------+-------------+
   | Header      | Data        | Header      | Data        |
   +-------------+-------------+-------------+-------------+

...where the header cells are headers for the data to the right.

Or, in a more difficult case to handle:

   +-------------+-------------+--------------+-------------+
   | Header v    | Header v    | Metaheader v |             |
   +-------------+-------------+--------------+-------------+
   | Data        | Data        | Header >     | Data        |
   +-------------+-------------+--------------+-------------+
   | Data        | Data        | Header >     | Data        |
   +-------------+-------------+--------------+-------------+


> > Without the scope="" attributes, I don't think that table would make 
> > much sense.
> 
> You have right that the proposed algorithm, for the first example in the 
> spec in the <th> element's section does not get handled correctly.
> 
> The question is: Why from a visual point of view, by excluding any 
> styling, can you feel that "Cats" cell and the "English speakers" cell 
> is know as a row group as highlighted in the source code with the scope 
> attribute set to "rowgroup"?
>
> My answer is: Because the header cell is surounded by empty data cell in 
> his row. For me that represent a mix of a layout table combined with a 
> data table. A quick fix to the proposed algorithm would be at the end of 
> the data row processing, do a test to know if the header cell is 
> surrounded by empty data cell, that until the first real data row is 
> found in the rowgroup (tbody) section. If that is true, the header cell 
> scope can be determined as a rowgroup header and the surrounded empty 
> data cell can be know as layout cell. Is that make sense? Have you 
> another visual logic regarding that case?

I don't know that we really need, or want, to make the current algorithm 
more "magic" than it already is. There's a point of diminishing returns 
where the complexity makes it too hard to debug. The algorithm is already 
pretty complex, maybe too much so; making it even more complex seems like 
a bad idea.


> > > Proposal: Table Usability API
> >
> > This is a very elaborate and large API. What are the use cases against 
> > which to evaluate it? i.e. what problem does it solve?
> 
> The main use case is to parse a complex table and extract the data in 
> the objectif to create an accessible (WCAG 2.0 Level AA compliant) chart 
> by using the progressive enhancement strategy. The use of the table to 
> create the chart remove the need for an web author to discus and 
> sometime debate with the content provider in the objectif to build a 
> descriptive text alternative version of the chart.

Why can't this be done in script already? I don't understand why we need 
an API for this.


> Also the proposed Table Usability API is not just to handle complex 
> table. The proposed API provide support access the tabular data either 
> by his row or by his columns. Sometime, for presentational purpose, the 
> axes are reversed.
> 
> As an example took the following two row table. Do you think, for 
> presentational purpose, it will be better have a two column table 
> instead? I think both table, with equivalent structure, should be 
> supported and have an equivalent accessible API.
>
> [long table]

It's not clear to me that you need an API at all. The DOM API seems 
sufficient for this example. I mean, people hardly use the API we have 
already, why add another one, especially a big one? It just doesn't seem 
like a compelling enough problem for us to try to solve it.


> > On Fri, 19 Oct 2012, Pierre Dubois wrote:
> > >
> > > 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.
> >
> > A summary group is just a group with a heading saying it's a summary 
> > group, no? I don't really understand what is special about a summary 
> > group. How should software treat it differently?
> 
> Sometime a summary group is not clearly identified by using a cell 
> heading (th) but it is often identified by using the styling. From an 
> accessibility (WCAG 2.0) point of view, by using styling to define those 
> summary group make it fail the Success Criterion 1.3.3 (Level A) 
> "Sensory Characteristics" 
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html

We don't want to derive semantics from styling, that's a layering 
violation. The style should come from the semantics.


> Here a simple common example where a summary group do not have a heading 
> saying it's a summary group.
> 
> <table hassum>
> <caption>Invoice</caption>
> <thead>
> <tr>
> <th>Item</th>
> <th>Price</th>
> </tr>
> </thead>
> <tbody>
> <tr><th>Product 1</th><td>25.00</td></tr>
> <tr><th>Product 2</th><td>60.00</td></tr>
> <tr><th>Product 3</th><td>15.00</td></tr>
> </tbody>
> <tbody class="summary">
> <tr><th>Sub Total</th><td>100.00</td></tr>
> <tr><th>Federal Taxes</th><td>5.00</td></tr>
> <tr><th>Provincial Taxes</th><td>10.00</td></tr>
> </tbody>
> <tfoot>
> <tr><th>Total</th><td>115.00</td></tr>
> </tfoot>
> </table>
> 
> The summary group concept can be useful to spec a responsive table 
> concept. For example, an user agent could hide some data group to reduce 
> the table space taken in view port. So in the previous "Invoice" table, 
> the user agent could hide the first row group and provide a mechanism to 
> display it, if requested by the user.

I don't understand why this is particularly useful. Anyone browsing the 
table can already find that it has a row labeled "Sub Total". Why would we 
need another way of doing it as well?

There's a near-infinite variety in the kinds of tables out there. It's not 
clear to me that there's much to be won by increasing the ways in which 
they can be marked up so as to let HTML handle a slightly greater number 
of those tables. We already handle the bulk acceptably well; if there are 
more tables we should handle, we need to first document how common they 
are and why dedicated markup would be worth the effort.

Adding features is not free.

   http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94


> > > 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.
> >
> > I would be very surprised if such an attribute was used correctly a 
> > useful fraction of the time.
> 
> If the responsive table is spec by having summary group, then I am sure 
> it would used correctly or at least to get the espected behaviour.

I'm not. Authors have great trouble using markup correctly at the best of 
times. When the markup doesn't really _do_ anything, they are _terrible_ 
at it. Just look at how much trouble authors have using <td> vs <th>.


> > On Tue, 6 Nov 2012, Pierre Dubois wrote:
> > >
> > > Use case: Draw a graphic based on a data table * Like a pie chart, 
> > > based on a sub-set of data contained in a data table.
> >
> > This is an interesting use case. Do any sites actually try to do this 
> > today?
> 
> Any website that use the Web Experience Toolkit chart plugin 
> (https://github.com/wet-boew/wet-boew/wiki/Charts-and-graphs) and any 
> website that use the Filament Group chart 
> (http://www.filamentgroup.com/examples/charting_v2/)

How many pages is that? It would have to be a lot of pages to justify 
building it into the browser -- is there some reason the libraries aren't 
sufficient for the current volume of usage?

I mean, as I showed in my last e-mail, doing this by hand is already 
pretty easy:

> > I tried writing an example to do this, and it's not clear to me that 
> > the API is particularly hard to use. Somewhat verbose, granted, but it 
> > only took a few lines of code, most of which is spent in canvas logic 
> > and in the CSS styles to make the table presentable:
> >
> >   http://damowmow.com/playground/demos/tables/002.html
> >
> > That's an admittedly simple table; what kinds of tables are people 
> > generating pie charts out of? Are they more complex? Do you have any 
> > examples we could study?


> Generating client-side chart help about the Web Content Accessibility. 
> Generating client-side chart save money. It is faster to change a data 
> cell value of a HTML table instead of updating a non HTML data table 
> (like MS Excel), generating a new chart image, add the corporate look, 
> update the text alternatives version, upload the image, update the 
> webpage, ...

Sure. But generating client-side charts is already possible. The question 
is what is it that is not possible, or is hard to do today, that we can 
address with some new API or markup features, and how widely would such a 
feature be used (it has to be enough to justify the cost), and would the 
features actually be used correctly, etc.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'