Re: [css4-ui] Scrollbar tracking control

On Thu, Mar 6, 2014 at 12:52 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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?

Since nobody objected (or said anything, really), should I consider
this a reasonable thing to do?  I'd like to write up an ED with this
in it, perhaps called CSS Scrolling.

~TJ

Received on Friday, 11 April 2014 21:06:48 UTC