> What happens if the DTD doesn't support them, or it the DTD
> allows arbitrarily large and complex content for them? They
> could end up taking the entire real estate available, especially
> if the window is resized to 200x200.... or on a TTY. There will
> always be cases where this proposal will fail. The main implemntation
> problem is finding these cases, and dealing with them "correctly":
I tried to propose a solution to the won't fit problem ... the sticky
headers would logically rest on the end of the panel before the
table rows and hence be very close ... still tricky to get right
because my notion of how to control scrolling doesnt quite fit.
My intent was not to have an obvious scrollable wigit associated with
the table. If the table fits on the available space it would be there
without any difference from a presentation without my feature. The
reading paradigm I'm trying to mimic is that of a printed document
where a table flows over more than one page. Headings are on every
page and hence easy to find but the scrolling (page flipping) is the
same as for the the remainder of the document. Under my proposal,
the normal browser scrolling keys/mouse bars would scroll the document
in a window which was reduced in size enough to have the sticky headers
in view until the end (top) of the table in a forward (backward)
direction is off the table.
> especially if there is arbitrary content. An embedded scrolling table
> view widget is something I can understand, and see a need for, but I
> don't think it will be possible to make header and footers "sticky" in
> a way is always useful (or meaningful).
Of course, nothing is always useful but I would venture what I have in
my head but perhaps not yet clearly expressed would be useful most of
the time ... certainly a higher percentage of the time then having
multiple screen tables with heading gone.
> Hard coding anything to do with presentation is probably not
> a good idea.
Agree -- should be optional.