W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2016

Re: [csswg-drafts] [cssom-view] New feature - scroll-boundary-behavior (an extension of -ms-scroll-chaining)

From: Majid Valipour via GitHub <sysbot+gh@w3.org>
Date: Thu, 22 Dec 2016 16:51:32 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-268841002-1482425489-sysbot+gh@w3.org>
Thanks for the feedback.

> across multiple (but maybe not all?) engines, this decision is made 
not per-pixel-of-scrolling but per-scrolling-gesture. If that's true 
in all engines, maybe it should just be specified that way. If not, it
 needs to account for differences somehow.

We can actually leave when the decision is made unspecified and leave 
it up to UA implementation. I More below. 

> In Gecko at least, propagate is not the default behavior for 
keyboard scrolling. This should be tested as well. (But maybe it 
should be?)

I can confirm this is indeed the case in Gecko for keyboard (tested on

> So I think, at the very least, the initial value would need to have 
a better match for what today's behavior is, assuming we don't have a 
wide agreement to change the behavior.

I think this is reasonable. I don't believe we need to have all UAs 
agree on which inputs and exactly when (per-pixel or per-gesture) they
 chain the scroll. All main usecases that need this feature actually 
care about a consistent method to *prevent* the default chaining as 
opposed to forcing chaining to happen for a particular input or at a 
particular time. 

Here is one way we can spec this to achieve the above without taking 
away the UA flexibility in deciding when to chain.

* Replace 'propagate' with 'auto'. So we don't prescribe what is the 
default boundary behavior and leave it up to UA. This also addresses 
the spelling concern with 'propagate'.
* Keep 'none' and 'contain' as they are. They simply prevent the 
default behavior which is propagation. 

GitHub Notification of comment by majido
Please view or discuss this issue at 
using your GitHub account
Received on Thursday, 22 December 2016 16:51:33 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 2 July 2022 03:20:52 UTC