- From: Matitiahu Allouche <matial@il.ibm.com>
- Date: Tue, 12 Feb 2002 12:33:27 +0200
- To: Martin Duerst <duerst@w3.org>
- Cc: "Irfan Gowani" <irfango@microsoft.com>, w3c-i18n-ig@w3.org, w3c-translators@w3.org
About the HTML issue, here is my view: a) We have a <UL> tag without explicit direction, so it inherits its direction from the context (the <HTML> tag), which is LTR. b) The first <LI> tag has an explicit RTL direction. c) The second <LI> tag has no direction, so it inherits its direction from the the context (the <UL> tag), which is LTR. According to this, it seems to me that what should happen is that the first LI should be right aligned with a bullet on the right, and the second LI should be left aligned with a bullet on the left. This looks bizarre, but it is the author's intent. My tests show that MS IE (5.5) and Mozilla (0.9.1) do what I think is right, while Netscape 6.2 seems to ignore the dir in the first <LI> tag, which I think is wrong. About the Bidi rendering of the phrase: This is the first list item, with a setting of dir="rtl". when dir="rtl", the trailing double-quote and period are neutral characters adjacent to the end of text, so they must adopt the paragraph orientation, which is RTL. Consequently, they will be reordered from right to left and displayed on the left side of the text. MS IE and Mozilla show this correctly. Shalom (Regards), Mati Bidi Architect Globalization Center Of Competency - Bidirectional Scripts IBM Israel Phone: +972 2 5870999 ext. 1202 Fax: +972 2 5870333 Mobile: +972 52 554160 Sent by: w3c-i18n-ig-request@w3.org To: "Irfan Gowani" <irfango@microsoft.com> cc: w3c-i18n-ig@w3.org, w3c-translators@w3.org Subject: RE: Direction in <li> Hello Irfan, It looks like you have digged up an interesting problem. I'm copying the HTML WG (because it's them who have to issue an erratum if we need one), the I18N IG, and the bidi list of the Unicode consortium (because there also seem to be differences with respect to the bidi algorithm). At 11:20 02/02/11 -0800, Irfan Gowani wrote: >Currently, IE displays the first li on the right and the keeps the >second one to the left. Do you think that is the correct behavior? Ah, I see. I have created a test page, at http://www.w3.org/2002/02/html-bidi-test/list-directions.html. (if you can't access this, try the following one temporarily: http://web5.w3.org/2002/02/html-bidi-test/list-directions.html) This page is indeed rendered differently by different browsers: - IE 6 puts the first list item to the right. It also doesn't show a bullet (which looks quite strange), and it changes the text slightly, to ."This is the first list item, with a setting of dir="rtl Bidi specialists, can you confirm what is the correct rendering of This is the first list item, with a setting of dir="rtl". in a rtl context (embedding), a straightforward rendering or the IE rendering? - Amaya (latest version) and Tango render the first list item on the right, with a bullet on the very right (parallel to the second group of list items). - Netscape 6 renders the list item to the left. - Opera 6 does not do bidi at all (all list items on the left side). - Frontpage (2002) does the same as IE, except that it displays a bullet. I guess that if we need an erratum, we can go either the Amaya/Tango/ Frontpage way (and partly IE) to respect current practice. Not displaying a bullet looks definitely like a bad idea. The alternative would be to say that lists and their bullets have to be aligned, and go the Netscape way. While I don't think that having bullets on both sides of the page makes much sense, it may be useful sometimes. It's always possible to bring the bullet back to the right side by changing <li dir='rtl'>This is the first list item, with a setting of dir="rtl".</li> to <li><span dir='rtl'>This is the first list item, with a setting of dir="rtl".</span></li> As for the different position of the dot and the quotes, that's really just a question of a careful interpretation of the bidi algorithm, no need for discussions. Regards, Martin.
Received on Tuesday, 12 February 2002 05:33:09 UTC