Re: per-paragraph auto-direction, a.k.a. dir=uba

I second Mati's proposal. As Ehsan has pointed out <textarea readonly> can
be used to display plain text (as opposed to edit it), even though somewhat
awkwardly. And if we work out a bigger proposal, we can tweak the bugs filed
on HTML5 and CSS3. Right now it is imperative to produce a new draft of the
proposal and file the bugs (October 1 deadline for HTML5..., apparently).

I do want to put dir=uba under the dir=auto umbrella, via
autodirmethod=first-strong|any-rtl|uba. autodirmethod inherits; dir does
not. The default would probably be first-strong.

Is this agreeable to everyone? Please respond.

Here is a quick spec for dir=auto:

   - Using dir=auto with autodirmethod=first-strong|any-rtl would:
      - Make the default value for the ubi attribute ubi (i.e. on), as
      described elsewhere.
      - Set the CSS direction to ltr or rtl according to the indicated
      algorithm.
      - Invoke the indicated algorithm on the in-order traversal of the
      descendent text nodes, with the following exceptions:
         - Text nodes under a descendant element with an explicit dir
         attribute (including dir=auto).
         - The part of the text after the first X characters (where the text
         in nodes excluded above are not part of the count). *Do we need
         this? If so, what's a good X value? 100?*
         - Parts of the text between an LRE, RLE, LRO, RLO, and its matching
         PDF.
      - The first-strong algorithm returns the direction of the first strong
      (L, AL, or R) character it encounters. If it does not encounter any, it
      returns ltr if it encounters any weak ltr characters (EN or AN).
If it does
      not encounter any of those either, it returns the inherited direction.
      - The any-rtl algorithm returns rtl if it encounters any strong RTL
      character, or ltr otherwise.
   - Using dir=auto with autodirmethod=uba would (by default) set
   unicode-bidi to "uba" and direction according to first-strong. (Note that
   this includes leaving direction at the inherited value if the content is
   neutral.)
   - For elements other than <textarea>, unicode-bidi:uba is treated as
   unicode-bidi:isolate.
   - On <textarea>, unicode-bidi:uba means that:
      - The UBA on the textarea content is invoked specifying only a default
      paragraph level (in icu4j terminology, either LEVEL_DEFAULT_LTR or
      LEVEL_DEFAULT_RTL), based on the the element's own direction value as
      calculated above. (This makes the all-neutral paragraphs use the same
      direction as the first paragraph that is not all-neutral.)
      - Each UBA paragraph’s lines’ alignment is determined by the
      paragraph’s resolved base level when the element's text-align is start or
      end.


Aharon


On Tue, Sep 14, 2010 at 2:21 PM, Matitiahu Allouche <matial@il.ibm.com>wrote:

> I don't feel competent enough to find the magic solution for all the
> questions that dir=uba seems to raise.  This discussion has been going on
> for a while, and there is real danger that the whole item be shelved if a
> consensus is not found soon.
>
> However, based on the discussion on the list, I think that the following
> points are more or less agreeable to all:
> 1) dir=uba is mostly needed for <pre> and <textarea> elements.
> 2) All or most of the problems are related to using dir=uba with <pre>.
> 3) There are alternatives to using dir=uba with <pre> for multiple
> paragraphs, like separating the text in distinct paragraphs.
> 4) There is no problem related to using dir=uba with <textarea>.
> 5) There is no other way than dir=uba to achieve paragraph-based direction
> for <textarea>.
>
> Given the above, I am suggesting to at least allow dir=uba for <textarea>,
> even if its use for other types of elements is postponed or abandoned
> altogether.
>
>
> Shalom (Regards),  Mati
>           Bidi Architect
>           Globalization Center Of Competency - Bidirectional Scripts
>           IBM Israel
>           Phone: +972 2 5888802    Fax: +972 2 5870333    Mobile: +972 52
> 2554160
>

Received on Tuesday, 14 September 2010 15:40:26 UTC