This mailing list is for technical discussion on Web Style Sheets

Tab Atkins Jr. | 15 Jun 2012 01:34

[css4-ui] Scrollbar tracking control

I just received an internal request for some functionality that I
myself have wanted a few times in the past as well.

If you're dynamically adding content to a container on a page, with
enough content to trigger a scrollbar, you usually want the latest
stuff to show up without forcing people to scroll.  Since the
scrollbar position is stable across content changes and is measured
from the top of the box, if you're adding content to the top, you're
fine, but if you're adding content to the bottom, like in a chatroom,
you have to manually adjust the scroll position in JS after adding
each entry.  This is both annoying and potentially racy.  Plus, if you
do it the obvious, naive way (just setting the scroll position to the
bottom every time), you produce a bad user experience, because they
might have scrolled somewhere into the middle of the content to read
or copy something, and you'll interrupt them.  (I've spent a lot of
cusses on software that does exactly this before...)

I request that we add an explicit control for this, such that if a
scrollbar is currently scrolled against a particular edge, it can be
made to "stick" to that edge when the content width/height changes.
Something like:

scrollbar-attachment: normal | edge;

It's UA-defined exactly how close a scrollbar has to be to be
considered "against" a particular edge.  The obvious answer is
"exactly at either end", but it might make sense to be a little looser
in case people stop scrolling a pixel or two away from the edge, so we
should leave this to implementations to decide.

(Continue reading)

headers

L. David Baron | 15 Jun 2012 02:00

Re: [css4-ui] Scrollbar tracking control

On Thursday 2012-06-14 16:34 -0700, Tab Atkins Jr. wrote:
> I just received an internal request for some functionality that I
> myself have wanted a few times in the past as well.
> 
> If you're dynamically adding content to a container on a page, with
> enough content to trigger a scrollbar, you usually want the latest
> stuff to show up without forcing people to scroll.  Since the
> scrollbar position is stable across content changes and is measured
> from the top of the box, if you're adding content to the top, you're
> fine, but if you're adding content to the bottom, like in a chatroom,
> you have to manually adjust the scroll position in JS after adding
> each entry.  This is both annoying and potentially racy.  Plus, if you
> do it the obvious, naive way (just setting the scroll position to the
> bottom every time), you produce a bad user experience, because they
> might have scrolled somewhere into the middle of the content to read
> or copy something, and you'll interrupt them.  (I've spent a lot of
> cusses on software that does exactly this before...)
> 
> I request that we add an explicit control for this, such that if a
> scrollbar is currently scrolled against a particular edge, it can be
> made to "stick" to that edge when the content width/height changes.
> Something like:
> 
> scrollbar-attachment: normal | edge;
> 
> It's UA-defined exactly how close a scrollbar has to be to be
> considered "against" a particular edge.  The obvious answer is
> "exactly at either end", but it might make sense to be a little looser
> in case people stop scrolling a pixel or two away from the edge, so we
> should leave this to implementations to decide.

(Continue reading)

headers

Tab Atkins Jr. | 15 Jun 2012 02:18

Re: [css4-ui] Scrollbar tracking control

On Thu, Jun 14, 2012 at 5:00 PM, L. David Baron <dbaron <at> dbaron.org> wrote:
> I'm worried about a few things here:
>
>  * I wouldn't want this to preclude browsers improving their
>   behavior in other ways (since there are a bunch of improvements
>   that could be made)

Brief examples?

>  * As a user, I hate this behavior.  I generally want to know where
>   I left off, and I hate it when sites think I want the latest and
>   don't care where I last stopped reading.  So I'm personally much
>   more interested in having the position be maintained.

I suspect this isn't actually your position in chat rooms. ^_^
Otherwise you'd have to constantly hit pagedown just to keep up with
the conversation.  But even if it is, pushing this functionality into
CSS makes it easy enough to put a "scrollbar-attachment: normal
!important;" rule into your user stylesheet.  Much easier than trying
to deal with each page's JS.

>   So it
>   seems like there are two separate pieces of information here: (1)
>   which end the site is adding content from and (2) whether the
>   site things you want scroll-to-latest-if-at-edge.  If they're
>   separate, then it's easier for the user to override (2).

I'm not sure how (1) would be useful as a separate piece of information.

~TJ

(Continue reading)

headers

L. David Baron | 4 Dec 2012 23:40

