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

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[Asaf Romano (gone)]

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 1

[Asaf Romano (gone)]

Neil: ping?

Comment 2

[Neil Deakin]

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

[Alan Thomas]

This happens on Windows too. I suspect this bug's platform should be All.

Comment 4

[Tomer Cohen :tomer]

(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.

Comment 5

[Asaf Romano (gone)]

What's the behavior when there's no global.dtd file? That is, is it ignored in other browsers?

Comment 6

[Tomer Cohen :tomer]

(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

[Sebastian Zartner [:sebo]]

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.

Comment 8

[Asaf Romano (gone)]

Tomer, also note that -moz-locale-dir was introduced in order to remove locale.dir completely at some point.

Taking...

Comment 9

[Sebastian Zartner [:sebo]]

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

[arni2033]

Attachment: 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

Comment 12

[Tim Nguyen :ntim]

In an html page it should be :dir(rtl).

Comment 13

[Boris Zbarsky [:bzbarsky]]

> 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.