[whatwg] Table integrity and conformance

[Lachlan Hunt]

Ian Hickson wrote:
> I think it would be good to require table integrity. Specifically I think 
> overlapping cells would be a MUST NOT.

That's fine for document conformance, but what about how browsers will 
handle it?  Is the spec still going to require browsers to render 
overlapping cells, or would it be possible to resolve this difference 
between HTML and XHTML rendering, as documented in CSS 2.1 [1]?

Do you have any statistics on the number of sites that depend on 
overlapping cells in HTML?  Could that rendering be removed from 
standards mode (but left in quirks mode) without breaking a significant 
number of pages?

I think the spec should define an algorithm to unambiguously determine 
which rows and columns a cell fits into.  If browsers can calculate 
that, there are 2 benefits I can think of.

1. It would make it easier to implement a :column() pseudo-class (as 
discussed on www-style a few months ago) which would select a cell based 
on it's semantic position.
2. Assistive technology can more accurately determine the header cells, 
especially in non-conforming tables.  (This algorithm should also be 
well defined, see below)

> I don't think there's a problem with missing table cells at the end of rows 
> i.e. a ragged table is fine). 

Agreed.

> I think cells extending (via colspan/rowspan) into columns or rows that 
> contain no cells other than extended cells should be at least a SHOULD 
> NOT, maybe a MUST NOT.

I don't think it should be a must not.  Here's a use case for where it's 
useful to span cells across multiple columns like that.

Consider a online TV guide where columns represent the time and rows 
represent the channel.  The headers for the times could be split into 
half hour time slots, because most shows take up units of half an hours. 
  However, there are some programs that only take 5 or 10 minutes (e.g. 
lottery draws or short news breaks) and to allocate such programs a full 
half hour slot in the table wouldn't be very useful.  Consider this 
markup demonstrating this:

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Cmeta%20http-equiv%3D%22Content-Type%22%20content%3D%22text/html%3B%20charset%3Dutf-8%22%3E%0A%3Ctitle%3ETable%20Cells%3C/title%3E%0A%3Cstyle%3E%0A%09col%20%7B%20width%3A%205em%3B%20%7D%0A%09table%2C%20td%2C%20th%20%7B%20border%3A%201px%20solid%20black%3B%20border-collapse%3A%20collapse%3B%20%7D%0A%3C/style%3E%0A%3C/head%3E%0A%3Cbody%3E%0A%0A%3Ctable%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%3Cthead%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%3E%3C/th%3E%0A%09%09%3Cth%20colspan%3D%226%22%3E20%3A00%3C/th%3E%0A%09%09%3Cth%20colspan%3D%226%22%3E20%3A30%3C/th%3E%0A%09%3C/tr%3E%0A%3C/thead%3E%0A%3Ctbody%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%201%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%225%22%3E20%3A00%20-%2025%20minute%20progr
am%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%221%22%3E20%3A25%20-%205%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A30%20-%2030%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%202%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A00%20-%2030%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A30%20-%2030%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%203%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%2210%22%3E20%3A00%20-%2050%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%222%22%3E20%3A50%20-%2010%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%3C/tbody%3E%0A%3C/table%3E%0A%0A%3C/body%3E%0A%3C/html%3E%0A

> I don't know whether we'll keep the requirement that TFOOTs be above 
> TBODYs.

I agree.  I think that requirement is silly, and most people who I've 
seen use tfoot inevitably put it at the end of the table.  It can also 
be more convenient in a generated table, where a server side script is 
calculating something from the contents of each row in tbody (e.g. a 
total) and then outputting that total in the tfoot.

> COLGROUP span="" will be illegal if the COLGROUP has COLs. COLs 
> and COLGROUPs will probably have a SHOULD NOT requirement about spanning 
> into columns with no actual cells.

Agreed.

> headers="" will have a MUST requirement to point to TH elements in the 
> same table, and will probably only be allowed on TDs.

Maybe.  What about in tables where one th is like a subheading of the 
one above?

> scope="" will probably only be allowed for THs. Maybe it should be REQUIRED for THs that 
> aren't in obvious locations (first row, first column, or whatever).

Maybe.  I think the spec should explicitly define how to determine which 
header cells are associated with each cell.  IIRC, the HTML 4 spec does 
define an algorithm like that, so maybe it could be improved.

> It might be interesting to have some sort of testing with the "axis" 
> attribute too, or maybe we should drop it.

I've never used axis.  I've never seen it used by anyone else.  It 
didn't seem to show up in the Google Web Stats you did previously.  I 
don't know anyone who understands how it can be used or what it's useful 
for.  I don't know any UA, including assistive technology, that supports 
it (though that needs to be verified).  I see no compelling reason to 
keep it, despite the theoretical benefits given in the HTML4 spec.

> (Indeed maybe we should drop some of the others, too.)

I'd say drop all of these because they're either presentational or not 
supported.

* align
* valign
* char
* charoff
* width
* height
* border
* frame
* rules
* cellspacing
* cellpadding

All of these attributes should be kept, because they are supported and 
non-presentational.

TABLE
* summary (supported by screen readers)

TH and TD
* abbr (I think that's supported by screen readers, but need to verify)
* headers
* scope
* rowspan
* colspan

COL and COLGROUP
* span

[1] http://www.w3.org/TR/CSS21/tables.html#q7

-- 
Lachlan Hunt
http://lachy.id.au/