Re: [cssom-view] value of scrollLeft in RTL situations is completely busted across browsers

On Mon, 06 Aug 2012 13:07:10 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> How should scrollLeft work with RTL? There are some major differences
> across browsers.
> http://people.mozilla.org/~roc/test_rtl_scrollLeft.html
> Try scrolling the elements and clicking in them.
>
> In Gecko nightly, scrollLeft=0 corresponds to the rightmost scrolled
> position and increases from left to right (so scroll positions are
> negative). Opera seems to behave the same way.
>
> Chrome (22 dev) behaves the same way when scrolling the viewport (for  
> both
> toplevel documents and iframes). Unfortunately scrolling a regular  
> element
> works quite differently: scrollLeft=0 corresponds to the leftmost scroll
> position (but still increases to the right).

Currently the spec requires the behavior Chrome has for elements, that is,  
physical dimensions with 0 being on the left and increasing to the right,  
regardless of block flow direction and inline base direction. This seems  
like the most sane thing to me.

> In IE9, scrollLeft=0 corresponds to the rightmost scrolled position but
> scrollLeft increases as you scroll from right to left!
>
> I'm unsure which behavior is best. I think most Web content I've seen  
> that
> uses scrollLeft assumes its minimum value is zero and it increases from
> left to right, because of course that's how LTR behaves. Unfortunately
> that's almost the least popular option in implementations. I'm  
> considering
> changing Gecko to do it that way for RTL anyway. AFAIK the main
> disadvantage of that approach (other than being a behavior change) is  
> that
> you lose the ability to easily scroll "to the start" by setting  
> scrollLeft
> to 0. Then again, I haven't noticed people trying to do that on the
> horizontal axis.
>
> Any thoughts, before I go ahead? :-)
>
> Rob

Scrolling to the "start" is handled by navigating to #top, at least for  
viewports. Is there a use case for doing that for elements?

Is there a use case for scrolling along a logical axis instead of physical  
axis? It's possible to work around the lack of this feature with the  
current APIs (assuming browsers behave the same, at least).

I think we should wait with introducing logical scrolling APIs until we  
have interop on the current set of APIs and there is a demand from authors  
for logical scrolling APIs (e.g. popular frameworks implement such APIs).

-- 
Simon Pieters
Opera Software

Received on Tuesday, 4 June 2013 22:55:04 UTC