|Paul Grosso wants us to drop a simple format string in favor of
|a much lengthier way of specifying exactly the same information.
|
|For instance:
|
| <table colspec="L1 C2 C2 L4" units=relative>
|
|becomes:
|
| <table>
| <COLSPEC colname=1 colwidth="1*" ALIGN=LEFT>
| <COLSPEC colname=2 colwidth="2*" ALIGN=CENTER>
| <COLSPEC colname=3 colwidth="2*" ALIGN=CENTER>
| <COLSPEC colname=4 colwidth="4*" ALIGN=LEFT>
|
|The motivation given is:
|
|> I would like to see HTML adopt the CALS subset. Not only does this have
|> the advantage of existing implementations as well as years of experience
|> understanding its semantics, but it has an obvious enhancement path when
|> HTML wants real headers and footers, multiple tgroups, individual rule
|> segment types, etc. I hope my presentation shows that it isn't much more
|> complex than Dave's model.
|
|The semantics of the current HTML 3 proposal seem clear enough, and the
|Internet Draft (see http://www.hpl.hp.co.uk/people/dsr) shows how you
|can subclass rows for real headers and footers etc. The treatment of
|these is browser dependent of course - what's appropriate for Windows
|won't be for speech output!
|
|Given, that the philosophy of HTML is to keep it simple, and that
|significant numbers of people will want to continue to edit HTML
|directly, why should we complicate HTML for the sake of minor
|simplifications to CALS filters?
I agree with Dave here:
- TGROUP and TBODY seem rather redundant. If tables are related, we
can always put <DIV>..</DIV> around them.
- Dave's COLSPEC is both more compact and easier readable.
- It is useful to distinguish between TH and TD (and easier for the
style sheet writer).
- ROWSPAN is IMHO easier to understand than MOREROWS.
- COLSPAN is relative, whereas NAMEEND is absolute, the former is
therefore both easier to write and to maintain. And moreover,
COLSPAN makes is impossible to specify illegal values (a cell that
ends before it starts!?)
- ROWSPAN and COLSPAN are nicely symmetrical.
- NAMEST is either redundant or it creates invalid tables.
- Using a CLASS attribute to mark a row as header/footer seems
better than introducing new elements; it simplifies the parser but
still allows a style sheet to render the row differently.
But I would argue for an extra rule to disallow overlapping cells,
viz.: "cells cannot overlap, if necessary cells are moved to the
right." In the case of COLSPAN > 1, this could leave empty cells, but
it would completely remove the possibility of invalid tables, and
therefore of undefined behaviour.
Dave's
/-------------------\
| 1 | 2 | 3 | 4 | 5 |
| |---------------|
| | 6 | | | | The cells labelled 6 and 7 overlap!
|---|...|-----------|
| 7 : | 8 | | |
\-------------------/
would become
+---+---+---+---+---+
| | 2 | 3 | 4 | 5 |
| 1 +---+---+---+---+
| | | | | |
+---+ 6 +---+---+---+
| | | 7 | 8 | Cell 7 had to be moved right!
+---+---+-------+---+
(see <URL:http://www.hpl.hp.co.uk/people/dsr/html/tables.html>)
There are some easy ways to improve the look of tables in such a way
that browsers can ignore them if they wish:
1. more values for the BORDER attribute.
2. a BORDER attribute on TR, TH, and TD, as well as on TABLE.
PS. Why isn't BASELINE the default value for VALIGN, it seems more
natural?
PPS. I don't understand the meaning of AXIS and AXES, aren't they
redundant? Dave, can you explain please?
|
|-- Dave Raggett <dsr@w3.org> tel: +44 117 922 8046 fax: +44 117 922 8924
| Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom
|
--
Bert Bos Alfa-informatica
<bert@let.rug.nl> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN