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

NEW
Unassigned

Status

()

9 years ago
a year ago

People

(Reporter: mano, Unassigned)

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.

Comment 2

9 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

8 years ago
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.
Keywords: rtl
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.

Comment 7

7 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

7 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

3 years ago
Duplicate of this bug: 1201640

Comment 11

3 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)
In an html page it should be :dir(rtl).
Flags: needinfo?(asaf)

Updated

a year ago
Assignee: asaf → nobody
Status: ASSIGNED → NEW
> In an html page it should be :dir(rtl).

That has nothing to do with the locale direction.  It matches purely on the values of the "dir" attribute.
You need to log in before you can comment on or make changes to this bug.