I am sorry for the late come back due to other priorities, as it is a fair month since I first posted this thread.
Originally Posted by dongryphon
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.
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?
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.
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.
margin: 5px 10px;
margin: 5px 10px 15px;
margin: 5px 10px 15px 20px;
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.
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.
That said, there are ways to achieve this goal, though not declaratively:
region: rtl ? 'east' : 'west'
dock: rtl ? 'right' : 'left'