Re: [css-overflow][css-scroll-snap][css-position] position: fixed and paging

On Tue, Feb 9, 2016 at 10:14 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> One major problem with "position: fixed" elements is that the content
> underneath
> it is viewed as "scrolled into view" when in many cases it is in fact
> invisible
> to the viewer. This interferes with paging actions, which no longer page by
> screenful of visible content (which is the only really useful behavior).
>
> Testcase:
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3875 [1]
>
> The solution I have off the top of my head is to extend the definition of
> 'scroll-snap-padding' to address this case, since the use cases that drove
> its addition are largely the same that result in this problem. That would
> require renaming it to 'scroll-padding', and possibly adding an 'auto' value
> that introduced padding based on any 'position: fixed' content applicable
> to the viewport. (I haven't quite thought this through, though.)

I don't think we should do anything about this.  Using position:fixed
to position a header or something is bad practice; there are much
better ways to do it now (like Flexbox).  There are many *other*
use-cases for position:fixed that don't cause these problems and
shouldn't reduce scrollable area, like a dialog floating on the page.

We also shouldn't put this on authors as something they have to do
just to make the page work correctly.

> I'm also concerned that "position: sticky" may have similar problems, though
> perhaps that's solveable as a behavior constraint on UAs--to reduce the
> paging
> size by the amount of sticky content--rather than something authors need to
> address explicitly.

Yeah, having UAs do this automatically for sticky makes sense to me.

~TJ

Received on Wednesday, 17 February 2016 01:24:31 UTC