Re: Proposal: Fixed Table Headers in CSS

Hi, folks-

Tab Atkins Jr. wrote (on 12/15/09 2:19 PM):
> On Tue, Dec 15, 2009 at 12:47 PM, Brad Kemperwrote:
>>
>> My idea is that this would be a position property, such as
>> 'position: sticky' or 'position: scroll-limited' or 'position:
>> semi-fixed'. And thus, it would use 'top', 'bottom', 'right', and
>> 'left' properties, in this case to determine where within the
>> viewport (or within the containing block) the element would "stick"
>> and become semi-fixed, relative to that side. Thus, for a table
>> header, you might have this:
>>
>> thead { position: scroll-limited; top:0; }
>>
>> Or, suppose you already had a position:fixed page header that was
>> 100px tall, and you wanted the table headers to stop below that
>> when scrolling, along with a little extra room:
>>
>> #page-header { postion: fixed; top:0; height: 100px; } thead {
>> position: scroll-limited; top: 110px; }
>>
> That's an elegant way to handle it, and I like it.

That syntax seems fine to me as well, and I like that you can (for 
whatever reason) provide an offset from the leading scroll edge.


>>>> * should there be an event that is thrown when content sticks,
>>>> so that the author can choose to enhance the effect via script
>>>> or declarative animation (change the background color of the
>>>> sticky content, widen it to fill the top like the Slashdot
>>>> example, shrink the font size and fade the color to make it
>>>> more subtle, etc.)? ** if so, should there be another event
>>>> when it unsticks? ** should there be an event attribute to
>>>> indicate whether the content stuck to the top, bottom, left,
>>>> right? ** any other events or attributes?
>>>
>>> I dunno.  We don't usually have events thrown by CSS
>>> interactions, though it does sound like this sort of thing might
>>> be useful.
>>
>> I'd think you could just compute its position relative to the
>> viewport pretty easily to do the same thing.
>
> That's my thought too.  You have to listen for scroll events, but
> that's not difficult.

I think that would actually be a lot more work for content authors.

If there were only one sticky header, it wouldn't be so bad to listen to 
the scroll event and do the math yourself... but when there are multiple 
sticky headers and footers, with different potential scroll and 
attachment directions (top, bottom, left, right) and their offsets, and 
accumulation, it gets much more complicated... the browser already knows 
the point at which the sticky effect has been applied, and all the 
various parameters, why make the author duplicate that in script, when 
the browser can simply notify them?

Think about this in terms of interaction with animation and transitions, 
as well, and with regards to how script libs and webapps are likely to 
use the feature.  I think it would be shortsighted not to provide an 
associated event type, and I would be happy to help define it.

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

Received on Tuesday, 15 December 2009 21:34:32 UTC