Re: [css4-ui] Scrollbar tracking control

On Thursday 2012-06-14 17:18 -0700, Tab Atkins Jr. wrote:
> On Thu, Jun 14, 2012 at 5:00 PM, L. David Baron <dbaron <at> dbaron.org> wrote:
> > I'm worried about a few things here:
> >
> >  * I wouldn't want this to preclude browsers improving their
> >   behavior in other ways (since there are a bunch of improvements
> >   that could be made)
> 
> Brief examples?

 - preserving the user's position in the content when the user
   resizes the page

 - preserving the user's state of being at the (bottom/end) edge of
   the content when the user resizes the page

 - preserving the user's position in the content a non-end position
   when content is added

Stepping back, I think there are a bunch of infinite-scroll UIs
being added these days, where new content gets added dynamically.

I can think of two big models:

 * new content at the top, but ability to scroll to get more old
   content at the bottom (twitter, facebook)

 * new content at bottom (chat)

The interesting thing about the first is that content can be added

(Continue reading)

headers

Alan Gresley | 5 Dec 2012 16:09

Re: [css4-ui] Scrollbar tracking control

On 5/12/2012 9:40 AM, L. David Baron wrote:
> On Thursday 2012-06-14 17:18 -0700, Tab Atkins Jr. wrote:
>> Brief examples?
>
>   - preserving the user's position in the content when the user
>     resizes the page
>
>   - preserving the user's state of being at the (bottom/end) edge of
>     the content when the user resizes the page
>
>   - preserving the user's position in the content a non-end position
>     when content is added
>
> Stepping back, I think there are a bunch of infinite-scroll UIs
> being added these days, where new content gets added dynamically.
>
> I can think of two big models:
>
>   * new content at the top, but ability to scroll to get more old
>     content at the bottom (twitter, facebook)
>
>   * new content at bottom (chat)
>
> The interesting thing about the first is that content can be added
> at both ends.  When I scroll to the bottom in facebook or twitter,
> it dynamically adds more new content at the bottom (and doesn't
> scroll when it appears); when I scroll to the top, it dynamically
> adds new content to the top, and there are use cases both for
> holding position-in-content and for staying at the edge.

(Continue reading)

headers

Brad Kemper | 5 Dec 2012 18:17

Re: [css4-ui] Scrollbar tracking control

On Dec 4, 2012, at 2:40 PM, "L. David Baron" <dbaron <at> dbaron.org> wrote:

> 
>>>  * As a user, I hate this behavior.  I generally want to know where
>>>   I left off, and I hate it when sites think I want the latest and
>>>   don't care where I last stopped reading.  So I'm personally much
>>>   more interested in having the position be maintained.
>> 
>> I suspect this isn't actually your position in chat rooms. ^_^
>> Otherwise you'd have to constantly hit pagedown just to keep up with
>> the conversation.  But even if it is, pushing this functionality into
> 
> It actually is my position in chat-rooms; if I want to catch up, I
> want to read forwards rather than backwards rather than search for
> my previous read-to point; if I don't, I can get to the end easily.

In my IRC client, if I am scrolled to the bottom, it keeps me scrolled to the bottom as new content is added (to
the bottom). But if I am scrolled to any other place my position doesn't change as the chat gets longer. That
works out well. So perhaps we could replicate that with something like 'scroll-position-y: sticky-edge'.

headers

Tab Atkins Jr. | 5 Dec 2012 18:36

Re: [css4-ui] Scrollbar tracking control

On Tue, Dec 4, 2012 at 2:40 PM, L. David Baron <dbaron <at> dbaron.org> wrote:
> On Thursday 2012-06-14 17:18 -0700, Tab Atkins Jr. wrote:
>> On Thu, Jun 14, 2012 at 5:00 PM, L. David Baron <dbaron <at> dbaron.org> wrote:
>> > I'm worried about a few things here:
>> >
>> >  * I wouldn't want this to preclude browsers improving their
>> >   behavior in other ways (since there are a bunch of improvements
>> >   that could be made)
>>
>> Brief examples?
>
>  - preserving the user's position in the content when the user
>    resizes the page
>
>  - preserving the user's state of being at the (bottom/end) edge of
>    the content when the user resizes the page
>
>  - preserving the user's position in the content a non-end position
>    when content is added

None of these are prevented by my proposal to define a sticky edge, actually.

