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

On Tue, 15 Apr 2014 02:31:48 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> BTW let me summarize the current state of the situation as I understand  
> it:
>
> Behavior A: For RTL, attribute value 0 means scrolled all the way to the
> right, and attribute value increases as you scroll left.
> Behavior B: For RTL, attribute value 0 means scrolled all the way to the
> right, and attribute value increases as you scroll right.
> Behavior C: For RTL, attribute value 0 means scrolled all the way to the
> left, and attribute value increases as you scroll right.
>
> FF: B for window.scrollX, B for non-body non-root scrollLeft
> Chrome: B for window.scrollX, C for non-body non-root scrollLeft
> IE: A for window.scrollX, A for non-body non-root scrollLeft (can someone
> check with http://people.mozilla.org/~roc/test_rtl_scrollLeft.html? I  
> don't
> have IE here)
> Spec: B for window.scrollX, C for non-body non-root scrollLeft (but Simon
> wants window.scrollX to be C)
>
> One other thing: currently pageXOffset is implemented by all browsers and
> the spec to have behavior B. If the spec changes the definition of
> window.scrollX, the definition of pageXOffset needs to be changed to not
> refer to scrollX.

Thanks for the analysis.


On Tue, 15 Apr 2014 10:41:48 +0200, James Ross  
<w3c-20040125@james-ross.co.uk> wrote:

> Testing IE11 on Windows 7:
>
>
> Main page: A for documentElement.scrollLeft and B for window.pageXOffset  
> (window.scrollX is undefined).
>
>
> overflow:scroll div: A for scrollLeft.
>
>
> The overflow:scroll iframe test doesn't work because data: isn't  
> supported in that context in IE.

Thanks, so IE uses a mix of A and B, Gecko uses only B and Chrome uses a  
mix of B and C. window.pageXOffset uses B across the board. What about the  
coordinates in MouseEvents/TouchEvents? What behavior should they use?

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2971 tests  
stuff with dir=rtl on the root.

We have two axes: origin and direction. (I'll only discuss the X and skip  
the Y to keep things easier to follow.)

IE11 on Win7:
e.x: origin is 9px (???) to the right of the left edge of the viewport  
when scrolled all the way to the right. Direction is positive rightwards.
e.pageX: origin is the left edge of the viewport when scrolled all the way  
to the right. Direction is positive rightwards.
e.screenX: origin is the left of the screen. Direction is positive  
rightwards.
e.clientX: origin is the left edge of the viewport (regardless of scroll  
position). Direction is positive rightwards.e.offsetX: origin is the left  
padding edge of the element. Direction is positive rightwards.
window.screenX: same as e.screenX
window.pageXOffset: same as e.x

Firefox Nightly 31.0a1 (2014-04-28):
e.x: undefined
e.pageX: origin is the left edge of the viewport when scrolled all the way  
to the right. Direction is positive rightwards.
e.screenX: origin is the left of the screen. Direction is positive  
rightwards.
e.clientX: origin is the left edge of the viewport (regardless of scroll  
position). Direction is positive rightwards.
e.offsetX: undefined
window.screenX: same as e.screenX
window.pageXOffset: same as e.pageX

Chrome 36.0.1962.0 canary:
e.x: origin is the left edge of the viewport (regardless of scroll  
position). Direction is positive rightwards.
e.pageX: origin is the left edge of the viewport when scrolled all the way  
to the right. Direction is positive rightwards.
e.screenX: origin is the left of the screen. Direction is positive  
rightwards.
e.clientX: same as e.x
e.offsetX: origin is the left of the viewport when scrolled all the way to  
the *left*. Direction is positive rightwards.
window.screenX: same as e.screenX
window.pageXOffset: same as e.pageX

A few things to note:

* IE returns subpixel values without opt-in (at least when the parent  
frame is scrolled) for e.x, e.pageX, e.offsetX. (Integer values for  
e.screenX, e.clientX, window.screenX, window.pageXOffset.)
* Direction is uniformly positive rightwards for the tested attributes.
* e.pageX is interoperable.
* e.screenX is interoperable.
* e.clientX is interoperable.
* window.screenX is interoperable.
* e.x, e.offsetX and window.pageXOffset (?) are not interoperable.

On Mon, 14 Apr 2014 22:01:04 +0200, Matt Rakow <marakow@microsoft.com>  
wrote:

> 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.

That is a compelling argument, it's nice when things work as intended  
without the author having to think about RTL. But what is our story for  
the other attributes tested above?

The names imply physical behavior. C is fully physical, A is fully  
logical, and B has the direction physical but the origin logical.

In CSS, 'left', 'top', etc are physical. The origin for 'left' for  
position:absolute for a rtl page that overflows to the left, is the left  
of the viewport when scrolled all the way to the right.

I'm a bit confused as to what we should do here. We presumably can't use  
A-like behavior for *all* things. For instance, it wouldn't make sense for  
window.open's 'left' feature to use the directionality of the document,  
since the document hasn't loaded yet when the window is opened, and hence  
it doesn't make sense for window.screenX to use A-like behavior. So if we  
opt for A for some of these things, we'll end up being internally  
inconsistent. Firefox is closest to being internally consistent, as far as  
I can tell (but it doesn't support all of the attributes). Consistency  
isn't the only consideration of course, but shouldn't be ignored either.

-- 
Simon Pieters
Opera Software

Received on Monday, 28 April 2014 14:05:41 UTC