Csswg-drafts: [css-scroll-snap] Different browsers implement keypress scrolling differently

[cruxicheiros]

Relevant section: https://drafts.csswg.org/css-scroll-snap/#scroll-padding
Related to thread "define scroll amount by CSS" http://lists.w3.org/Archives/Public/www-style/2018Jul/subject.html

CSS Scroll Snap introduces the attribute scroll-padding which allows CSS style sheets to specify an offset that the page will not scroll into when the space or page down buttons are used to scroll. This is important because otherwise, text that the user had not yet scrolled to would be hidden behind the header.

However, Firefox attempts to automatically detect sticky headers and does this already (described in this Bugzilla post. From my testing, Chrome, Edge, and Opera do not have this feature, making Firefox the odd one out.

I have created a demo site to help easily demonstrate this difference.

The reason this is relevant to CSS Scroll Snap is that with its introduction, guidance should be given on how scrolling should work when the attribute is not present. Scrolling behaviour should be standard across browsers.

Firefox's approach has benefits in that it fixes the problem scroll-padding aims to solve on already-existing websites. Therefore it might be beneficial for other browsers to do similarly. However, this could result in clashes when scroll-padding is used in a stylesheet on a website the browser has detected as using a fixed header and has already applied an offset to.

Firefox's detector, however, is not perfect and does not work on all sites. This page is an example where the offset should be applied and isn't.

Thank you.

[majido]

Firefox's approach has benefits in that it fixes the problem scroll-padding aims to solve on already-existing websites. Therefore it might be beneficial for other browsers to do similarly.

Perhaps it is beneficial for other browsers to implement this. But that is not something that we need to spec but rather an optimization that each browser can decide on. Similar to how the actual amount that implementations consider a "page" is implementation specific.

More concretely, Firefox detection is based on a heuristic with many caveats. I don't think we should specify anything like that.

The good news is that now their behavior can be described based on the new concept ('scroll port viewing region'?) introduced in the specification. Perhaps we can/should add a note that implementations are allowed to adjust scroll port viewing region if there is not user specified scroll-padding.

However, this could result in clashes when scroll-padding is used in a stylesheet on a website the browser has detected as using a fixed header and has already applied an offset to.

I think this will be a bug for browsers that have additional heuristics. In particular, if authors have
specified a scroll-padding the browser should not employ additional heuristics. See my suggestion above to add a note that should clarify this.

[fantasai]

It seems like scroll-padding should have auto as its initial value, then. This makes the interaction with author-specified scroll-padding very straightforward. (I remember suggesting this at some point, and it was decided not to complicate things by adding it. But if Firefox is already using some heuristics, then it might be worth doing.)

Whether we specify the heuristics or not is a different question, but also one worth investigating.

[majido]

Introducing 'auto' as initial value sounds good to me.

As for specifying a heuristic, are there example of cases where this was done. I am curious what something like that may look like. It will be also valuable to hear Firefox experience with their heuristic before going down this route.

[css-meeting-bot]

The Working Group just discussed Different browsers implement keypress scrolling differently, and agreed to the following:

• RESOLVED: add an auto value as the intiial value and for auto allow the agent to determine the padding size using a heuristic they want

The full IRC log of that discussion

<dael> Topic: Different browsers implement keypress scrolling differently

<dael> github: https://github.com/w3c/csswg-drafts/issues/2929

<dael> TabAtkins: Right now scroll-padding initial is 0 indicating no special padding is applied. FF has heuristics where it tires to detect like a fixed header and subtracts that from its page scrolling operations. Suggested we should allow those and then adjust initial value to reflect that intiial scroll padding may be impacted so change initial to auto

<dael> fantasai: So set to 0 or anything else browser heuristics are set off as opposed to having heuristics + your padding which is not what wanted

<dael> florian: sgtm

<dael> TabAtkins: Majid our impl is fine, suggested by FF, so 2 browsers say cool

<dael> myles: Proposal is add an auto value?

<dael> TabAtkins: Add an auto value, make it initial, and define as roughly 0 but browser may impose heuristics with a description of sort of heuristics

<dael> myles: Sounds great. Def do that

<dael> fantasai: 100% to do this

<dael> florian: Revisitin a few years

<dael> myles: Not spec exact heuristics

<dael> florian: Yes, if converge then standardize

<dael> astearns: Prop add an auto value as the intiial value and for auto allow the agent to determine the padding size using a heuristic they want

<dael> astearns: Obj?

<dael> RESOLVED: add an auto value as the intiial value and for auto allow the agent to determine the padding size using a heuristic they want

<dael> fantasai: Approval to update CR one edits in?

<dael> astearns: I expect tests need updating that are checking initial value

<dael> florian: Don't know if we have much test suite

<dael> fantasai: Majid would have those tests

<dael> astearns: No other scroll-snap issues?

[astearns]

@majido do you know of any WPT tests that check the initial value that would need to be changed?

[majido]

I am not aware of any such test. We don't have wpt CSS syntax parsing and initial value tests for css-scroll-snap.

[tabatkins]

@cruxicheiros Can you confirm that the edits in 9e4d465 satisfy you?

[cruxicheiros]

@tabatkins This resolves it. Thanks.