Proposal for DNN support of RTL layout Part 2

Please read the first part of this post first to better understand this post.
In my first post, I didn’t speak about the number of RTL script language users. They are about 600 millions (300 million in Arabic states (including economically important Persian gulf states), 170 millions in Pakistan, 75 millions in Iran, 30 millions in Afghanistan, etc.). This makes about 10% of the human population use RTL scripts mostly using the Arabic script which is used for many languages not just Arabic. Hebrew script users are 5 millions. Thaana script users in Maldives are 350,000 users.I have no info about Syriac user community but I think they won't be more than 3 millions but not sure.

I want also to clarify part of my previous post that maybe was not clear enough. The RTL CSS should override any property that affects horizontal direction not only float, text-align but also padding, margin, border any other property that affects the horizontal layout as in RTL layout it should be mirrored.
Now, I will continue explaining how to handle images and JavaScript in RTL layout.

Handling images in RTL mode

Usually images shouldn’t be horizontally flipped in RTL mode except:

1. Images that specifies horizontal direction. For example in the image below the required image should be flipped to point to the text box not to point to the empty space beside the empty textbox.

2. Images that are displayed in sequence horizontally as in RTL these images should be flipped to give the same effect. A real life example here is XDNewBlue skin. The skin is having messy layout in RTL mode because of its asymmetric layout. Here I will only show the container in RTL and LTR modes. The container header has 3 consecutive images which when rendered in reverse order were not correct. You will need to reverse second image to have the same layout of LTR flipped horizontally. In this case the image file is specified in a CSS file so the flipped image should be referenced in the RTL CSS file.

Images should be flipped either using:

1. Client side horizontal flipping: this way is done using flipping images using CSS and remove the need to having a separate mirrored image file. After doing some search, I found a solution here. This solution is very good and would work by adding the CSS class below to the element to be flipped. This class should be empty in normal CSS and only having the text below in the RTL CSS file. Unfortunately this solution while it worked on Internet Explorer, Firefox, Safari and Chrome, it didn’t work on Opera browser. If you find any solution for Opera, please send it to me in comments. Please also note that if you apply this style to an element with text, the text will be mirrored which would not make it readable.

.flip-horizontal {
-moz-transform: scaleX(-1);
-webkit-transform: scaleX(-1);
transform: scaleX(-1);
filter: fliph; /*IE*/ }

2. Server side flipping: A more trivial and cross browser way but will require a separate copy of every flipped image file. I suggest if the original image called x.jpg, the flipped one should be called x.rtl.jpg. This is just a naming convention and will not imply automatic loading. You will have to handle programmatically substituting images with flipped ones in case you detect the culture is RTL culture.

JavaScript files in RTL mode

Usually JavaScript code don’t have problems with RTL layout. The catch here is that you should not specify any inline style properties in JavaScript files that affect horizontal layout as possible as you can. Use instead classes specified in CSS files, so they would be correct for both LTR and RTL layout or you will have to programmatically check for RTL and then reverse the style.

To determine the direction client side:

According to Part 1 of this post direction propery is put in the portal.rtl.css file. So the only way to get this value in either use GetComputedStyle in Firefox or currentStyle for Internet Explorer. The function below is inspired from here. The code should be put in js/dnn.js file.

dnn.direction = function() {
if (typeof (dnn.__direction) == "undefined") {
var hElement = document.getElementsByTagName('html')[0];
if (window.getComputedStyle)
dnn.__direction = window.getComputedStyle(hElement, null).direction;
else if (oElement.currentStyle)
dnn.__direction = hElement.currentStyle.direction;
}
return dnn.__direction;
}

Explicit handling of RTL layout in JavaScript

The only case I can think of now is handling absolute positioning set programmatically. Usually this is done in menus. Below the image of DNN menu in RTL layout

As the co-ordinates are not mirrored for RTL layout, the code adjusts the absolute position of menu to the left offset of the button. The solution here for RTL layout is if in RTL layout then it should position the menu = offsetLeft of button - menu width + offsetWidth of button and then the menu will look like the image below

Catches:

Real testing RTL layout should ALWAYS be done using an RTL script. In the screenshots above though text is aligned right but text itself is written from left to right which is not the case with RTL scripts (I took screenshots in English for simplicity). The RTL script is written from right to left. This text direction could affect in some cases the layout. For Example the image below is for Save/Cancel buttons are messed up because Latin script is written left to right regardless of alignment.

As you see the save icon is beside cancel and the cancel icon is beside register. But when the text is really in RTL Arabic script, we see in the image below that everything is OK without doing any change.

Recommendations:

1. Changes to core DNN library and core modules should be done to handle both LTR and RTL layouts automatically.
2. In snowcovered sold modules, there should be some info about if the displayed module is tested in RTL layout with the default to No.
3. Every release of DNN or DNN core modules should be developed with RTL layout in mind and should be tested by a developer that knows a language that is written in RTL script ( There would be a lot of them especially Egyptians, Pakistanis and Israelis)

I didnt discuss the RTL localization of FCK editor. There is a post about it here.
Next week, I will publish the DNN code described here as a proof of concept.