[html5] td and th

[Jukka K. Korpela]

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.

The page looks complicated, but if I get the idea right, some <th> elements 
have associated detailed information that becomes available on request, e.g. 
on mouseover. That's an increasingly common arrangement, and the detailed 
information is often very much block-like, but this is basically an argument 
in favor of allowing flow content virtually everywhere. For example, a poor 
lonesome <span> or <i> element inside a text paragraph might have associated 
information, such as an explanation of a key concept or statement.

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>

... except that it's not allowed by the syntax rules. But similarly we 
cannot use, say, <details><summary><i lang="la">status quo</i></summary> An 
explanation of the phrase and its current meaning</details> inside a text 
paragraph.

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.

> I don't find convenient to place <select> and <button> elements
> within a <th>, but not <form>s (at least when no scripting).  Does it
> mean that the <form> element should be placed on top of the <table>
> element?  What if one wants to define different <form>s for different
> <th> / <td> elements in the same <table>?

Well, in my scenario, we could place the entire <table> inside a single 
<form>, but that would force us to write the server-side form handling as a 
single program that first detects how it was called.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/