Right-to-Left Reading Order Support

[uqpik]

Please provide Right-to-Left reading order layout. An RTL version of jQueryMobile 1.1.0 can already be found at http://www.intlaqa.com/jquery-mobile-rtl/

[skoant]

+1 for rtl support

[Fady1956]

same here.
can you incorporate right to left in the jquery mobile? there is already a working implementation that we use available and the changes do not seem hard to implement.

[toddparker]

I attempted to reach out to the person from intlaqa.com a while back to see if he'd be interested in maintaining this as part of the official codebase but didn't hear back. We'd like to have someone with expertise in this on the team to keep it up-to-date before we added it. Any help appreciated, we'd like to support this.

[Fady1956]

Moutaz Shams can be reached on his facebook page at https://www.facebook.com/intlaqa.
Actually I reached out to him to see if he has plans to produce a version 1.3 beta and he replied that he would rather wait till the final version, which makes sense :)
I will send him a message to see if he is interested in joining your team.
anyway, many thanks guys for all your work.

[toddparker]

I left a facebook message this weekend...

[Fady1956]

I communicated with him and he agreed in principle to do it. let us hope it goes through for the benefit of all involved

[jaspermdegroot]

Issue #5440 is about a problem that occurs when you use "rtl" in combination with a form as wrapper of your JQM pages. Something to take into account when working on full support for "rtl".

[jaspermdegroot]

Closing as feature request. After 1.4 final release we are going to update the roadmap and set a specific milestone. The ticket will be re-opened when we are going to work on implementing the feature.

[gwhenne]

+1

[eMosbat]

need this

[ailaG]

+1. Is there anything new on the RTL / jQuery Mobile front?

[arschmitz]

This is something we want to support but we need someone with more knowledge then we have on the subject to help out with it. I talked to someone last week hopefully they come through! PR's welcome!

[mokhtarabadi]

+1

[rhelms]

I see there's still nothing proposed in the roadmap, regarding RTL support.

Just having some thoughts on how this might be done.

Moutaz Shams approach was to create a dedicated RTL version, where particular edits were done to swap left and right classes, in the CSS and JS, and make additional edits were required. I can see why he decided not to continue with generating RTL versions once the requirejs approach was taken.

I'm thinking about doing something similar (a RTL conversion for jqm 1.4.5), but I would like to do it in a fashion that has a bit more longevity. Perhaps a fork from the final 1.4.5 release so that upgrades can easily be applied.

My initial thoughts are to have CSS styles that use either dir="rtl" or a rtl class in the html element. Try to support RTL functionality for only a portion of a page might be a bit too much to ask, especially if it the page has a default of RTL, and then is expected to have a portion as LTR. Looking at the support for attribute selection (html[dir="rtl"] or [dir="rtl"]), I might be safer using an actual rtl class.

My next thought is how to support RTL in the JS. Perhaps a rtl property in jquery.mobile.defaults.js that is set to false. And perhaps a jquery.mobile.rtl.js or an update of jquery.mobile.support.js to provide $.mobile.rtl as returning true or false, based on the rtl class on the html element (or dir="rtl" attribute on the html element). Given that RTL would be global for the page, it might be better to not bother with the default, and just provide as a mobile property. Then any particular classes that need to know if they should be using right or left properties or styles can inspect that value.

[rhelms]

I started doing some work on this. My previous experience with jqm is 1.2, and my how things have changed.

I'm attempting to do a conversion on 1.4.5, and for my first widget to attempt to convert is the button, it's an interesting time to pick it. The button markup is about to be deprecated, and functionality from 1.5 onwards dictates that you need to specify the icon position yourself, via classes.

I've updated the widgets/forms/button.js to place the correct default ui-btn-icon-* class, based on the closest parent being .ui-rtl or .ui-ltr, defaulting to the left option. I still want to call a spade a spade, and thus, still want the left and right specific classes to actually refer to the left and right.

In the back of mind is the seed of an idea that a lazy conversion option might be warranted, where an otherwise LTR page can be easily converted to RTL, without having to introduce ternary operators on every right or left specific class. I'm thinking specifically of multilingual sites that are predominately LTR.

[rhelms]

I'm still continuing work on this, but have a question about convenience.

The latest jqm preference is to explicitly state the CSS styles on any particular widget.

The convenience of a .ui-rtl class is great for coming up with right and left defaults, however, when you explicitly have to put right or left styles on a widget (like .ui-btn-left and .ui-btn-right in a header bar), the convenience of .ui-rtl is a little lost.

Now your app has to be more RTL aware than normal, if .ui-btn-left is to be placed on the button and still mean left, even in a RTL environment. Things would be different if there was a .ui-btn-first and .ui-btn-last (or .ui-btn-start and .ui-btn-end) classes in which the order of elements with these classes would indicate if it were to be at the start or end of the flow. i.e. the first element with .ui-btn-first would be at the extreme left in a LTR environment, and subsequent elements of the same class would follow, and in a RTL environment, it would be at the extreme right.

Anyway, I'm just sounding out if it would be preferred that .ui-btn-left remain left, even in a RTL context, or if the presence on .ui-rtl in a parent element would cause it to be interpreted as right. I'm thinking that default functionality should remain the former, with custom CSS for those who wish to flip the *-left and *-right classes on their heads for specific functionality. Perhaps in a future release that did proper support for RTL, *-left and *-right classes would be dropped or renamed, or complemented with *-start and *-end classes when it comes to ordering of elements.

[arschmitz]

@rhelms we have been recently working with IBM Bidi labs to work towards proper RTL implementation. Unrelated to that we already have renamed these classes to *-beginning / end

I will get meeting notes from these talks and link them here shortly

[arschmitz]

@rhelms also worth noting the options are beginning and end but the icons are now positioned inline and dont have classes to indicate their position making RTL not an issue for them any more.

[rhelms]

@arschmitz the usage of *-beginning / end is awesome, and actually working on a proper RTL implementation is awesome, too. The other part of class naming for icons is for when the icon itself has an indication of directionality, but is has *-l / r in the name. For example, the icon arrow-r is often used to indicate a forward facing arrow (as far as LTR is concerned) for more options in a listview. Aliasing these icons to arrow-next, arrow-previous, carat-next, carat-previous, etc, to arrow-l, arrow-r, carat-r, carat-l depending on the current context (RTL or LTR) would save applications having to swap these icons around themselves.

It would also be good if a proper RTL implementation also supported LTR within a RTL context for screens where multiple languages and orientations of text are required. I've done my best to try an implement that in my modifications, and have provided demos of that functionality.

Looking forward to reading those talks.

[gnanaswaroop]

Any update on supporting RTL now ?

[arschmitz]

@rhelms the implementation we are working on is Bidi so it does support nesting. Icons are complicated because my understanding from working on this is that many icons should not flip in a rtl vs ltr context. The best examples is progress controls from players things like play fast forward etc by default should not flip, in addition many icons are symmetrical and so therefore should not flip.

@gnanaswaroop This is being implemented in UI first since mobile depends on much of UI. There is a PR here jquery/jquery-ui#1682 This is in progress but cant be landed until UI 1.12 final is release ( Wont be long we are on RC3 ) This will likely land in Mobile 1.6 which should be a quick release after the very long 1.5

[gnanaswaroop]

@arschmitz Any tentative timeline for Mobile 1.6 release ?

[matingholami]

+1 for officially RTL support, and although when I have to edit almost all css and most js files to make JQM work, why I must use it???