Make scrollLeft consistent and interoperable in RTL |
|||||||||
Issue descriptionUserAgent: 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 the problem: 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. What is the expected behavior? What went wrong? Non-interoperable. Did this work before? No Does this work in other browsers? Yes Chrome version: 58.0.3029.96 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
May 14 2017
,
May 15 2017
,
May 31 2017
,
Jun 29 2017
,
May 14 2018
WebKit matches Gecko. Test case from WebKit - https://bug-172028-attachments.webkit.org/attachment.cgi?id=311474 Blink uses negative scrollLeft values for document-level scrolls and positive/regular for element-level scrolls. This is confusing. Edge still uses reverse (right most is 0). Can a use counter be added for the combination (scrollLeft and RTL)?
,
May 14 2018
The document-level behavior should be applied to the element-level behavior as well in order to be interoperable with Gecko and WebKit.
,
Oct 23
Updating the component since it seems this is related to Scrolling. I think we should prioritize fixing this issue. The fact that Document scroll offset behave differently than inner scroller scroll offsets is bad alone. Worse is that this is different from other vendors. My hope is that since now both WebKit and Safari match we are able to change this without a lot of backward compat concern. I have attached a test case for inner scrollers which shows Blink is different from others. The testcase in #6 shows that document now works correctly.
,
Oct 23
Issue 499649 has been merged into this issue.
,
Oct 26
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by phistuck@chromium.org
, May 12 2017Status: Untriaged (was: Unconfirmed)