[Webkit-unassigned] [Bug 172028] New: scrollLeft in RTL in not interoperable

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 12 07:17:35 PDT 2017


            Bug ID: 172028
           Summary: scrollLeft in RTL in not interoperable
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: CSS
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: phistuck at chromium.org

Please, join the discussion at https://github.com/w3c/csswg-drafts/issues/1354 for closing this one once and for all.

>From https://github.com/othree/jquery.rtl-scroll-type -
Horizontal scrollbar with rtl(right to left) language support have different implement in different browsers.

[scrollLeft][mdn-scrollleft] in rtl element is not defined by any spec or standards. So different browser have different implement.
As far as I know, there are 3 implements: WebKit, Firefox/Opera, IE. WebKit's implement is the most easy to use implement.

Exactly the same as ltr(left to right) element. Except the initial position of scrollbar controller is at most right position.

Firefox has a clearly define in their mdn document. The most right position stands for 0. And when user scrolls to left. The value decreases. The value is possible to be negative in this implement.

IE thought the element is flip horizontal. So the most right position is 0. And if it scrolls to left. The value increase.

A table is below to make these cases more clear.

3 Types of scrollLeft (scrollWidth = 100)

Browser   Type       Most Left  Most Right  Initial
WebKit    default    0          100         100
Gecko     negative   -100       0           0
IE        reverse    100        0           0
The current cross-browser situation is pretty awful, the most sane behavior (whichever it may be) should be specified.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170512/cc969511/attachment-0001.html>

More information about the webkit-unassigned mailing list