[html5] td and th

[Ian Hickson]

On Tue, 5 Apr 2011, Luis-Miguel Rodríguez Rojas wrote:
> 
> May be an old topic, but I have a conceptual doubt: Why does the <th> 
> element have a Phrasing content model, whilst the <td> element does have 
> a Flow content model?

For the same reason <h1> has a phrasing content model while <section> has 
a flow content model.


On Tue, 5 Apr 2011, Jukka K. Korpela wrote:
> 
> I had not noticed this change (from HTML 4.01 and its predecessors), but 
> I think it is rather natural on semantic grounds. A table header cell 
> contains header information for a column or a row, and header-like 
> elements are generally just text and text-level markup (cf. to <h1> and 
> <caption>, for example). A data cell may contain just about anything, 
> such as text paragraphs, lists, or inner tables, even in a table that 
> represents tabular data (which is a much wider concept than "numeric 
> table").
> 
> Thus, the stricter content model probably helps to detect accidental use 
> of <th> where <td> should be used, as well as markup based on 
> misunderstanding of HTML semantics - assuming, of course, that the 
> author uses suitable software to check the markup.

Indeed.


> The only potential objection that I can imagine for now is that a table 
> header might reasonably act as a tool for sorting or otherwise modifying 
> the data in the table or its rendering. Typically this means just making 
> the header content a link so that e.g. clicking on a particular column 
> header sorts the table so that the column appears in alphabetic or 
> numeric order, and this can be arranged using just text-level markup 
> there (whether we use client-side, server-side, or combined 
> implementation of the operation). But would it be possible that someone 
> reasonably wanted to use a _form_ in a table header cell? I mean a form 
> where the user selects a sorting criterion, for example. Perhaps in the 
> simplest case, the form might consist of a <select> element and (at 
> least when scripting is disabled) a submit button - but to make it work 
> robustly, with a server-side backup, it would need to be a <form>.

You can still do that, just have the form outside the table and point to 
it with form="".


On Tue, 5 Apr 2011, Luis-Miguel Rodríguez Rojas wrote:
> 
> I have one particular example at 
> http://bioinfo-prod.mpl.ird.fr/xantho/x.org/gui/seqterm.php, for which 
> the cells in the second row and the first two columns (or at least the 
> second) could be <th> elements, allowing the definition of scope.  
> However, they contain hidden <div> elements*, which are flow content.  
> This is probably solvable with <iframe> elements, but this may not be a 
> robust solution, would it?

This is a very interesting case. (For those who don't want to look at the 
page, these <div>s are being used as inline rich tooltips, basically.)

I'll have to study this case more closely, especially in the context of 
possible new markup for dialog boxes and rich tooltips.


On Tue, 5 Apr 2011, Jukka K. Korpela wrote:
> 
> In HTML5, the most natural way (ignoring current implementation status 
> for the time being) to have a table header cell with some optionally 
> available additional information would appear to be to use
> 
> <th><details><summary>XYZ</summary>Detailed explanation of XYZ, quite 
> possibly using flow elements.</details></th>

<details> represents a disclosure triangle, which is a similar feature, 
but it's not identical to the rich tooltip thing.


> It might be argued that optionally available blocks of information 
> should be arranged in a completely different manner, partly because 
> embedding them into, say, <th> elements or text-level elements is bad 
> for accessibility and degrades badly: on non-supporting browsers, the 
> entire "optional" block is part of the content in a manner that tends to 
> confuse. Tables get tough if their header cells contain novels. For 
> accessibility, and for graceful degradation, it would probably be best 
> to have something like
>
> <th><a href="...">XYZ</a></th>
>
> possibly with some added elements or attributes that might make it 
> possible to advanced browsers to prefetch the linked resource and show 
> its content upon request in a manner that is essentially smoother than 
> following a link.

Yeah.

Alternatively, we could introduce some element that is used to introduce 
data like this, which future ATs would ignore. It wouldn't have a good 
legacy fallback story, unfortunately.

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