1185987 - element with -moz-isolate and numbers in content comes on the wrong side of other numbers in an RTL page

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Amir Aharoni]

To see an example check the following page:
https://fa.wikipedia.org/wiki/User:Amire80/ref

The page's general direction is RTL.

It shows numbers and Latin letters after which there are <sup> elements with footnotes.

Ideally, these footnotes are supposed to appear after the numbers, so in an RTL environment this means - main numbers on the right, sup elements on the left. Also, the square brackets in the text of the <sup> element are supposed to be around the number and not to jump to the other side of the preceding content.

Using unicode-bidi: embed on the <sup> element resolves the problem of the jumping square brackets, but they don't resolve the problem of the order of appearance - the <sup> appears on the right and this is not the desired behavior.

Using unicode-bidi: isolate appears to be right choice. This is what happens in the second section in the page content. Applying "unicode-bidi: -webkit-isolate" does the right thing in Chrome 43.0, but applying "unicode-bidi: -moz-isolate" doesn't seem to have the desired effect in Firefox.

I am testing with Firefox 39.0 stable on Fedora.

Comment 1

[Simon Montagu :smontagu]

This is similar to bug 717811 and/or bug 996627 and has the same dependencies. You may be able to work around for the time being by using "display: inline-block"

Comment 2

[Timo Tijhof]

Wikipedia tried "display: inline-block" but is reverting back to 'unicode-bidi: isolate' due to counter-intuitive selection behaviour in Firefox with inline-block elements in a paragraph (downstream: https://phabricator.wikimedia.org/T108493). Chrome is unaffected (e.g. triple-click selects the entire paragraph, including any inline elements with inline-block).

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

It seems our result now matches Chrome's behavior, and also the behavior descibed in comment 0. I suppose this is fixed by bug 1160847.