> Stepping back, I think there are a bunch of infinite-scroll UIs
> being added these days, where new content gets added dynamically.
>
> I can think of two big models:
>
>  * new content at the top, but ability to scroll to get more old
>    content at the bottom (twitter, facebook)
>

(Continue reading)

headers

Mike Lawther | 15 Jan 2013 16:15

Re: [css4-ui] Scrollbar tracking control

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?

On 6 December 2012 04:36, Tab Atkins Jr. <jackalmage <at> gmail.com> wrote:

On Tue, Dec 4, 2012 at 2:40 PM, L. David Baron <dbaron <at> dbaron.org> wrote:
> On Thursday 2012-06-14 17:18 -0700, Tab Atkins Jr. wrote:
>> On Thu, Jun 14, 2012 at 5:00 PM, L. David Baron <dbaron <at> dbaron.org> wrote:
>> > I'm worried about a few things here:
>> >
>> > * I wouldn't want this to preclude browsers improving their
>> > behavior in other ways (since there are a bunch of improvements
>> > that could be made)
>>
>> Brief examples?
>
> - preserving the user's position in the content when the user
> resizes the page
>
> - preserving the user's state of being at the (bottom/end) edge of
> the content when the user resizes the page
>
> - preserving the user's position in the content a non-end position
> when content is added

None of these are prevented by my proposal to define a sticky edge, actually.

> Stepping back, I think there are a bunch of infinite-scroll UIs
> being added these days, where new content gets added dynamically.
>
> I can think of two big models:
>
> * new content at the top, but ability to scroll to get more old
> content at the bottom (twitter, facebook)
>
> * new content at bottom (chat)
>
> The interesting thing about the first is that content can be added
> at both ends. When I scroll to the bottom in facebook or twitter,
> it dynamically adds more new content at the bottom (and doesn't
> scroll when it appears); when I scroll to the top, it dynamically
> adds new content to the top, and there are use cases both for
> holding position-in-content and for staying at the edge.

I agree! There was another thread around the same time as this one
about dynamic updates, where I think I proposed some way to declare
that if a container gained/lost elements or some elements changed
height *outside* of the visible scrolling area, it would auto-adjust
your scrolling position to keep your apparent position stable. That
works fine with this proposal.

> I tend to think we need a concept of a container for
> infinite-scrolling content in which the browser knows that it ought
> to pay attention to either
>
> (a) position preservation of the content present both before and
> after a dynamic update, across that update, or
>
> (b) preservation of a position at the edge of the content
>
> regardless of whether content is being added or removed from one
> edge or the other.

For (b), you still have to bias it towards one edge, so that the user
experience is nice when the elements transitions from "not scrolling"
to "scrolling" as you fill it with content.

>> > * As a user, I hate this behavior. I generally want to know where
>> > I left off, and I hate it when sites think I want the latest and
>> > don't care where I last stopped reading. So I'm personally much
>> > more interested in having the position be maintained.
>>
>> I suspect this isn't actually your position in chat rooms. ^_^
>> Otherwise you'd have to constantly hit pagedown just to keep up with
>> the conversation. But even if it is, pushing this functionality into
>
> It actually is my position in chat-rooms; if I want to catch up, I
> want to read forwards rather than backwards rather than search for
> my previous read-to point; if I don't, I can get to the end easily.

