Re: Multiple Table Captions

Some people might want this on TFOOT too. The use case seems weaker,  
but it would have nice symmetry of function if it was allowed there too.

On Oct 30, 2008, at 12:57 AM, Brad Kemper wrote:

> On Oct 29, 2008, at 11:52 PM, Boris Zbarsky wrote:
>> Brad Kemper wrote:
>>> Actually, it would be good to have both the caption and the column  
>>> headers visible whenever and wherever there are table rows visible.
>> I've wished for this a few times, but see below...
>>> keep the caption and/or thead immobile once you scrolled the page  
>>> enough
>> So if the caption is below the table and the thead is above and the  
>> table is taller than the screen, would the caption render on top of  
>> other parts of the table?
> I think those sort of details could be worked out and specified in a  
> way that would not preclude moving forward with the idea. In fact,  
> if you take a look at what Apple did with the Contact list in the  
> iPhone, there is something in there that is already very close:  
> There are dividers in the long list for each letter of the alphabet,  
> and they stay visible for as long as contacts starting with that  
> letter are visible.
> IMO, the answer to your question would be "no", it would not  
> initially be rendered on top of other parts of the table. The way I  
> see that situation, is that initially the caption or thead with that  
> property value would start out in the same position as if they were  
> position:static, and you would only see a difference when the top of  
> the table started to scroll in or out of view. If scrolling up, it  
> would be elements at the top that would stop scrolling with the  
> page. If scrolling down, it would be elements at the bottom (such as  
> your caption example) that would stop scrolling with the page (or  
> other scrollable container; it would not have to be a page).
> This in essence means that there could be situations (with tall  
> TBODYs, for instance) where your example would result in a caption  
> scrolling into view from the bottom, but not scrolling out until it  
> touched the bottom of the immobilized THEAD. That is not too  
> different from what happens in the iPhone example, when the next  
> letter divider moves up the screen to meet the last one. If both do  
> not fit at the same time, then the one on top shows and the bottom  
> one doesn't (same as today on the initial rendering of such a table  
> that doesn't all fit in the scroll area).
> It might be simpler to say that this only effect table elements when  
> they scroll in and out of view at the top or left edges of the  
> scrollable area (I've only seen it work on the top edge on the  
> iPhone).
>> Also, I assume the whole thing should scroll on horizontal scroll?   
>> Or should <th> elements in the first column not scroll then?
> That is a possibility. I admit to mainly thinking vertically of this  
> vertically in terms of THEAD or CAPTION, that ordinarily span the  
> full width of the table. But I can conceive of THs in the first  
> column becoming immobile instead of scrolling horizontally out of  
> view.
>> I should also note that something like this would also be possible  
>> if table row groups could be made scrollable.
> I agree that would also be cool, and has its own problems to work  
> out too. But with what I am envisioning would allow the tables to be  
> their full height, without additional scroll bars needed beyond what  
> are already there.
>> > Thus, this property would then be
>>> used to keep captions and/or theads visible on paged media too, as  
>>> long as there would also be rows of the same table to be shown on  
>>> that page.
>> How does this work if the thead or caption is taller than a page?
> Yes, we would need to decide what happens in that case. My initial  
> thought is that it would not be a very good design choice to use  
> that property value for theads or captions that are likely to be  
> taller than a page. But I think that, just as in less extreme cases  
> where enough scrolling does push it off screen (when the bottom of  
> the table reaches the bottom of the thead), SOMETHING would  
> eventually push it up and off. I think in this case it should be the  
> rest of the table that pushes it out of the way. In other words, if  
> the THEAD with "position:persist" (or "position:fixed-in-table" or  
> whatever we call it) is taller that the scrollable container it is  
> in, then it should really at that point be no different that  
> position:static (this would be an exception to the rule of how it  
> normally would work). Otherwise, you would never see the table body.
>> -Boris

Received on Thursday, 30 October 2008 15:27:11 UTC