Re: Proposal: Fixed Table Headers in CSS

On Mon, Dec 14, 2009 at 9:46 AM, Doug Schepers <schepers@w3.org> wrote:
> * should this include both headers and footers?  (My intuition is yes.)

Sure.  We're looking at it as a generic mechanism now.  Note, though,
that putting it on both a header and footer means that they'll both be
visible at all times while the table is visible.  They'll appear
first, then they'll separate and show the data.

> * how should vertically-scrolled content (e.g. row headers, maybe more
> complex non-table content?) be handled? (my first instinct is that this
> effect should be defined as for scrolling

You mean like if a row header gets horizontally scrolled off the
screen?  We should define a mechanism for saying that we only care
about it remaining visible in certain directions.

> * should sticky content accumulate?

Yes.  That's the only way to go when you do this generically, I
believe.  That means that sticky content still has a notion of
'thereness' that normal abspos or fixpos content doesn't (that is,
abspos/fixpos elements will gladly overlap each other).  Sticky
elements (a) need to reserve their old space in the element (like a
relpos) when they switch from normal flow to sticky (so that
subsequent content doesn't suddenly 'jump up' now that the sticky
heading or whatever isn't there), and (b) need to avoid overlapping
other sticky elements, like how floats avoid overlapping each other.
I feel like the exact details of (b) will depend on how we define the
'directionality' of stickyness (like with the row-headers that are
only sticky if scrolled off horizontally).

> ** i.e. will a sticky <h1> stay on the screen when its "child" <h2>s stick?
> will multiple <h2>s stick together? (I would guess that different "levels"
> of heading could accumulate, but not "siblings".)

In my current idea of how this works, sticky elements use their
containing element to decide how long to stick around.  When their
containing element completely scrolls off the screen, they go with it.
 So yes, both the <h1> and the <h2> would stack.  As long as you used
<section> elements to establish the <h2>s in new containing blocks,
though, they won't stack - as one comes up, the previous one scrolls
off along with its containing block.

> ** what about different "categories" of sticky content (headings and table
> headers)... would they accumulate?

I don't see any reason why not.  CSS has no inherent notion of
'categories' of elements beyond the display type.

> * what should be the behavior when a user jumps to the middle of a
> containing block that would otherwise have a sticky header/footer when
> scrolled (e.g. a row in the middle of a very long table, a paragraph under a
> sticky <h2> itself under a sticky <h1>)?  (I think it the sticky content
> effect should be applied, though I suspect this will make implementation
> rather more difficult.)

The sticky effect should be applied.  The way I'm imagining it is that
you specify the directions that the sticky element doesn't want to
scroll off (by default, this would just be 'top').   Jumping straight
down, frex by an anchor link, still scrolls things off (and most UAs
actually animate an anchor link as a scroll now anyway).

> * 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.

~TJ

Received on Tuesday, 15 December 2009 14:07:33 UTC