Re: [css4-ui] Scrollbar tracking control

On Tue, Jan 15, 2013 at 7:15 AM, Mike Lawther <mikelawther@chromium.org> wrote:
> This proposal is going to make developer's lives easier In trying to make
> this sticky behaviour work using JS, there are several disadvantages over a
> declarative solution as proposed earlier in this thread.
>
> In particular, we are using declarative transitions to smoothly animate new
> content into the bottom of a frame. The new piece of content is added to the
> bottom of the existing content at height 0, and smoothly grows to its final
> size. In native (mobile) versions of the app, it looks great and feels
> slick.
>
> In the browser, trying to use JS to set the scroll position at the same rate
> that the transition is happening just never works smoothly.
>
> It's also exposing an asymmetry in the scroll positioning behaviour - if we
> were inserting content into the top of the frame (and the user is scrolled
> to the top), everything just works. We could also try implementing a custom
> scrollbar to invert the scrolling behaviour so the desired 'sticky'
> behaviour happens on the bottom instead, but yuck :(
>
> What I like about this proposal is that it moves common behaviour that is
> otherwise tricky and cumbersome to implement (not to mention jank prone as
> you try to use JS to reset the scroll position at 60Hz to keep up with the
> animation) into declarative code. Into the bargain, for power users who
> really do desire a different behaviour (hi David! :) ), they are able to
> override the CSS - where if the behaviour was implemented in JS that
> wouldn't be an option. It's just as useful for desktop browsers as it is for
> mobile.
>
> David, Simon - does this address your concerns?
>
> The proposed syntax as I understand it is:
>
> ----
> overflow-anchor: none | [ [ before | after ] <length>? | [ start | end ]
> <length>? ]
>
> before/after: logical direction referring to the "block axis", which is
> vertical in English text, but horizontal for "vertical text" like Japanese.
> start/end: the corresponding logical directions for the "inline axis", which
> is perpendicular to the block axis.
> length: a ‘safe zone’ - if you’re at least this close to the edge, then
> it’ll be sticky. If this is omitted, then the UA can supply whatever value
> it thinks is best.
> Initial value: overflow-anchor: before
>
> Note that concepts of ‘x’ and ‘y’, or ‘top’ or ‘left’ are not used - these
> presuppose a writing direction, and interact wrongly with eg RTL text.
> -----
>
> Are there any problems with this as it stands that people would object to an
> experimental implementation?

We have parts of an experimental implementation done now, but haven't
done any of the parsing for it.  Based on our shift in terminology
since then, the grammar would now be:

Name: overflow-anchor
Value: none | [ [ block-start | block-end ] <length>? || [
inline-start | inline-end ] <length>? ]
Initial value: block-start

(I'm not sure what "none" would actually do here, but I've included it
for now because it was in Mike's previous version.)

I'd like to put this into a spec.  Does anyone object to this?  If
not, where should I put this?

~TJ

Received on Thursday, 6 March 2014 20:53:08 UTC