bidirectional text support for text element truncation in HTML

my investigation of bidirectional text was largely Silverlight based.  i was removed, but cognoscente and curious, about the HTML discussion in which other colleagues of my team were engaged.  Hereafter exists the summary of Bob's investigation into dealing with bidirectional text behaviors.

Behavior in a mixed environment for Bidi and non-Bidi text

When dealing with Bidi text, there are two settings to consider - text alignment and text direction, which are independent of each other.

Text Alignment

For text alignment, whether the text should be left or right aligned could depend on either the control's property, user or application language settings, language of the first character, or other settings; it can also be a combination of any of these. The inconsistency among Bidi text alignment is an Office wide issue, because there's no absolute correct behavior.  It would be the best if options of choosing the alignment are provided to the user.  When no options are available, each situation can be different, and using the surrounding layout as a reference would be a good starting point.

For example, in the screenshot below, user 1 is using Arabic version of Communicator while user 2 is using the English version.  The message sent by user 1 is right aligned, while the message from user 2 is left aligned.  In this case, since user 1 is in a right-to-left environment and the names were aligned to the right, it would probably have been easier for the user to read all the messages if they were all right aligned regardless of the language of the text. 

Text Direction

Text direction is more important than alignment, since it can affect the meaning of the text.  In the worst case, text can become unreadable.  There are three types of text direction, Left-To-Right, Context, and Right-To-Left.  Below is an example from Outlook options.  Some applications don't have support for Context text direction. 

Again, don't confuse this with text alignment, as it's possible that each of these text direction can coexist with both left or right text alignment.  When only Bidi (i.e. Arabic) text are entered by themselves, the text will stream from right to left regardless of the text direction setting, vice versa for or non-Bidi (i.e. English) text, this means the caret will always appear on the left when Arabic is being entered and on the right when English is entered.  Here are the differences between each setting, which are also the expected behaviors.

Left-To-Right

When HOME key is pressed, caret will always appear at the leftmost position.  In certain applications like Outlook, when a neutral character (space, most punctuation, numerals, etc.) is entered, the caret will go to the right of current input sequence.  If you are entering Arabic text, which goes from right to left, you'll see the caret jumps to the right when you enter a space, and then jumps back to left when you continue to type in Arabic. It's not a bug whether the caret jumps or not.

Right-To-Left

When HOME key is pressed, caret will always appear at the rightmost position.  In certain applications like Outlook, when a neutral character (space, most punctuations, numerals, etc.) is entered, the caret will go to the left of current input sequence.  If you are entering English text, which goes from left to right, you'll see the caret jumps to the left when you enter a space, and then jumps back to right when you continue to type in English.  Again it's not a bug whether the caret jumps or not.

Context 

Context text direction will behave just like Left-To-Right or Right-To-Left depending on the first non-neutral character entered. If the character is Bidi, then the text direction will become Right-To-Left for the control, and If the character is non-Bidi, then the text direction will become Left-To-Right for the control.

Behavior when mixing with neutral characters in Bidi environment

One of the common issues with Bidi environment is the unexpected behavior when mixing with neutral characters. Shown below are examples of forward slashes mixing with URL name containing Bidi text and ellipsis showing on the wrong side of the abbreviated English text.  The first bug is more severe since it's hard for the user to read the URL.

There are a few approaches to fix the issues.

First approach is changing the text direction property in the control if viable.  For the first bug, Left-To-Right would be the best since we want the forward slashes in left to right direction regardless of the text surrounding them.  For the second bug, Context would be the best since the ellipsis would show in the correct position for both English and Arabic text. 

For cases like the second bug, which is a SharePoint page with HTML language and doesn't have the Context option, it's recommended to use the dir="ltr|rtl" HTML attribute to define embedded direction changes.  For example, the below <span dir="ltr"> markup renders the "." string truncation ellipsis to the right -- "Product Ca.", even though it's within a "rtl" body.

<body dir="rtl">

    some text

    <span dir="ltr">Product Ca.</span>
</body>

Another approach, the last resort, the costly and dangerous way, don't do it unless you are absolutely sure that the text will always be non-Bidi text or always be Bidi text, is to use override characters.  We can insert a Left-To-Right override (U+202D) character in the beginning of the English text to force the ellipsis to show on the right, vice versa for Bidi text using the Right-To-Left override (U+202E) character.    The override will affect not just the direction of the words, but individual letters as well.  So "hello world" would become "dlrow olleh" if the Right-To-Left override character is inserted before the text.