[css3-text] text-align and bidi

Adding www-style (for real this time).

The discussion started with the alignment of <select> and <option>,
see thread here:
   http://lists.w3.org/Archives/Public/public-i18n-bidi/2010AprJun/0030.html

On 05/23/2010 08:40 AM, Aharon (Vladimir) Lanin wrote:
> I had originally decided to avoid the subject of alignment in the
> proposal for two reasons:
>
> - It belongs primarily to CSS, not HTML. However, it is now apparent
> that there is no choice but to expand the proposal's scope to CSS.
> - Alignment is a minefield of competing preferences, definitions, and
> assumptions. However, that's actually probably a good reason to deal
> with it...
>
> So, here goes.
>
>  > In CSS3, there is a text-align value called 'start', which represents
>  > the default behavior. It inherits as 'start' and computes against the
>  > current element. So if I don't specify text-align, it will be 'start',
>
> I assume you don't mean that literally, since text-align, when not given
> any explicit value, is supposed to inherit the parent element's value.
> Thus, if we have
>
> <body style="text-align:center">
> <div>
> hello
> </div>
> </body>
>
> the "hello" should be centered.
>
> Actually, there seems to be a problem with the inheritance of "start"
> and "end" when the descendant without an explicit text-align changes
> direction: WebKit and Firefox implement it quite differently. Thus, if
> we have:
>
> <body style="text-align:start>
> <div dir="rtl">
> hello
> </div>
> </body>
>
> Chrome 5.0.375.38 and Safari 4.05  make the "hello" be left-aligned,
> according to the "start" of the element where the text-align:start was set.
>
> Firefox 3.6.3 makes it right-aligned, or according to its element's own
> start edge.
>
> Obviously, the spec should clearly specify the correct approach.
> (Perhaps it already does. I have to admit that I did not take the time
> to look at it. That lets me have my own opinion more easily :-))
>
> My current opinion is that I prefer Webkit's interpretation as the more
> useful: where one wants the alignment to get re-set according to
> direction, one explicitly sets text-align:start. Where one wants the
> alignment to stay as it was, one does not do anything. Firefox's
> approach gives no good way to leave the alignment alone when changing
> the direction.
>
> The <select> is a case in point. With Firefox's approach to text-align,
> once dir and text-align on <option> are fully supported, to get
> different-dir options to line up, one will have to use text-align with
> some absolute value, e.g. text-align:left on the <select>. That is a
> problem, since one has to change the HTML depending on whether the page
> overall is ltr or rtl.
>
> With WebKit's approach, one can use text-align:start on the <select>,
> thus remaining overall page-dir agnostic, and all the options will still
> line up. If one wants each option to line up to its own start - which I
> think is a minority preference - one can set text-align:start on each of
> the options.
>
> On the other hand, WebKit's approach to text-align:start means that the
> default text-align value for the topmost element /can not be /"start",
> since everyone agrees that in
>
> <body>
> <div dir="rtl">
> hello
> </div>
> </body>
>
> the hello is supposed to be right-aligned.
>
> Thus, if WebKit's approach is the one to be chosen for the spec, we
> really need an additional text-align value to indicate the behavior of
> the currently unnamed default. (I hate unnamed values.)
>
> As long as we are on this topic, I should mention that especially if
> Firefox's approach to text-align:start wins, we need a
> text-align:inherit value that finally actually works. It would be
> defined as applying the parent element's "bottom-line" alignment: left,
> right, center, or justify (as opposed to start, end, or the "unnamed
> default" value). Thus, for
>
> <body style="text-align:inherit>
> <div dir="rtl">
> hello
> </div>
> </body>
>
> hello would be left-aligned.
>
> This turns out to be quite useful in many places when one needs to set
> the dir on a block element, but does not want the element's alignment to
> be affected, and does not want to use an explicit "left" or "right",
> since that would depend on the the overall page direction.

Firefox's behavior is correct per spec: the computed value of 'text-align'
is the specified keyword, and the computed value, not the used or actual
value, is what's inherited in CSS.
   http://www.w3.org/TR/css3-text/#text-align
   http://www.w3.org/TR/CSS21/cascade.html#value-stages

Your suggestion for a 'match-parent' keyword that computes to the parent's
effective alignment seems like a good idea, though.

~fantasai

Received on Sunday, 23 May 2010 21:18:15 UTC