Closed Bug 1364451 Opened 9 years ago Closed 8 years ago

scrollLeft in RTL in not interoperable

Categories

(Core :: DOM: CSS Object Model, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: phistuck, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Steps to reproduce: 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.
So Gecko's behavior seems to be the most useful one, and WebKit now matches Gecko per https://bugs.webkit.org/show_bug.cgi?id=172028 Closing this as INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.