RTL Support: Is There A Right Way Left?

[ibnesayeed]

After reading about the RTL support in 4.2-beta release, I can't express how excited I was so I thought if I may put my two cents in, I would say something like this:

When it comes to RTL, exchanging right and left properties (like margin, padding and float etc.) is not always intended behavior (and I know this because I am struggling with bi-directional web applications for last 7+ years.) For example, a simple multi-lingual web page which has a top navigation bar and on left side a sidebar for sub navigation may still like to keep the page layout the same (i.e., sidebar on left side) except the text flow, list item flow etc. flipped according to the direction of the language chosen.

There is a new pattern emerging for such behaviors which I think should be anticipated in this early stage of RTL support in ExtJS. According to this new pattern, "Right" and "Left" should not change their meaning wrongly as a workaround for proper layout. Instead "Start" and "End" propertied should be used to properly declare the layout. This means "Start" is a synonym of "Left" in LTR languages while it is synonym of "Right" in RTL language context and similarly the "End" property. For backward compatibility, these start and end properties can be translated at a pre-compilation stage accordingly.

This behavior can be observed in;

• CSS reference of Mozilla at https://developer.mozilla.org/en-US/...z-margin-start
• Android 4.2 Layout API at http://developer.android.com/about/v...d-4.2.html#RTL

Since this is only a concern for RTL developers (and RTL support is yet in beta phase), who can learn how to code their application properly to make it bi-directional hence introducing this pattern should not be an issue for mainstream ExtJS developers while providing more flexibility in layout. Also, if one feels that flipping the direction is almost always the case then as a shorthand there can be configurations in the RTL package to express if one wants right and left property flipping behavior or honoring the semantics of right, left, start and end properties.

[dongryphon]

All very good points and thanks for taking the time to provide so much detail.

We discussed adding "start" and "end" options, but those words did not make sense in a 2D space... for example: left, top, right, bottom would become start, top, end, bottom. Also north, south, east, west ... all were problematic nomenclature.

That said, there are ways to achieve this goal, though not declaratively:

    region: rtl ? 'east' : 'west'

    dock: rtl ? 'right' : 'left'

We could probably add something declarative here. Perhaps "west!" and "left!". Thoughts?

[ibnesayeed]

All very good points and thanks for taking the time to provide so much detail.

I am sorry for the late come back due to other priorities, as it is a fair month since I first posted this thread.

We discussed adding "start" and "end" options, but those words did not make sense in a 2D space... for example: left, top, right, bottom would become start, top, end, bottom. Also north, south, east, west ... all were problematic nomenclature.

We could probably add something declarative here. Perhaps "west!" and "left!". Thoughts?

In my opinion, if "start" and "end" are understood as direction aware words when they are used alone then there should be no issues when we use them in 2D space. Saying, "top end bottom start" doesn't sound odd to me in comparison with "top right bottom left" where we will then wrongly translate left as right and right as left. To me, earlier one makes more sense as long as we don't have any better nomenclature that captures the semantics more precisely and elegantly. The same goes to the corners, "top-left" => "top-start", "bottom-right" => "bottom-end" and so on.

When boundary properties (margin, padding and border etc.) are listed individually, "start" and "end" in place of "left" and "right" seems to solve the problem while keeping the original "left" and "right" semantics untouched and making a component direction aware only when "start" and "end" are used. on the other hand when shorthand property declaration is used here are the possible cases using margin example.

margin: 5px;
margin: 5px 10px;
margin: 5px 10px 15px;
margin: 5px 10px 15px 20px;

This cycle always starts with "top". Fortunately, all of the above forms but the last one are direction independent. I am suggesting these possible solutions to solve just the last case issue because others are not causing the issues at all.

One solution to this problem is to never use the last shorthand form when direction sensitive layout is desired, instead break them in equivalent "*-top", "*-end", "*-bottom" and "*-start" properties.

Other solution is to provide a config option in RTL package where developers can express their intent if the compact 4 valued shorthand should be interpreted clockwise or anti-clockwise depending upon the direction property or not.

A third solution is actually inspired from your banged version of values, which I guess is to make it direction responsive. I was thinking on the same lines, what if we can make not just the values but the properties responsive, if we are going to pre-compile them anyway. But I am not sure if a property name like "margin!" and "padding!" will be safe (or sanitized) to use and it wont affect the execution as bang ! is negation sign when used in the beginning of a variable. But if it does, one can choose to use this form to make the property direction responsive (interpret clockwise or anti-clockwise depending on the direction.) I am not sure how frequently this last shorthand form is used in the core of ExtJS and how much effort will it require to make this change throughout the library and test it.

Talking about east, west, north, south and center properties for layout. I was never sure why it was introduced on a surface where there is no relation with the geographic directions. When it comes to map, it makes more sense because that piece of printed paper or digital displays were supposed to to be oriented or considered to match with the geographical orientation. I can smell this philosophy in Java Swing border layout which I guess was the inspiration for ExtJS border layout system as well. Java Swing was an animal of pre-internationalized-web era and served it's purpose or long enough. I strongly believe that a modern app development platform like ExtJS should reconsider and reform these things from the day one of its maturity age. As I already cited a reference in my previous post, how Android is handling this direction awareness in its layout system, if a huge community is going towards that direction then there is no reason why can't we at ExtJS get inspiration from the wide community and be part of it in supporting and making it a de-facto standard to solve an open internationalization challenge.

I would love to see alternate declarations for "north south east west and center" as "top bottom right left and center" (direction fixed) and "top bottom end start and center" (direction aware) respectively which will not only get rid of unnecessary geo-direction (from where it serves no real purpose) but also make it coherent with other boundary properties like border, margin and padding etc. (with addition of center.) Hence, the problem of direction sensitivity will be solved for all using just one convention.

On the other hand if it doesn't seem to be feasible for some reason and we do have to live with old convention then I did like the bang ! version (east! and west!) which guess will be considered as direction aware.

That said, there are ways to achieve this goal, though not declaratively:

    region: rtl ? 'east' : 'west'

    dock: rtl ? 'right' : 'left'

It would be nice to move this logic in RTL core and provide with a (per component or global) config option to use it or not.