No block elements in HTML5 table header cells

["Bob Stayton" <bobs@sagehill.net>]

I'm working on implementing an HTML5 stylesheet for docbook in preparation for 
supporting the new EPUB3 standard.  I've encountered a change for HTML5 that I'm not 
sure how to handle.

In HTML4, the table elements th and td had the same content model, which what quite 
broad and included block and inline elements (which the W3C calls flow and phrasing 
elements).  In HTML5, the td element retains the broad content model, but the th 
element is now restricted to phrasing elements: text and inline elements.  This seems 
like a pretty big backwards incompatibility, so I'm not sure why they did it.  Perhaps 
one of the W3C participants reading this email can explain why?

DocBook markup permits many kinds of block level content inside an entry in thead, and 
any thead cells are currently converted to th for HTML output.  That would generate 
invalide HTML5 output.

The HTML tr row element still allows any mix of td and th, regardless of whether the 
row appears in a thead or tbody.  So this problem can be addressed in DocBook XSL in a 
couple of ways:

1.  Never use the th element, always use td, even when the row is inside thead.  Since 
the td element supports block content, this would be compatible with DocBook.  But any 
CSS that styles based on the th element name would not work for such output.  The CSS 
would have to change to match on thead/tr/td instead.

2.  When processing a thead entry element, check its content to see if it has block 
content.  If not, then use th, otherwise use td.  While this matches the content 
models better, it could create a thead row that contains a mix of th and td.  That 
could lead to odd formatting problems in CSS.  Since the CSS would need to handle both 
td and th inside thead rows, we might as well use option 1 (only td).

3.  Always output th elements inside thead rows, but have the stylesheet try to make 
valid content out of the input by processing block content into phrases.  While this 
might work for a couple of para elements in an cell, this would likely make a mess of 
most such content.

I'm leaning toward option 1, and I'm open to further suggestions.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net