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

On Thu, May 7, 2015 at 7:19 PM, Simon Fraser <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?

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).

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?

Simon
>
> [1] http://dev.w3.org/csswg/cssom-view/#dom-document-scrollingelement
> [2] http://dev.w3.org/csswg/cssom-view/#potentially-scrollable
>
>