Re: [cssom-view] Easing the transition to spec-compatible body scrollTop behavior

> On May 11, 2015, at 4:47 PM, Rick Byers <rbyers@chromium.org> wrote:
> 
> On Thu, May 7, 2015 at 7:19 PM, Simon Fraser <smfr@me.com <mailto:smfr@me.com>> wrote:
> Hi Rick
> 
> We’re looking at implementing scrollingElement in WebKit, and are confused by a few things in the spec[1]:
> 
> Hi Simon, thanks for your feedback!  In general I defer to SimonP on the precise wording - he wrote all this and is the editor.  But I'll reply with my opinion of the intention here. 
> 
> 1. We’d like to see some text to explain the purpose of this API, perhaps with an example of use (in a quirky and a non-quirky document), and a description of what exactly scrollingElement is intended to represent.
> 
> Do you mean some normative text?   The non-normative note is fairly clear on the purpose, no?

The note starts by stating what behavior is for quirky UAs, then talks about getting the right element for “scrolling APIs” which could be taken to include overflow scrolling. Only at the very end does it talk about scrolling the viewport, which is really what this property is about.

> 
> 2. In the first step, the negated reference to the body being “potentially scrollable” is very confusing, because the definition of “potential scrollable” has a clause that references the body and the root’s scrollability. We’re finding that the multiple negations make the logic hard to follow. It would also help to use a term that’s more descriptive than “potential scrollable”. Is this more like independently scrollable, or scrollable via overflow?
> 
> Clarifying this sounds good to me, I know some blink folks have also found it confusing to follow.  But note that this issue is bigger than just scrollingElement, it has affected the algorithm for each of the scrolling APIs (eg. scrollTop <http://dev.w3.org/csswg/cssom-view/#dom-element-scrolltop>) for some time I believe.  My hope is that we can move all this complexity from being duplicated across all the scrolling APIs to just the section for scrollingElement and then rewrite the relevant logic for the scrolling APIs to just say "if this is the scrollingElement" (at least that's how I did the implementation in blink <http://src.chromium.org/viewvc/blink?view=revision&revision=193662> and it simplified things dramatically for us).

Somewhere I read text that talked about a “scrolling box”, which I think is easier to understand than “potentially scrollable”.

> 
> 3. The steps and the Note about non-conforming user agents imply that there will be a behavior change for non-conforming user agents when they start to conform. Currently they will always return the body. In future, they will return null for some combination of non-visible overflow on the body and the documentElement. Is that intended?
> 
> Right.  The intention is that user agents will always return the element which reflects the viewport scroll position (i.e. where setting scrollTop is equivalent to calling window.scrollTo).  In some edge cases there will be no such element, and so you get null.  Perhaps the normative text should first say something like my sentence above before going into the algorithm details?

I think that would be an improvement, yes.

Simon