Re: Proposal: Fixed Table Headers in CSS

Hi, Mikko-

Mikko Rantalainen wrote (on 12/10/09 5:59 AM):
> Doug Schepers wrote:
>>  My conception of this is that the headers would stop scrolling when they
>>  hit the very last row... so, the last thing the user would see while
>>  scrolling down is a 2-row table... the header row and the final row.
>>
>>  I guess ideally this is what would happen when the user scrolled up
>>  toward the table from the bottom as well... for example, if the user
>>  jumped to the bottom of the page via a fragment identifier, then
>>  scrolled up, they would see that 2-row table, with the table growing and
>>  the header sticking to the top of the window until the whole table is
>>  passed.
>
> This sounds great. I would like to make that more generic, though.

TJ and I talked about this, but decided that specifying and implementing 
this would be rather more difficult than the specialized case for table 
headers.  Specifically, the accumulation rules for multiple nested 
containing blocks would have to be defined, and if this were declared on 
all headings, the accumulated fixed blocks could quickly take up the 
whole viewport.  (Of course, that would be an author flaw, but 
nevertheless a concern.)

My chief concern with generalizing it is not that it's not a good idea, 
but that it could make the whole thing take much longer to specify and 
implement, sacrificing the known (fairly strong) use case for the 
potential to meet less-common use cases.

It may be that my intuition is wrong, and the general case could be 
specified and implemented just as quickly.  In that case, I have no 
objections, and would even encourage the general case.  Should my 
intuition prove correct, maybe the CSS WG could specify it first for the 
specific table header/footer case, picking a name that would be suitable 
for later expanded use, and specify the behavior for the general case 
after browser vendors have played with vendor-specific extensions and 
arrived at a good generic solution.


> I think that it should look like "fixed" in the sense, that the
> element would stay fixed relative to viewport while the normal content
> is scrolled (no hopping around or flickering). I think that it should
> not stick to rows (or any other elements) but always stay exactly at the
> edge of the viewport (if moved from it's "true relative" position).

I agree that this would usually look best.  I don't have a strong 
opinion, though, and wouldn't mind terribly if that were UA-dependent.


> The same feature could be used to bring footer from bottom of a table to
> bottom of the viewport, too. And it would work it RTL content, too.

Yes, I can see that use case, too.


> I'm open for suggestions for the position name, the
> "relative-or-fixed-within-viewport-and-container" would be pretty close
> to the behavior but that's way too long. Another choice could be
> "relative-float-to-viewport" or just "float-to-viewport".

How about 'block-fixed'?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 12 December 2009 01:27:54 UTC