Huh, ok. I'll have to trust you on this, but your preference seems
extremely weird and uncommon to me. This isn't really about catching
up, it's about having to *constantly* press PgDn to see new content
every few seconds in a conversation (in fact, even your own messages
won't be initially visible).

headers

Bjoern Hoehrmann | 15 Jun 2012 01:59

Re: [css4-ui] Scrollbar tracking control

* Tab Atkins Jr. wrote:
>I request that we add an explicit control for this, such that if a
>scrollbar is currently scrolled against a particular edge, it can be
>made to "stick" to that edge when the content width/height changes.
>Something like:
>
>scrollbar-attachment: normal | edge;

This is not really controlling the scrollbar, especially not if there is
none, so the name seems wrong; and I am not sure I like having just the
"edge" value (what if initially the content does not overflow, then you
add stuff, how would the implementation decide whether to stick with the
top or with the bottom), but the functionality seems useful enough.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

headers

Tab Atkins Jr. | 15 Jun 2012 02:14

Re: [css4-ui] Scrollbar tracking control

On Thu, Jun 14, 2012 at 4:59 PM, Bjoern Hoehrmann <derhoermi <at> gmx.net> wrote:
> * Tab Atkins Jr. wrote:
>>I request that we add an explicit control for this, such that if a
>>scrollbar is currently scrolled against a particular edge, it can be
>>made to "stick" to that edge when the content width/height changes.
>>Something like:
>>
>>scrollbar-attachment: normal | edge;
>
> This is not really controlling the scrollbar, especially not if there is
> none, so the name seems wrong;

Explain? I'm not sure how this isn't controlling the scrollbar.

> and I am not sure I like having just the
> "edge" value (what if initially the content does not overflow, then you
> add stuff, how would the implementation decide whether to stick with the
> top or with the bottom), but the functionality seems useful enough.

Ah, good point.  It might make sense, then, to instead specify an
edge, so that when a scrollbar *does* appear, it sticks to that edge.

~TJ

headers

Bjoern Hoehrmann | 15 Jun 2012 03:16

Re: [css4-ui] Scrollbar tracking control

* Tab Atkins Jr. wrote:
>On Thu, Jun 14, 2012 at 4:59 PM, Bjoern Hoehrmann <derhoermi <at> gmx.net> wrote:
>> * Tab Atkins Jr. wrote:
>>>I request that we add an explicit control for this, such that if a
>>>scrollbar is currently scrolled against a particular edge, it can be
>>>made to "stick" to that edge when the content width/height changes.
>>>Something like:
>>>
>>>scrollbar-attachment: normal | edge;
>>
>> This is not really controlling the scrollbar, especially not if there is
>> none, so the name seems wrong;
>
>Explain? I'm not sure how this isn't controlling the scrollbar.

Scrollbars are an interface that represent and allow to control which
part of an element is rendered. The `-ms-scrollbar-*` properties would
control the actual scrollbar, but you generally would not refer to some
UI control in order to manipulate concepts they are an interface to.
You would not have a property `volume-slider: 100%` for `volume: 100%`.
And if this was to work with overflow:hidden, say because you have some
touch UI or because you don't actually want the user to scroll, then it
becomes confusing to set `scrollbar-*` properties, since there is none.
And which scrollbar anyway, considering there can be more than one.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

headers

Sebastian Zartner | 15 Jun 2012 06:49

Re: [css4-ui] Scrollbar tracking control


-------- Original-Nachricht --------
> Datum: Fri, 15 Jun 2012 03:16:39 +0200
> Von: Bjoern Hoehrmann <derhoermi <at> gmx.net>
> An: "Tab Atkins Jr." <jackalmage <at> gmail.com>
> CC: www-style list <www-style <at> w3.org>
> Betreff: Re: [css4-ui] Scrollbar tracking control

> * Tab Atkins Jr. wrote:
> >On Thu, Jun 14, 2012 at 4:59 PM, Bjoern Hoehrmann <derhoermi <at> gmx.net>
> wrote:
> >> * Tab Atkins Jr. wrote:
> >>>I request that we add an explicit control for this, such that if a
> >>>scrollbar is currently scrolled against a particular edge, it can be
> >>>made to "stick" to that edge when the content width/height changes.
> >>>Something like:
> >>>
> >>>scrollbar-attachment: normal | edge;
> >>
> >> This is not really controlling the scrollbar, especially not if there
> >> is none, so the name seems wrong;
> >
> >Explain? I'm not sure how this isn't controlling the scrollbar.
> 
> Scrollbars are an interface that represent and allow to control which
> part of an element is rendered. The `-ms-scrollbar-*` properties would
> control the actual scrollbar, but you generally would not refer to some
> UI control in order to manipulate concepts they are an interface to.
> You would not have a property `volume-slider: 100%` for `volume: 100%`.
> And if this was to work with overflow:hidden, say because you have some
> touch UI or because you don't actually want the user to scroll, then it
> becomes confusing to set `scrollbar-*` properties, since there is none.
> And which scrollbar anyway, considering there can be more than one.

How about this:

overflow-attachment-x: [normal | left | right] || <length> | inherit;

overflow-attachment-y: [normal | top | bottom] || <length> | inherit;

with <length> specifying the trap distance to the edge.

Sebastian
--

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

headers

Elliott Sprehn | 15 Jun 2012 07:29

Re: [css4-ui] Scrollbar tracking control

On Thu, Jun 14, 2012 at 9:49 PM, Sebastian Zartner <sebastianzartner <at> gmx.de> wrote:

...
How about this:

overflow-attachment-x: [normal | left | right] || <length> | inherit;

overflow-attachment-y: [normal | top | bottom] || <length> | inherit;

with <length> specifying the trap distance to the edge.

This looks really good to me. Why would you want inherit though?

- E

headers

Sebastian Zartner | 15 Jun 2012 10:30

Re: [css4-ui] Scrollbar tracking control

> On Thu, Jun 14, 2012 at 9:49 PM, Sebastian Zartner
> <sebastianzartner <at> gmx.de>wrote:
> 
> > ...
> > How about this:
> >
> > overflow-attachment-x: [normal | left | right] || <length> | inherit;
> >
> > overflow-attachment-y: [normal | top | bottom] || <length> | inherit;
> >
> > with <length> specifying the trap distance to the edge.
> >
> >
> This looks really good to me. Why would you want inherit though?
> 
> - E

If you have a scrolling element inside another scrolling panel you might want to inherit the scrolling
behavior, so you see e.g. the bottom-most element inside of it. Though I'm not sure if that's a common use case.

Anyway, I'd also suggest a shorthand for the syntax above:

overflow-attachment: [normal | top | bottom] || [normal | left | right] || <length>{1,2} | inherit

Sebastian
--

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

headers

Simon Fraser | 15 Jun 2012 20:18

Re: [css4-ui] Scrollbar tracking control

On Jun 15, 2012, at 1:30 AM, Sebastian Zartner wrote:

>> On Thu, Jun 14, 2012 at 9:49 PM, Sebastian Zartner
>> <sebastianzartner <at> gmx.de>wrote:
>> 
>>> ...
>>> How about this:
>>> 
>>> overflow-attachment-x: [normal | left | right] || <length> | inherit;
>>> 
>>> overflow-attachment-y: [normal | top | bottom] || <length> | inherit;
>>> 
>>> with <length> specifying the trap distance to the edge.
>>> 
>>> 
>> This looks really good to me. Why would you want inherit though?
>> 
>> - E
> 
> If you have a scrolling element inside another scrolling panel you might want to inherit the scrolling
behavior, so you see e.g. the bottom-most element inside of it. Though I'm not sure if that's a common use case.
> 
> Anyway, I'd also suggest a shorthand for the syntax above:
> 
> overflow-attachment: [normal | top | bottom] || [normal | left | right] || <length>{1,2} | inherit

'overflow-attachment' is way better than 'scrollbar-attachment' (which sounds like it affects
scrollbar rendering), but this doesn't feel like something that should be in CSS.

I also agree with David Baron; this is an area where both web sites and UAs can do smart/inventive things to
improve the user experience, and a simple binary CSS switch is insufficient to capture all the kinds of
things that could be done.

Simon

headers

Tab Atkins Jr. | 15 Jun 2012 20:28

Re: [css4-ui] Scrollbar tracking control

On Fri, Jun 15, 2012 at 11:18 AM, Simon Fraser <smfr <at> me.com> wrote:
> 'overflow-attachment' is way better than 'scrollbar-attachment' (which sounds like it affects
scrollbar rendering), but this doesn't feel like something that should be in CSS.

CSS or not, it should be declarative.  The CSS UI module has similar
types of controls.

> I also agree with David Baron; this is an area where both web sites and UAs can do smart/inventive things to
improve the user experience, and a simple binary CSS switch is insufficient to capture all the kinds of
things that could be done.

I don't think UAs can do inventive things - there's no solid
heuristics - though I'd be interested in being proved wrong.  Websites
might be able to do smart and inventive things, but the whole point of
this suggestion is to make the most common thing trivial, because it's
actually a little tricky to get right.  It doesn't stop them from
continuing to do even smarter things if they think they can pull it
off.

~TJ

headers

Brad Kemper | 20 Jun 2012 18:01

Re: [css4-ui] Scrollbar tracking control

On Jun 14, 2012, at 9:49 PM, Sebastian Zartner wrote:

> 
> -------- Original-Nachricht --------
>> Datum: Fri, 15 Jun 2012 03:16:39 +0200
>> Von: Bjoern Hoehrmann <derhoermi <at> gmx.net>
>> An: "Tab Atkins Jr." <jackalmage <at> gmail.com>
>> CC: www-style list <www-style <at> w3.org>
>> Betreff: Re: [css4-ui] Scrollbar tracking control

[…]

>> Scrollbars are an interface that represent and allow to control which
>> part of an element is rendered. The `-ms-scrollbar-*` properties would
>> control the actual scrollbar, but you generally would not refer to some
>> UI control in order to manipulate concepts they are an interface to.
>> You would not have a property `volume-slider: 100%` for `volume: 100%`.
>> And if this was to work with overflow:hidden, say because you have some
>> touch UI or because you don't actually want the user to scroll, then it
>> becomes confusing to set `scrollbar-*` properties, since there is none.
>> And which scrollbar anyway, considering there can be more than one.
> 
> How about this:
> 
> overflow-attachment-x: [normal | left | right] || <length> | inherit;
> 
> overflow-attachment-y: [normal | top | bottom] || <length> | inherit;
> 
> with <length> specifying the trap distance to the edge.

That is on the right track, but the name still feels long. How about 'scroll-top' and 'scroll-left' as the
property names? Then if you use JavaScript's scrollTop to get the scroll position, for instance, or
jQuery's scrollTop to get or set the scroll position, then it would refer to how far it was scrolled
vertically from the edge specified in this CSS property. And it could be writing mode dependent, if we also
had those keywords (er, begin/stop and head/foot? Or whatever it is this week?).

headers

Maciej Stachowiak | 2 Jul 2012 00:16

Re: [css4-ui] Scrollbar tracking control


On Jun 14, 2012, at 5:14 PM, Tab Atkins Jr. <jackalmage <at> gmail.com> wrote:

> On Thu, Jun 14, 2012 at 4:59 PM, Bjoern Hoehrmann <derhoermi <at> gmx.net> wrote:
>> * Tab Atkins Jr. wrote:
>>> I request that we add an explicit control for this, such that if a
>>> scrollbar is currently scrolled against a particular edge, it can be
>>> made to "stick" to that edge when the content width/height changes.
>>> Something like:
>>> 
>>> scrollbar-attachment: normal | edge;
>> 
>> This is not really controlling the scrollbar, especially not if there is
>> none, so the name seems wrong;
> 
> Explain? I'm not sure how this isn't controlling the scrollbar.

>From your description it sounds like it is controlling the scroll position, as opposed to the position of
the scrollbar as a whole, which is what "scrollbar-attachment" seems to imply. You could say it's
controlling the position of the scrollbar thumb, but (a) it's wrong to refer to just the thumb as the
scrollbar; (b) the thumb position is determined by the scroll position, so describing the property as
controlling attachment of the scrollbar thumb would be reversing cause and effect; and (c) this property
could plausibly have an effect even in cases where no scrollbar is visible at the moment, such as the
default state when not actively scrolling on OS X or iOS.

(It might be that I'm just misunderstanding the proposal though; it was hard to follow the original
description.) 

Regards,
Maciej

headers

Elliott Sprehn | 15 Jun 2012 02:14

Re: [css4-ui] Scrollbar tracking control

On Thu, Jun 14, 2012 at 4:34 PM, Tab Atkins Jr. <jackalmage <at> gmail.com> wrote:

...

I request that we add an explicit control for this, such that if a
scrollbar is currently scrolled against a particular edge, it can be
made to "stick" to that edge when the content width/height changes.
Something like:

scrollbar-attachment: normal | edge;

...

Thoughts?

This is something I've wanted for a long time because so many apps get this wrong, but I don't think it's attachment behavior you want, it's changing the direction the inside of the scroll view seems to "extend" towards.

For example if scrollTop = 0, there's no overflow and you insert 20 new messages into the chat window you want the scrollbar to stay stuck at the bottom not the top. With just "edge" this case is ambiguous since it was touching both edges at the start since there was no overflow.

Something like overflow-growth-direction: top | bottom;

There's probably a better name for this concept though.

- E

headers

Sebastian Zartner | 22 Jun 2012 07:59

Re: [css4-ui] Scrollbar tracking control

> > How about this:
> >
> > overflow-attachment-x: [normal | left | right] || <length> | inherit;
> >
> > overflow-attachment-y: [normal | top | bottom] || <length> | inherit;
> >
> > with <length> specifying the trap distance to the edge.
>
> That is on the right track, but the name still feels long. How about
> 'scroll-top' and 'scroll-left' as the property names?
'scroll-top' and 'scroll-left' don't hit the point in my eyes (also not in JavaScript) and having a longer name isn't always bad as long as it is more descriptive as a short one.
My proposal would also have the benefit that you could combine the value in the 'overflow' property and use it as shorthand property. E.g. like this:

overflow: scroll normal bottom;

> And it could be writing mode dependent, if we also had those
> keywords (er, begin/stop and head/foot?
Yes, I didn't consider this before. What about begin/end for both properties? What are other properties using here?

> Or whatever it is this week?).
Of course it should be something consistent with other properties' values.

The alternative (when staying with left/right and top/bottom) would be to use the :dir() pseudo-class [1]. So somebody would have to write this to cover different writing modes:

#foo:dir(ltr) {
overflow-attachment-x: right;
}

