[css-overflow] Positioning Scrollbars on top or left of container

[praveenpuglia]

From time to time, I have encountered cases where having a horizontal scrollbar at the top or left would be more helpful than having it at the bottom. For example, consider a long table that forces a vertical scrollbar. Also, it has so much content that the space required on horizontal axis is more than what viewport width can provide.

Or when something like bootstrap responsive table is needed, which has a horizontal scroll in smaller screen-size.

A lot of times, due to the amount of vertical content, the presence of a horizontal scrollbar is not known to the end user or they have to scroll further down where they can't see table headers anymore. As a result, users don't realize that the content can be scrolled.

The situation is worse for mobile browsers because they generally have overlay scrollbars which only appear when you at least tap on the content.

Chrome on phones at least give a flash as to which containers have scrollbars and then it goes away.

In these sort of cases and others like (RTL languages) wouldn't it be great to have an option to change the position of the scrollbars?

Right now, the trick that I use is something like this.

.parent {
  transform: rotateX(180deg);
  overflow-x: auto;
} 
.child {
  transform: rotateX(180deg);
}

This way, the horizontal scrollbar appears on top. This hack however isn't all that great and has it's own problems.

I know that scrollbar is a browser chrome thing and it's still not allowed to style by end users for reasons. But can there be properties that at least let the users set the position of scrollbars?

For example

.parent{
  scrollbar-x-position: top; /*either top or bottom, default is bottom or dir based*/
  scrollbar-y-position: left; /*either left or right, default is right or dir based*/
}

I'll be happy to know the reasons if this was thought before and dropped.

[fantasai]

If I'm understanding this correctly, it seems more of a quality-of-implementation issue -- the browser UI should be doing better at indicating scrollable boxes (and, ideally, making them scrollable) when the scrollbar is off-screen.

[praveenpuglia]

Right. Browsers should probably show the scrollbar or some sort of cue to let users know that an element is scrollable and in which direction. If they do that, these properties won't be needed.

I am, however, wondering how difficult it is to get the browsers to even think about it. Also, on smaller devices, they try to maximize the space for content by overlaying scrollbars and hiding them when not needed. What the alternatives can be.

Is there something that I can do on my part to trigger at least a discussion on it?

[mazhiwen]

hope it could have a good solution

[fantasai]

@praveenpuglia I guess, file bugs against the browser vendors with some good motivating examples?

I do think dictating scrolling UI should be out-of-scope for the CSS specs.

[frivoal]

For overlay scrollbars, I would tend to agree that the UA should be free to be smart and put them on the more useful side if it wants to. We probably do not want that for scrollbars that consume space, because that putting the scrollbar on the left side instead of the right one would shift the content horizontally, potentially putting it out of visual alignment with content outside the scrollable area.

I think it may be interesting to consider potential interactions with scrollbar-gutter (defined in level 4), since that can be used to reserve space on both sides.

[kamikadza]

It's genius.

[bradkemper]

On Mar 6, 2018, at 2:14 AM, Florian Rivoal ***@***.***> wrote: For overlay scrollbars, I would tend to agree that the UA should be free to be smart and put them on the more useful side if it wants to. We probably do not want that for scrollbars that consume space, because that putting the scrollbar on the left side instead of the right one would shift the content horizontally, potentially putting it out of visual alignment with content outside the scrollable area.

NeXT desktop had scroll bars on the left. The OS really can put them wherever it wants. https://m.imgur.com/GqVO6bZ

[jonjohnjohnson]

My first thought on this is that in most cases, it's not worth the confusion for a user to put scrollers on the top/left, when convention is bottom/right. And I'd hope standards would emphasis the usability afforded by familiarity in this case.

Second thought is that this issue primarily arises from poorly conceived layouts in the first place. This is mostly an issue if a nested scroller (not the scrollers content) is wider/taller than the scroller it is within. Which I agree causes poor usability, but the solution might not be to move scrollbars to unintuitive areas of their scrollport.

A request for "sticky" scrollbars has been brought up previously, #2252, addressing a similar problem, but its ask, I believe, would make scrollbars behave similar to the sticky position scheme against the edges of the scrolling elements scroll parent. Which I *think, is a more desirable solution than the request here, even if I think it could sometimes have strange scrollbar visuals. Think when a horizontally scrollable table first scrolls into the viewport it's bottom sticking scrollbar would move in at the top edge of the table, though "mounting" to the bottom edge of the viewport until reaching the bottom edge of table?

All in all, I'm guessing internal scrollers best practice should follow a rule of never being larger, in either axis, than the scroller (often viewport, using max-width/max-height with vw/wh) within which they are nested.

Also, note the mostly bulletproof table, affording sticky labels for rows and columns from @SimplyPhy https://codepen.io/SimplyPhy/pen/oEZKZo. This type of table following the practice described above should be all we need?

[jonjohnjohnson]

And note discussion about standards, convention, and usability in #1936 - Change the pointer cursor to indicate any interactive element.

[JLademan]

My first thought on this is that in most cases, it's not worth the confusion for a user to put scrollers on the top/left, when convention is bottom/right. And I'd hope standards would emphasis the usability afforded by familiarity in this case.

Second thought is that this issue primarily arises from poorly conceived layouts in the first place. This is mostly an issue if a nested scroller (not the scrollers content) is wider/taller than the scroller it is within. Which I agree causes poor usability, but the solution might not be to move scrollbars to unintuitive areas of their scrollport.

A request for "sticky" scrollbars has been brought up previously, #2252, addressing a similar problem, but its ask, I believe, would make scrollbars behave similar to the sticky position scheme against the edges of the scrolling elements scroll parent. Which I *think, is a more desirable solution than the request here, even if I think it could sometimes have strange scrollbar visuals. Think when a horizontally scrollable table first scrolls into the viewport it's bottom sticking scrollbar would move in at the top edge of the table, though "mounting" to the bottom edge of the viewport until reaching the bottom edge of table?

All in all, I'm guessing internal scrollers best practice should follow a rule of never being larger, in either axis, than the scroller (often viewport, using max-width/max-height with vw/wh) within which they are nested.

Also, note the mostly bulletproof table, affording sticky labels for rows and columns from @SimplyPhy https://codepen.io/SimplyPhy/pen/oEZKZo. This type of table following the practice described above should be all we need?

Excellent point, not sure how this got voted down. This inspired me to apply a max height to the box that made a lot more sense, rather than lifting the scrollbar.

This feature request is a kind of XY problem.