Re: RTL Behavior

Hello Shawn,

Many thanks for your examples. Unfortunately, they didn't make it 
thought the mailing list. But they are in the archive; everybody please 
check http://lists.w3.org/Archives/Public/public-iri/2012Apr/0011.html 
if you didn't get the actual images.

On 2012/04/04 8:44, Shawn Steele wrote:
> I don't have a lot of time to spend on this, but quickly, here are some of the problems:
>
> Currently an RTL user sees something like this:
> [cid:image001.png@01CD11B8.3665AC60]
>
> But when the URL gets bigger, a BIDI user had the most important information displaced.  So the part where they look (right side) isn't where the important stuff is.
> [cid:image002.png@01CD11B8.3665AC60]
>
> Worse, clipping starts clipping it in the wrong direction:
> [cid:image003.png@01CD11B8.3665AC60]

Why isn't everything outside the domain name grayed out in this example? 
And the address bar could/should try to place the IRI so that the 
not-grayed out part is visible initially. Otherwise, there are some 
attack vectors for LTR cases, too, such as:

http://www.microsoft.com.very-long-and-convoluted-series-of--many-labels.the-bad-guys.com

> Clearly those are Latin examples, however the existing behavior with an Arabic domain and ASCII path would cause the same types of problems with respect to the most important (eg: domain) part of the IRI.  I would probably even argue that in this case, where the browser UI language/system locale is Arabic, and the GUI is Bidi/Mirrored, that rendering ANY IRI with the parts ordered from right to left would be much more user friendly.  That's a User Preference, or at least System Preference.

I agree that it might be much more user friendly.

However: The main problem with this isn't to allow it in the spec. 
Changing the spec is easy (at least for Adil and Larry and me).

The *real problem* is how to get anything close to by-component 
reordering according to the UI or embedding direction *implemented* in 
*general text*.

Regards,    Martin.

Received on Wednesday, 4 April 2012 01:45:18 UTC