#foo:dir(rtl) {
overflow-attachment-x: left;
}

As far as I saw there's no pseudo-class for the writing mode yet, so bottom-to-top texts couldn't be covered with this approach.

Sebastian

[1] http://dev.w3.org/csswg/selectors4/#dir-pseudo

--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

headers

Brad Kemper | 22 Jun 2012 17:53

Re: [css4-ui] Scrollbar tracking control

On Jun 21, 2012, at 10:59 PM, "Sebastian Zartner" <sebastianzartner <at> gmx.de> wrote:

> > > How about this:
> > > 
> > > overflow-attachment-x: [normal | left | right] || <length> | inherit;
> > > 
> > > overflow-attachment-y: [normal | top | bottom] || <length> | inherit;
> > > 
> > > with <length> specifying the trap distance to the edge.
> > 
> > That is on the right track, but the name still feels long. How about
> > 'scroll-top' and 'scroll-left' as the property names?
> 'scroll-top' and 'scroll-left' don't hit the point in my eyes (also not in JavaScript)

You mean it just doesn't feel right? I kind of like that things like scrollTop in JavaScript or jQuery would
just use the edge picked by the CSS author, and so using the same naming convention would make it easy to
understand and remember. 

> and having a longer name isn't always bad as long as it is more descriptive as a short one.

Sure. But you have to admit, 'overflow-attachment-y' is pretty darn long. I don't think it is really
describing it that well. 'overflow-anchor[-x | -y]' would be better, since it it the part of the content
box that is anchored to the named edge while everything else gets pushed away from it. But I still prefer
'scroll-top' and 'scroll-left'.

> My proposal would also have the benefit that you could combine the value in the 'overflow' property and use
it as shorthand property. E.g. like this:
> 
> overflow: scroll normal bottom;

Sure. You could still do that with my naming variation, since I am not touching the values. I think your
better argument is to have a  'overflow-attachment' shorthand property that combined x and y, like this:

overflow-attachment: <overflow-attachment-x> <overflow-attachment-y>

Which could then be shorthanded into 'overflow' as you suggested:

overflow: <overflow-attachment>

So, my version would be like this:

scroll-anchor: <scroll-left> <scroll-right>
overflow: <scroll-anchor>

> > And it could be writing mode dependent, if we also had those 
> > keywords (er, begin/stop and head/foot?
> Yes, I didn't consider this before. What about begin/end for both properties? What are other properties
using here?

I think flex-box is doing that (start/end for both vertical and horizontal), but only because, uh, well, I
a, not the best one to explain that. I think because it needs to have a vertical and horizontal that are more
divorced from writing mode. Or something. Sorry I haven't been following that quite as closely. 

> > Or whatever it is this week?).
> Of course it should be something consistent with other properties' values.

