Re: [CSS21] bidi, text-align, and list markers

 

Hi.

From: Aharon (Vladimir) Lanin <aharon@google.com> 
Date: Thu, 3 Jun 2010 09:59:12 +0300


> Re the proposed change to text-align generally (i.e., that by default it get
> set to 'left' or 'right' at the root element and be inherited as such by
> normal inheritance rules), I strongly agree with fantasai that this would
> break many existing bidi pages, which rely on a change in dir changing the
> alignment by default. I am very much against such a change.
Agreed.
> I am very much for adding (to CSS3) a text-align value or values that
> compute(s) to either 'left' or 'right' at the point where it is specified
> (and would thus be inherited as 'left' or 'right', i.e. ignoring direction
> changes in descendants). Among the 'frozen-start' (pardon the name - we have
> to call it something during this discussion) value's uses would be to get
> the proposed behavior - but by explicitly putting that value on the root
> element. Another use would be to get the <option>s in a <select> to all line
> up despite direction changes (hopefully they'll start supporting direction
> very soon) by putting the new text-align value on the <select>. (Would it be
> possible to even make that value the default text-align on a select?)
Yes, this would work.
> Re list marker location, it is certainly true that one can use a child
> element to set the direction on an <li>'s content. 
This works generally (it did for my ie8 browser); but see 
http://bytes.com/topic/html-css/answers/98405-how-do-i-set-bullets-right-side-ordered-list
> However, I think that
> this is basically a workaround that authors may or may not invent when they
> are faced with the problem of <li>'s current bidi behavior. 
> I think that it
> would be best if there were a style that would allow controlling the
> location of the list marker, and that by default it should be set to use the
> start edge of the list's (not the list item's) direction.
Yes. Thanks. This is it.
> The 'frozen-start' text-align value on the list in addition to the suggested
> list marker location style would also achieve consistent alignment of the
> list items' content. Please note that this is not the same as controlling
> the list marker location:

> * hello
>                                          OLLEH *
I cannot imagine that this should be the default based on directionality ever.
> is not the same as

> * hello
> *                                         OLLEH

> is not the same as

> * hello
> * OLLEH
This is what we need for the most part.
> is not the same as

> * hello
> OLLEH *
> Aharon

From: Aharon (Vladimir) Lanin <aharon@google.com> 
Date: Fri, 4 Jun 2010 14:00:14 +0300

> This is what one gets today for the same example as above in IE. In Firefox
> and Opera the "O" is left-aligned with the "h". In WebKet, the bullet
> disappears.
> I would say that what Firefox and Opera do should be the expected display
> when the bullet gets its location from the <li>'s direction.
Hmm I think either IE or Firefox/Opera's solution is o.k.; Webkit's solution is not.

Choosing between IE's solution or Firefox/Opera's -- imo -- needs to be handled at the browser-design level.

 

(Thanks for your thorough, clear summary of this.

{ Also -- just a Note: 'olleh' sounds almost like 'hola' pronounced 'ola' which means 'hello' so hello/olleh is a neat example. })


From: fantasai <fantasai.lists@inkedblade.net> 
Date: Thu, 03 Jun 2010 11:48:44 -0700
To: W3C style mailing list <www-style@w3.org> 
CC: "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org> 

>> Right, but Aharon is proposing CSS to achieve these effects (and possibly
>> avoid the shrinkwrap, no?) 
Still I say shrinkwrap should be an option.
> and I'm curious to see how he would propose
>> the frozen 'text-align' to operate.

> The best way for the new value of text-align to operate, imo, would
> be as a 'match-parent' keyword. So for example,

>   option, li, dl, dt { text-align: match-parent }

> would give the consistent-bullet-position behavior. 'match-parent'
> would be different from 'inherit' because 'inherit' triggers normal
> inheritance -- inheriting the specified keyword value. 'match-parent'
> would compute the 'start' and 'end' keywords against the parent's
> direction, and result in either 'left' or 'right' as the computed
> value of 'text-align' (which would then inherit to any children).

> ~fantasai
Thanks fantasai -- match-parent would be the default here, I think.


Again, best,

--C. E. Whitehead
cewcathar@hotmail.com