Open Bug 619963 Opened 14 years ago Updated 2 years ago

The position of the scrollbar for iframes with RTL content embedded in RTL documents should be on the left side

Categories

(Core :: Layout, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: ehsan.akhgari, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: rtl)

Attachments

(1 file)

See the test case here: <http://www.w3.org/People/kennyluck/Test/bidi-scrollbar>.  The scrollbar for the Hebrew wikipedia iframe should appear on the left side, and its position should not depend on the layout.scrollbar.side pref.
See Also: → 556363
To be precise, the scrollbar side in a frame or iframe should depend only on the direction of its document (i.e. the embedded body element). If the embedded document is LTR, it should be on the right; if it is RTL, it should be on the left.
I know people have come to expect this behaviour but personally I think putting the scrollbar on the side that is typically further away from the text you are reading or editing is a huge usability problem that has led to the development of crutches such as scrollwheels.

For LTR languages the scrollbar should be on the left and for RTL languages on the right so it is near the text and not all the way on the other side of the screen. I think that this nonsense originated because some right-handed designer years ago felt awkward at the idea of controlling a scrollbar on the left with his or her right hand. Then when the first RTL localization was done, someone else thought they needed to change the side of the scrollbar.
(In reply to Mark Callow from comment #2)
> I know people have come to expect this behaviour but personally I think
> putting the scrollbar on the side that is typically further away from the
> text you are reading or editing is a huge usability problem that has led to
> the development of crutches such as scrollwheels.
> 
> For LTR languages the scrollbar should be on the left and for RTL languages
> on the right so it is near the text and not all the way on the other side of
> the screen. I think that this nonsense originated because some right-handed
> designer years ago felt awkward at the idea of controlling a scrollbar on
> the left with his or her right hand. Then when the first RTL localization
> was done, someone else thought they needed to change the side of the
> scrollbar.

This is really a comment on scrollbars generally, not on iframes specifically, so I assume this comment does not really belong on this bug. Furthermore, if I understand correctly, you do agree that the correct behavior is to depend on the element directionality, not to put the scrollbar on the same absolute side always. On iframes, however, scrollbars currently are always on the right, regardless of iframe direction or iframe document direction. That is what this bug is about.

Nevertheless, in response to your original point:

1. Browser interoperability (scrollbar on the end side of internal elements other than iframes) has finally been achieved (across IE, Mozilla and Chrome). Even if having the scrollbar on the start side really were a better UX (of which I am not at all sure), I do not think that it is worth breaking interoperability again.

2. User expectations are a fact and should not be ignored.

3. Having the scrollbar on the start side means that the content gets shifted over when the scrollbar appears. This is poor UX.

4. Furthermore, pages that need to align something with (or over) the content (not the scrollbar) have a harder time calculating the content's horizontal position (it depends on whether there is a scrollbar). Changing this retroactively would break many pages.
To clarify the current status, the scrollbar is always on the right, even if both the <iframe> and the document inside it have direction:rtl. This is clearly incorrect.

For an <iframe>, the scrollbar should be on the start side of the document inside it (even though that is *not* the case when the same document is displayed in a separate tab, not an <iframe>). If the thing inside the <iframe> does not have a direction, e.g. it is an image, it should be on the start side of the <iframe>'s direction. (If the latter requirement is very difficult to achieve, though, it can be relaxed.)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: