W3C home > Mailing lists > Public > www-style@w3.org > April 2015

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

From: Simon Pieters <simonp@opera.com>
Date: Thu, 09 Apr 2015 12:50:43 +0200
To: "www-style@w3.org" <www-style@w3.org>, "Rick Byers" <rbyers@chromium.org>
Message-ID: <op.xwtm2twjidj3kv@simons-mbp>
On Wed, 08 Apr 2015 21:34:05 +0200, Rick Byers <rbyers@chromium.org> wrote:

> I'm continuing to try to get blink fixed
> <https://code.google.com/p/chromium/issues/detail?id=157855> to follow  
> the
> spec for body/documentElement scrollTop/Left behavior.  We've uncovered  
> another
> framework <https://code.google.com/p/chromium/issues/detail?id=426181>
> which relies on a WebKit UA check, making it hard for us to change.  It's
> not at all clear to me when (or even if) we'll be able to ship
> spec-compatible behavior without an unacceptable level of breakage.
>
> At the same time, while working with Facebook engineers we realized there
> isn't really any great work-around for existing code trying to support  
> both
> types of browsers.  Naive approaches like this one
> <https://gist.github.com/dperini/ac3d921d6a08f10fd10e> don't work
> reliably.  The best I've seen now is to have explicit functions for  
> getting
> and setting the document scroll position (which set both
> body/documentElement, and get returning whichever is non-zero).  But this
> is hard to integrate to existing code
> <https://github.com/google/closure-library/blob/32365aba43acb36c5d693256ef5d4dbe3bddddfe/closure/goog/dom/dom.js#L632>
> that expects to be able to determine the Element which can scroll the
> document.
>
> How about we make this transition easier by explicitly defining an API
> which returns either documentElement or body depending on which one  
> scrolls
> the viewport?  Frameworks can rely on a heuristic polyfill for existing
> browser engines, while newer engines can tell the page explicitly which
> element they're supposed to use.  This should also make dealing with
> framework code (which may or may not be used in quirks mode) a little
> simpler too.

Yeah, I think that makes sense. Added:

https://github.com/w3c/csswg-drafts/commit/857df4c257dc60d9d62292ec95883b992ce3ff42

-- 
Simon Pieters
Opera Software
Received on Thursday, 9 April 2015 10:51:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC