- 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