> >I don't think that the suggestion had much to do with HTML per se.
> >It seems to be a suggestion about rendering. If browser developers
> >can do it, then why not? Certainly this will affect how style
> >sheets might be written -- or not -- but I don't think that the
> >style sheet design should preclude any browser implementation
> >from adding such an obviously useful feature.
> If you cannot enable this feature from a stylesheet, then how will you
> enable it without hard coding the table format into the rendering
> engine? Someone else pointed out that spreadsheets do basically what
> is proposed as a way of refuting my statement that implementing this
> would be hard.
You don't need a stylesheet mechanism to be able to handle
table heads and feet specially. That can certainly be
hardwired into a browser as desired/required.
> However, there is one point missed here: Given that SGML *is* coming
> to the WWW (like it or not), and that people want arbitrarily complex
> tables (or will do eventually), what does "header" and "footer" mean?
They mean whatever the table fragment of the DTD say that they mean.
Most sophisticated table DTDs include, at least, a way to
differentiate the rows of a table that are "row-heads" from
the data rows. I would expect that a general SGML browser
could be taught to deal with these specially either a DTD by DTD
basis or through a style-sheet. But the fact that style sheets
could be used does not mean that they must be used.
> Also, is this meaningful on a scrolled page? I can imagine people
> wishing to have something like a "scrolled table view" widget embedded
> in a document to cut down the amount of space required for the table;
> I'll even admit that it might be useful for large tables, but it is
> certainly not an HTML issue.
I think that it is only meaningful in a scrolled view of a table.
The whole idea is for the reader to be able to see the row-heads
while viewing the data. In longer tables, it is really annoying
to have to go back to the top of the table to remind oneself
what each row is about -- especially in tables that are heavily
laden with numeric data or technical specs (like semiconductor
data sheets, for example).
> Personally, I agree with Eric Nuggum and think that tables don't
> exist anyway :-)
You'll find a friend in Terry Allen then.