The default bug view has changed. See this FAQ.

-moz-locale-dir selector should work in html documents

ASSIGNED
Assigned to
(NeedInfo from)

Status

()

Core
CSS Parsing and Computation
ASSIGNED
7 years ago
2 years ago

People

(Reporter: mano, Assigned: mano, NeedInfo)

Tracking

({rtl})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Neil: ping?

Comment 2

7 years ago
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);

Comment 3

7 years ago
This happens on Windows too. I suspect this bug's platform should be All.
OS: Mac OS X → All
Hardware: x86 → All

Comment 4

6 years ago
(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.
Keywords: rtl
What's the behavior when there's no global.dtd file? That is, is it ignored in other browsers?

Comment 6

6 years ago
(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.

Comment 7

6 years ago
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.

Taking...
Assignee: nobody → mano
Status: NEW → ASSIGNED

Comment 9

5 years ago
Is that already fixed? At least the reporter of the issue mentioned in comment 7 said, that it's already working for him now.

Sebastian

Updated

2 years ago
Duplicate of this bug: 1201640

Comment 11

2 years ago
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
Flags: needinfo?(asaf)
You need to log in before you can comment on or make changes to this bug.