Currently, -moz-locale-dir is supported only within xul documents. In html documents this selector always matches ltr. I assume this was done for a reason: the code within nsXULDocument::IsDocumentRightToLeft has nothing to do with xul.
With remote xul going away now, this makes -moz-locale-dir usable only within chrome:// UI. However, there are already few UI documents that are rendered within the content area. For now, they fallback to using global.dtd's locale.dir and complex selectors (body[dir="rtl"] > ...)
At least for about: pages, I strongly suggest to enable this selector for non-xul documents.
What would -moz-locale-dir return? The direction the chrome is in I presume?
Are you expecting this to be the same in remote web pages?
If so, probably, what need to happen is that the default implementation of nsDocument::IsDocumentRightToLeft() just needs to return nsIXULChromeRegistry::IsLocaleRTL("global", &isRTL);
This happens on Windows too. I suspect this bug's platform should be All.
(In reply to Mano from comment #0)
> With remote xul going away now, this makes -moz-locale-dir usable only
> within chrome:// UI. However, there are already few UI documents that are
> rendered within the content area. For now, they fallback to using
> global.dtd's locale.dir and complex selectors (body[dir="rtl"] > ...)
What's wrong with using global.dtd's locale.dir? It is working well right now.
What's the behavior when there's no global.dtd file? That is, is it ignored in other browsers?
(In reply to Mano from comment #5)
> What's the behavior when there's no global.dtd file? That is, is it ignored
> in other browsers?
global.dtd is available on Mozilla applications, and thous I don't see why we should use another method to retrieve the UI direction. Please correct me if I'm wrong as I don't see any downsides in our current implementation.
Please see http://code.google.com/p/fbug/issues/detail?id=4948 for a case, in which -moz-locale-dir could be needed.
Please let me know, if this could be solved differently.
Tomer, also note that -moz-locale-dir was introduced in order to remove locale.dir completely at some point.
Is that already fixed? At least the reporter of the issue mentioned in comment 7 said, that it's already working for him now.
*** Bug 1201640 has been marked as a duplicate of this bug. ***
Created attachment 8666662 [details]
screenshot 2015.09.28 15-26-23.png
That selector still doesn't work in Aurora43 for RTL localization. I tested Hebrew localization
I believe this should be closed/reassigned (or left w/o assignee) if you're not going to work on this