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

On Wed, Jun 5, 2013 at 10:55 AM, Simon Pieters <> wrote:

> On Mon, 06 Aug 2012 13:07:10 +0200, Robert O'Callahan <
>> wrote:
>  How should scrollLeft work with RTL? There are some major differences
>> across browsers.
>> 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.

It seems to me that the current CSSOM draft results in inconsistent
behavior between scrollLeft on the root element and scrollLeft on other
elements: when the entire document is RTL, scrollLeft on the root element
returns negative values when the viewport is scrolled to the left, but when
a normal element is scrolled to the left, scrollLeft does not return
negative values. Is that correct? Because that doesn't seem very sane to me

Greg, this is an issue where Microsoft feedback would be helpful.

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w

Received on Sunday, 13 April 2014 22:28:35 UTC