You need to
before you can comment on or make changes to this bug.
Chrome Version : 16.0.912.63
OS Version: OS X 10.7.2
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: FAIL
Firefox 4.x: OK
IE 7/8/9: NA
What steps will reproduce the problem?
1.Make the following html file
<li><i class='c1'>a</i><b>1</b> </li>
<li><i class='c2'>b</i><b>2</b> </li>
<li><i class='c3'>c</i><b>3</b> </li>
<li><i class='c4'>d</i><b>4</b> </li>
2. And just load it on the browser
What is the expected result?
d4 c3 b2 a1
should be shown.
What happens instead?
a1 b2 c3 d4
The order is wrong.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
HTML 4.1 had specified that block elements (like <li>) are supposed to have unicode-bidi:embed by default (as opposed to "normal" for inline elements), in case they get set to display:inline by CSS as you have done in your test case. FF implemented that a couple of years ago at least, but WebKit has not. This is the basic cause of the bug.
However, note that in HTML5, the what-used-to-be-called-block elements are supposed to have unicode-bidi:isolate. This too will result in the behavior you expect. FF has implemented this change (see https://bugzilla.mozilla.org/show_bug.cgi?id=676245), but WebKit has not yet, see https://bugs.webkit.org/show_bug.cgi?id=65617. IMO, this is a duplicate of that bug.
*** This bug has been marked as a duplicate of bug 65617 ***