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)
Core
CSS Parsing and Computation
Tracking
()
NEW
People
(Reporter: asaf, Unassigned)
References
Details
(Keywords: rtl)
Attachments
(1 file)
(deleted),
image/png
|
Details |
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.
Reporter | ||
Comment 1•14 years ago
|
||
Neil: ping?
Comment 2•14 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•14 years ago
|
||
This happens on Windows too. I suspect this bug's platform should be All.
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 4•13 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
Reporter | ||
Comment 5•13 years ago
|
||
What's the behavior when there's no global.dtd file? That is, is it ignored in other browsers?
Comment 6•13 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•13 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.
Reporter | ||
Comment 8•13 years ago
|
||
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•13 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
Comment 11•9 years ago
|
||
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)
Updated•7 years ago
|
Assignee: asaf → nobody
Status: ASSIGNED → NEW
Comment 13•7 years ago
|
||
> 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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•