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

On Tue, May 12, 2015 at 10:58 AM, Simon Fraser <smfr@me.com> wrote:
>
> 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> 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.
>
> SimonP: any thoughts on the suggested wording improvements 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
>
>
>