- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Wed, 29 Oct 2003 22:19:04 +0000 (GMT)
- To: www-html@w3.org
> particular issue faced when creating a table in HTML/XHTML. The issue > is with creating a table that has a number of sub-sections. After the The more I think about this, the more I come to the conclusion that you want new presentational features at a time when such features are being removed. Your sub-headings are control-break headings in report writer terminology and represent a denormalisation of the data. In a purely semantic representation of the data, they are logically an extra column of TH elements. You can denormalise such a column, even in HTML as it is at present, by using rowspan. Shifting the contents of such a column to above row groups ought to be considered styling, as should doing the control break logic to infer the denormalised form. Even if you don't buy the semantic purity argument, report wrtiers generally allow multiple levels of control break, so you need a fuilly recursive structure (as already pointed out). Also, it is not uncommon, I believe, to repeat control break headings on each printed page, so the option to include them in a THEAD type context would be needed. I'd say if you were keeping your composite layout/data table format, you would need to use TR and TH, not CAPTION, and to allow recursive use of the whole THEAD/TFOOT/TBODY group, with the expected styling being to accumulate the contents of all open THEADs and TFOOTs when constructing page headers and footers for printed media. I did notice, in the examples, a failure to use TH for the subheadings, which may represent a misunderstanding about TH and the use of <p> </p>, which suggests a rejection of styling. In relational terms, one would expect a candidate key to be marked with TH in the rows. The other factor to remember, always, is that HTML sits at the simple end of document markup languages so features have to be the sort of feature that the majority of users will use reasonably regularly; might this feature be better suited for a more sophisticated language.
Received on Wednesday, 29 October 2003 17:25:32 UTC