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

On Thu, Apr 9, 2015 at 9:01 AM, Simon Pieters <simonp@opera.com> wrote:

> On Thu, 09 Apr 2015 14:47:30 +0200, Rick Byers <rbyers@chromium.org>
> wrote:
>
>  On Thu, Apr 9, 2015 at 7:48 AM, Simon Pieters <simonp@opera.com> wrote:
>>
>>  On Thu, 09 Apr 2015 13:14:27 +0200, Robert O'Callahan <
>>> robert@ocallahan.org> wrote:
>>>
>>>  In most ways, the root element acts as the viewport element. So I think
>>>
>>>> scrollingElement would make more sense here.
>>>>
>>>>
>>> OK. I'm fine with either name. Anyone else have opinions about the name?
>>> If not I'll change to scrollingElement.
>>>
>>>
>> I prefer scrollingElement as well (could use 'viewportScrollingElement' to
>> be pedantic, but that seems overly long).  Thanks!
>>
>
> OK, changed.
>
> https://github.com/w3c/csswg-drafts/commit/9550767396214e0710ef77abe74b27
> 15cc5cc3f2


Thanks!

What do you think the behavior should be for a document in quirks mode when
the body element has an associated scrolling box?  In that case there is
really NO viewport scrolling element (setting body.scrollTop changes the
body element's scroll position, and documentElement.scrollTop is defined to
be always 0).

Your current wording says document.scrollingElement should be 'body' in
this case, but null feels more logical (and slightly simplifies
implementation and probably the ultimate spec wording of scrollTop etc.).
However it might be more convenient for libraries that want to assume
there's some scrollingElement if we returned body in this case.  WDYT?

 Do you think the spec text for scrollTop/Left/Width/Height could now be
>> simplified by referring to the scrollingElement (rather than repeating the
>> rules for each API)?  That's probably how I'll implement it in blink.
>>
>
> Yeah... filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28450
>
> cheers
>
> --
> Simon Pieters
> Opera Software
>