Agreed. I'm being a bit snarky because start/end are apparently well established for bidirectional
writing, but still hard for me to remember, because the opposite of "start" should be "stop" or "finish",
and the opposite of "end" should be "begin" (you even paired begin/end):

~ One can start smoking and stop smoking, but it is quite a different thing to end smoking. 

~ One can start running in a race when the starting gun is fired, and stop running when they reach the
finishing line, but the race doesn't end until everyone is done or some time limit is reached. 

~ books, articles, movies, and songs all have beginnings and endings. You can start or stop reading,
watching, or listening at any point, but the piece generally begins at the beginning and ends at the ending
(you can personally start reading, watching, or listening at the beginning, and stop reading, watching,
or listening at the end, or you could just start and stop reading, watching, or listening to a middle part). 

Anyway, if you only wanted two directions, it would be start/end, because those keyword are established
for bidi. But I think you'd not get away with that. You need all 4 logical directions to be consistent with
most other things that (will) have four logical directions. The other two are under discussion to change
from before/after to head/foot.  

> The alternative (when staying with left/right and top/bottom) would be to use the :dir() pseudo-class
[1]. So somebody would have to write this to cover different writing modes:

I don't like that. It seems clumsy and awkward to me.

headers

Sebastian Zartner | 30 Jun 2012 00:41

