W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > January to March 2010

[Fwd: Re: Bidi proposal draft]

From: Najib Tounsi <ntounsi@gmail.com>
Date: Fri, 05 Mar 2010 16:56:29 +0000
Message-ID: <4B9137BD.8040508@emi.ac.ma>
To: public-i18n-bidi@w3.org
Resent to

attached mail follows:

HI Richard, all,

My present remarks are about the first part (section 2.1)  of the article.

I've always thought that HTML is not enough clear about Bidi.
HTML is equipped for Bidi, indeed a minimum,  but it lacks of 
clarification about the related markup. For example, Wrt bidi, HTML 
specifies the dir attribute with reference to the UBA,  and IMO, doesn't 
clarify well what the dir attribute does or, especially, what it doen't 
do. (e.g. dir="rtl" was not made to justify text right, or other visual 

The consequence may be that even recent browsers are not always 
consistent or compatible with one another. Which is worse.

For example, LRE(U+202A)/PDF(U+202C) isn't always equivalent, at least 
for Safari, to dir="ltr"!:
   <p>ABC <span dir="ltr"> &gt; </span> DEF</p>
is not the same as
   <p>ABC &#x202A; &gt; &#x202C DEF</p>
Safari and Opera have different opinion for the last line.
Safari and firefox have different opinion for the first line.
(see http://www.w3c.org.ma/Tests/Bidi-Fev-2010/safari%3eopera.html)

Wrt to the introduction examples (section 2.1), I find HTML is equipped, 
at least according to the examples cited, to sufficiently markup a 
document, but is the "the right way" I would say.

Considering what is called "self-contained entity", I see it like 
someting which gives semantic to the notion of "directinal-run".

The problem with Bidi is that you can have two different directional 
runs, A and B say, which are logically adjacent, but visually A splits B 
in two parts, as in example-2; or you want B to split in two, but it 
doesn't (as in example-3-4. (See a digression about this at 
Clearly, I want to specify my own "directional run" to be a given piece 
of text.

In what follows are my suggestion for this §1 Introduction and §2.1:

§1.3 Teminology
May be add LRM/RLM to the terminology, since they are used in  the 
following section just after.

LRM: A short name for the Unicode character U+200E. This invisible 
control character is used to force directionality of directionally 
neutral character to strong LTR.
RLM: A short name for the Unicode character U+200F. This invisible 
control character is used to force directionality of directionally 
neutral character to strong RTL.

"The Problem
Most documents contain a large number of self-contained entities whose 
content must not influence the directional rendering of what precedes or 
follows them."

I would see "must not BE influenceD BY the directional rendering of what 
precedes or follows them.", since we expect "such an entity to be 
displayed visually between what precedes it and what follows it", and so 
not to be influenced by them. No?

Moreover, I think the notion of "self-contained entity" SCE is an 
important one. I see it as what gives semantic to the notion of 
"directional run". I would also like to add this some where in the text.
Indeed, a single directional run might appear visually as split in two 
parts, whereas one might wish it to be a single SCE, (or one might wish 
to visually separate a single directional run in two pieces, or two 
SCEs), and "self-contained entity" is the right notion in this case.

§2.1  the examples
You say that adding dir="rtl" doesn't solve the problem. Yes, if you put 
it around RTL part. But it works, if you (oddly) surround LTR text with 
dir="ltr". Example-2 works if you put <span dir="ltr"> - 3 
review</span>, knowing that it is already LTR context.

I see example-2 and example3-4 as two sides of the same problem:
- "PIZZA -3"  should be cut in two parts (or "-3 reviews" shouldn't be 
cut in two parts), that is "-3 review" is the same directional run.
- "css (position:relative)", same directional run, should split in two 
parts, but it doesn't. It is displayed at once. (using dir="rtl", for 
"css" word, also solve the problem, but is this the right way).
In this case, parenthesis or punctuation merely add confusion to the 
same situation.

May be you can have examples with real RTLs and then summarize problems 
in a figurative way? I can help doing it.

§2.1 later on.
- "Currently, there is no reliable way to deal with Example 1 to Example 
4 using mark-up, except by redundantly marking an entity's surroundings 
with the base direction, which is counterintuitive and painful to 
Cite the example2 solved with <span dir="ltr"> - 3 review</span>

- "The LRM or RLM is being ... In fact, the entity is typically already 
surrounded by an element that either gives it style or indicates its 
direction; why can't the element itself be used to indicate an entity?"
s/surrounded by/marked up with/
otherwise I understand the element preceding or following the entity.

Best regards,


Richard Ishida wrote:
> Hi Aharon,
> I have migrated the bidi proposal wiki text to the format needed to publish as a Working Draft.  There may be a couple of additional things to do or mistakes, but hopefully most of the work is now done.
> See http://www.w3.org/International/docs/html-bidi-requirements/
> I rearranged some of the introductory stuff slightly, to fit the format, and I left some additional terminology floating around so that we could decide whether we want to keep it - although 'base direction' isn't in the list, and probably should be.
> We now need to get you set up to edit that document, rather than the wiki.  Addison, what would you recommend as the best way for WG members to edit docs?
> RI
> ============
> Richard Ishida
> Internationalization Lead
> W3C (World Wide Web Consortium)
> http://www.w3.org/International/
> http://rishida.net/
Najib TOUNSI (tounsi at w3.org)
W3C Office in Morocco (http://www.w3c.org.ma/)
Ecole Mohammadia d'Ingénieurs, BP. 765 Agdal-RABAT Morocco
Phone : +212 (0) 537 68 71 50  Fax : +212 (0) 537 77 88 53
Mobile: +212 (0) 661 22 00 30 
Received on Friday, 5 March 2010 16:52:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 5 March 2010 16:52:04 GMT