W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: Alignment of paragraphs with unicode-bidi: plaintext [css3-text] [css3-writing-modes]

From: Aharon (Vladimir) Lanin <aharon@google.com>
Date: Sun, 1 Apr 2012 17:38:10 +0300
Message-ID: <CA+FsOYYg01aTiLNKyiqCW5FArbFKOwvxygYm8u=wSAWVgMg6tQ@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: public-i18n-bidi@w3.org, "www-style@w3.org" <www-style@w3.org>
Thanks for the response and for the kind words!

I am very happy and relieved that we agree on the ideas. I also like most
of your changes to the wording. However, I think the wording still needs a
little tweaking.

For unicode-bidi:plaintext, the spec currently has:

 An element immediately contains a bidi paragraph if it is a block

 container or bidi-isolating inline and no other such elements intervene
>  between it and the bidi paragraph.


I have three issues here:
- It does not say that the element has to contain the paragraph.
- I think that the "intervene" is a little too loose for a definition.
- I don't think that that the "inline" in "bidi-isolating inline" is
necessary.

 Thus, I would tweak it a little further:

An element immediately contains a bidi paragraph if both of the
following conditions hold for the element but not for any of its
descendants:
- The element contains the entire paragraph.
- The element is either bidi-isolating or a containing block.

For alignment,  the spec currently has:

The start and end edges of a line box are determined by the inline base
> direction of the "bidi paragraph" to which it belongs. In most cases, this
> means using the containing block's computed ‘direction’. However if
> containing block has ‘unicode-bidi: plaintext’ [CSS3-WRITING-MODES], the
> inline base direction of its line boxes will be determined by the bidi
> paragraphs it immediately contains. In the case of an empty bidi paragraph,
> the direction used is that of the previous bidi paragraph in the containing
> block, or, if this is the first bidi paragraph in the containing block,
> then the ‘direction’ property is used.


(Thanks for making the additional change re empty bidi paragraphs.)

My issues here:
- I am not sure why you use the term "inline base direction" (of a bidi
paragraph) instead of just "base direction". How is the base direction
"inline"? (This is not new. You were already using "inline base direction"
before my suggested changes.)
- There is no definition of how a line box "belongs" to a bidi paragraph.
(This was already a problem in my proposal. The "belonging" was explained
outside of the change I suggested.) I think that the "to which it belongs"
has to be expanded to an actual definition, which is composed of two parts:
  - The line box contains text belonging to the bidi paragraph
  - The bidi paragraph is immediately contained by the line box's
containing block.
- In the current wording, the first sentence ("the start and end edges of a
line box are determined by the inline base direction of the "bidi
paragraph" to which it belongs") is incorrect when that paragraph is empty.
To deal with this, the empty paragraph handling has to be further
integrated into the rest of the definition.
- "Empty paragraph" is not defined. The naive definition - a paragraph
containing nothing - is incorrect, since it also has to cover a paragraph
containing nothing but the terminating (B-class) character.

So, here is my attempt at revised wording.

Most of the time, the start and end edges of a line box are determined by
the containing block's computed ‘direction’. However, if the containing
block has ‘unicode-bidi: plaintext’, they are determined by the base
direction of the bidi paragraphs the containing block immediately
contains [CSS3-WRITING-MODES], in the following manner. Each line box
displays some part of exactly one bidi paragraph immediately contained by
the line box's containing block. If this or some preceding bidi
paragraph immediately contained by the containing block is non-empty (i.e.
contains characters other than the terminating bidi-paragraph-breaking
character, if any), that non-empty bidi paragraph's base direction
determines the line box's start and end edges. Otherwise, they are
determined by the the containing block's computed ‘direction’.

Fixed the incorrect example. I should probably add some more of yours, too.
> :)


I agree that more examples are necessary. Here is what I would suggest
adding (this includes the explanations,which I think would be quite useful
to the reader):

Example 9:

<pre dir="rtl" style="unicode-bidi:plaintext">
"<span style="unicode-bidi:plaintext">שלום!</span>", he said.
</pre>

The result should be a left-aligned line looking like this:
"!שלום", he said.

The line is left-aligned (despite the containing block having
direction:rtl) because the containing block (the <pre>) has
unicode-bidi:plaintext, and the line box displays an immediately-contained
bidi paragraph that is ltr. This is because that paragraph's first
character with a strong direction is the ltr "h" from "he". The rtl "שלום!"
does precede the "he", but it sits in its own bidi-isolated paragraph that
is *not* immediately contained by the <pre>, and is thus irrelevent to the
line box's alignment (even though it is rtl, thus displaying as "!שלום",
not "שלום!"). From from the standpoint of the immediately contained outer
paragraph, the bidi-isolated paragraph inside it is, by definition, just a
neutral U+FFFC character, so the immediately-contained paragraph becomes
ltr by virtue of the "he" following it.

Example 10:

<textarea dir="rtl" style="unicode-bidi:plaintext">

Hello!

</textarea>

As expected, the "Hello!" should be displayed ltr (i.e. with the
exclamation mark on the right end, despite the <textarea>'s direction:rtl)
and left-aligned. This makes the empty line following it left-aligned as
well, which means that the caret on that line should appear at its left
edge. The first empty line, on the other hand, should be right-aligned, due
to the direction of its containing paragraph, the <textarea>.

Aharon
Received on Sunday, 1 April 2012 14:39:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT