Open Bug 588996 Opened 14 years ago Updated 2 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

People

(Reporter: asaf, Unassigned)

References

Details

(Keywords: rtl)

Attachments

(1 file)

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?
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.
OS: Mac OS X → All
Hardware: x86 → 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.
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
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
Attached image screenshot 2015.09.28 15-26-23.png (deleted) —
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)
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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: