Re: Proposal: define scroll amount via CSS

 I've gone and done some further investigation of this problem. I have been
using Chrome 67 with the Experimental Web Features flag enabled to test
this. When applied to `body` (as suggested in the spec), `scroll-padding`
doesn't seem to have any effect on the scroll distance at all - so maybe it
hasn't been implemented there yet.

I am in the middle of writing a demo that will show the difference between
how Chrome and Firefox deal with sticky headers. I'm not totally sure how
the sticky header detection is done and it does make me wonder whether it
(as liam@w3.org suggested) should be a recommendation to have browsers
attempt to detect them by default.

This makes me unsure whether it's actually worth opening an issue about
since, looking at this discussion, it seems to be a problem with browsers
and not the spec itself.

On Mon, Jul 16, 2018 at 6:43 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Mon, Jul 16, 2018 at 9:21 AM Majid Valipour <majidvp@chromium.org>
> wrote:
> > On Mon, Jul 16, 2018 at 11:12 AM Hazel Seanor <hazel.seanor@gmail.com>
> wrote:
> >> My proposed solution would be to add a new property, scroll-amount,
> which would be set to a size in units.
> >
> > I believe this is already addressed by `scroll-padding` [1].
>
> Yes, 'scroll-padding' is designed for *precisely* this use-case.  Set
> the size of the fixed header as a scroll-padding on the scroll
> container, and pgUp/pgDn should jump the appropriate amount. (If
> browsers properly support it, of course.)
>
> >>  I haven't made a github issue because I'm not sure what to tag it as.
> >
> > If `scroll-padding` does not address this problem then I suggest
> creating a github issue and tagging it with css-scroll-snap.
>
> Don't worry about correct tagging, we can edit titles and add labels
> later.  Putting stuff into GitHub is *greatly* preferred; it's easy to
> lose track of emails, particularly since our workflow is so GH-focused
> now.
>
> ~TJ
>