Re: [css4-ui] Scrollbar tracking control

> You mean it just doesn't feel right?
Well, yes.

> > and having a longer name isn't always bad as long as it is more
> descriptive as a short one.
> 
> Sure. But you have to admit, 'overflow-attachment-y' is pretty darn 
> long.
Sure, it's not the shortest name. And I am open for other suggestions.

> I don't think it is really describing it that well. 'overflow-
> anchor[-x | -y]' would be better
Sounds ok to me.

> > My proposal would also have the benefit that you could combine the
> > value in the 'overflow' property and use it as shorthand property. 
> > E.g. like this:
> > 
> > overflow: scroll normal bottom;
> 
> Sure. You could still do that with my naming variation, since I am not
> touching the values. I think your better argument is to have a 
> 'overflow-attachment' shorthand property that combined x and y, like 
> this:
> 
> overflow-attachment: <overflow-attachment-x> <overflow-attachment-y>
> 
> Which could then be shorthanded into 'overflow' as you suggested:
> 
> overflow: <overflow-attachment>

Yes, that's one benefit of my proposal.

> So, my version would be like this:
> 
> scroll-anchor: <scroll-left> <scroll-right>
> overflow: <scroll-anchor>

Normally longhand property names are having the shorthand property name as prefix. Having
'scroll-anchor' people probably wouldn't know that they can put it into 'overflow'.

> > > And it could be writing mode dependent, if we also had those 
> > > keywords (er, begin/stop and head/foot?
> > Yes, I didn't consider this before. What about begin/end for both
> properties? What are other properties using here?
> 
> I think flex-box is doing that (start/end for both vertical and
> horizontal), but only because, uh, well, I a, not the best one to 
> explain that. I think because it needs to have a vertical and 
> horizontal that are more divorced from writing mode. Or something. 
> Sorry I haven't been following that quite as closely.
I don't believe people would mix up the writing mode with flexbox. But that's not the topic of this issue.

> > > Or whatever it is this week?).
> > Of course it should be something consistent with other properties'
> values.
> 
> Agreed. I'm being a bit snarky because start/end are apparently well
> established for bidirectional writing, but still hard for me to 
> remember, because the opposite of "start" should be "stop" or "finish", 
> and the opposite of "end" should be "begin" (you even paired begin/end):
> 
> ~ One can start smoking and stop smoking, but it is quite a different
> thing to end smoking. 
> 
> ~ One can start running in a race when the starting gun is fired, and 
> stop running when they reach the finishing line, but the race doesn't 
> end until everyone is done or some time limit is reached. 
> 
> ~ books, articles, movies, and songs all have beginnings and endings. 
> You can start or stop reading, watching, or listening at any point, but 
> the piece generally begins at the beginning and ends at the ending (you 
> can personally start reading, watching, or listening at the beginning, 
> and stop reading, watching, or listening at the end, or you could just 
> start and stop reading, watching, or listening to a middle part).
Ok, thanks for the good examples. They really clarify this. So it sounds I wasn't that wrong with begin/end
even when I'm not a native English speaker. 

> Anyway, if you only wanted two directions, it would be start/end, 
> because those keyword are established for bidi. But I think you'd not 
> get away with that. You need all 4 logical directions to be consistent 
> with most other things that (will) have four logical directions. The 
> other two are under discussion to change from before/after to 
> head/foot.
As I said as long as it complies with other directional property values I think it's fine.

> > The alternative (when staying with left/right and top/bottom) would be
> to use the :dir() pseudo-class [1]. So somebody would have to write
> this to cover different writing modes:
> 
> I don't like that. It seems clumsy and awkward to me.
I agree. I just mentioned it to point out an alternative.

Sebastian
--

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de