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

Agreed that elements and the document should have identical behavior.

In IE we prioritized certain associations and equivalencies between properties that authors assume.  As one simple example, an LTR author can assume that <div style="position: absolute; left: 200px"> will be in-view and aligned with the left edge of the viewport when scrollLeft is 200.

In IE, the RTL equivalent is that an RTL author can assume that <div style="position: absolute; right: 200px"> will be aligned with the right edge of the viewport when scrollLeft is 200.  Thus an author is able to write a statement like "docElem.scrollLeft = 200" and know that the element is now in view, very much like what can be done in LTR documents.  In Chrome and FF this is true for scrollLeft = -200, which is functionally similar.

By contrast, the Chrome element behavior doesn't provide an easy association.  The element would be aligned with the right edge of the element scroller when scrollLeft = elemScroller.scrollWidth - elemScroller.clientWidth - 200.

In more complex scenarios, discrepancies like these make it difficult/impossible for an author to reuse code between LTR/RTL or at minimum require lots of forking.  And that's assuming the author knew and understood the correct calculations they needed to perform.  For that reason, I don't really like the Chrome element behavior on first impression.  Perhaps there are some other scenarios I'm not thinking of though, where this behavior has an advantage?  I admit I haven't looked through this portion of the CSSOM view spec in great detail.

Thanks,
-Matt

> -----Original Message-----
> From: Simon Pieters [mailto:simonp@opera.com]
> Sent: Monday, April 14, 2014 6:40 AM
> To: Greg Whitworth; Robert O'Callahan
> Cc: www-style
> Subject: Re: [cssom-view] value of scrollLeft in RTL situations is completely
> busted across browsers
> 
> On Mon, 14 Apr 2014 00:28:07 +0200, Robert O'Callahan
> <robert@ocallahan.org> wrote:
> 
> >> 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 :-).
> 
> Hmm. That wasn't the intention. But I can see that "initial containing block
> origin" is maybe the top right corner for RTL? I meant the left edge of the
> initial containing block.
> 
> Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25341

> 
> > Greg, this is an issue where Microsoft feedback would be helpful.
> 
> Indeed. :-)
> 
> --
> Simon Pieters
> Opera Software

Received on Monday, 14 April 2014 20:01:51 UTC