> > From: Bert Bos <bert@let.rug.nl>
> > To: Multiple recipients of list <html-wg@oclc.org>
> > Subject: Attempt at HTML 2.1 (tables)
> >
> > The current consensus seems to be that between HTML 2.0 and 3.0 there
> > ought to be small, incremental steps, so that eventually nothing
> > controversial remains for HTML 3.0.
> >
> > So here is my attempt at defining such a small, incremental step. The
> > only thing it does is to allow a TABLE element everywhere that a P is
> > allowed, bringing HTML to version 2.1.
> >
> > The table syntax is very simple, with even less attributes than the
> > ones in HTML 3.0, but that may well be enough for HTML.
> >
>
> I agree with the idea of an HTML 2.1 that equals 2.0 plus tables.
> Thanks for doing this, Bert.
>
> I know lots of folks have spent a lot of time discussing tables in
> email and face-to-face, and I am initially concerned that this proposal
> seems to ignore much of the results of that conversation. Despite the
> fact that the table model in some of the latest HTML 3.0 drafts has
> features that I don't like, I'm willing to consider it the result of
> the closest thing we have to date to at least quasi-consensus. I
> suspect you thought that subsetting the latest 3.0 model would make
> it easier to accept for 2.1, but I think this may have been a
> mis-calculation.
The calculation ran as follows:
- I didn't ignore the results of the conversation, I just don't think
there were many results. Before he went off-line Dave Raggett
proposed a series of alternatives, none of which seemed to satisfy
many people. I tried to measure how much people agreed with each of
the alternatives, but got no response.
- It is easier to add features later, than to remove or change
them. This applies to attributes like `units' or `width' and to
elements like `tspec' for holding extra alignment info.
- People already use these tables and it seems that that part of the
syntax at least has reached consensus.
- Over the past few weeks I've looked at many tables (more or less
all the books in my possesion plus many from the library and I
found only one type of table that didn't fit the model: a table
with arrows connecting some cells.
- None of the non-HTML table specs that I've seen (5, I think) could
encode those arrows.
- No matter how many attributes and elements you add, you can never
replace a good style sheet. Many of the tables I've seen had
diagonal headers, horizontal rules without vertical ones, colours
behind every other row, etc.
- I don't agree with Dave Hollander, who suggested that we put
controversial features in and try to learn in practice if they are
workable. We can do the experiments anyway.
Compared to HTML 3, I've changed the names of ALIGN and VALIGN to
COLALIGN and ROWALIGN and reduced the value of COLALIGN to a single
letter. This way all three levels TABLE, TR and TH/TD have the same
attributes.
I've also left out NOWRAP, from the assumption that contents of a cell
should never be broken, except when enclosed in a P. This is similar
to (La)TeX.
Compared to Netscape, I've left out the attributes that were clearly
introduced as stopgap measures while waiting for style sheets. (Listed
in <http://home.netscape.com/assist/net_sites/tables.html> under `A
little more control')
> However, I particularly wanted to make more of a meta-comment on the
> approach to a 2.1. I think it would be better and easier all around
> if what actually went into the 2.1 spec (DTD and text-wise) minimized
> duplicating 2.0. I especially wanted to highlight this issue DTD-wise.
I too like to drop the full DTD in favour of the diffs, but then there
must be some place where people can download the complete DTD. We
can't ask people to construct it out of the various fragments.
Redefining the parameter entities and including the HTML 2.0 DTD by
reference will work once, but not for 2.2, 2.3, etc.
> First, I would suggest that we don't need to allow tables in addresses.
It followed from my rule that a table can appear anywhere that a P
can. I've no specific arguments about ADDRESS.
Bert