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

Re: <option>'s alignment and dir Re: Additional Requirements for Bidi in HTML - open issues

From: Aharon (Vladimir) Lanin <aharon@google.com>
Date: Sun, 23 May 2010 18:40:44 +0300
Message-ID: <AANLkTin7E3y_h44gxFp_FcXj8OgjiFVvhEikPzllOe0G@mail.gmail.com>
To: ntounsi@emi.ac.ma
Cc: fantasai <fantasai.lists@inkedblade.net>, Xiaomei Ji <xji@google.com>, "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>
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.

> The proposal also says that "an <option> element's
> computed direction will take its dir attribute into account,
> and will be used to display the option's text in both the
> dropdown and after being chosen". Does it mean if dir is
> set for <option>, it is honored, otherwise, the direction of
> <option> is computed (as what Safari does) without
> inherits from dir of <select>?

In the original form of the proposal, it was left as an open issue whether
the default dir value on <option> would be "auto". Backward compatibility
does not seem to be a major problem here, and if one knows the correct
direction, one can always specify it explicitly. The major reason this got
dropped from the proposal is that it seemed a little silly to mandate
dir=auto by default for just one comparatively rare element. Safari's
example is not necessarily compelling because dir does not work on <option>
there. However, we could re-open that issue if you like.

Aharon


On Fri, May 21, 2010 at 2:36 PM, Najib Tounsi <ntounsi@gmail.com> wrote:

> fantasai wrote:
>
>> On 05/20/2010 11:41 AM, Xiaomei Ji wrote:
>>
>>> I have some questions on <option>'s alignment.
>>>
>>> In 3.7 <option> should support the dir attribute and be displayed
>>> accordingly both in the dropdown and after being chosen. The proposed
>>> solution on alignment is: "setting an <option> element's alignment via
>>> CSS or the align attribute will affect its display accordingly in both
>>> the dropdown and after being chosen".
>>>
>>> Since "text-align" is inherited, if an <option>'s alignment is set, it
>>> is honored. If an <option>'s alignment is not set, it should take its
>>> <select>'s alignment if it is set.
>>>
>>> But how about the case when alignment is not set in both <option> and
>>> <select>? Should the alignment be derived from <option>'s dir or from
>>> <select>'s dir?
>>>
>>> For example:
>>> <select dir="rtl">
>>> <option style="text-align:right">foo</option>
>>> <option dir="ltr">bar</option>
>>> </select>
>>>
>>> "foo" is aligned right.
>>> "bar" is displayed as left-to-right both in dropdown and after being
>>> chosen. How about its alignment?
>>>
>>>
>>> The proposal also says that "an <option> element's computed direction
>>> will take its dir attribute into account, and will be used to display
>>> the option's text in both the dropdown and after being chosen". Does it
>>> mean if dir is set for <option>, it is honored, otherwise, the direction
>>> of <option> is computed (as what Safari does) without inherits from dir
>>> of <select>?
>>>
>>
>> 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',
>> and 'start' will inherit from the <select> to all the <option>s. When
>> layout happens, 'start' will behave as 'left' or 'right' depending
>> on the direction.
>>
>> So, according to the specs, for this case
>>  <select dir="rtl">
>>    <option dir="ltr">Option A
>>    <option>Option B
>>  </select>
>> Option A will be left-aligned, and option B right-aligned.
>>
>> ~fantasai
>>
>>
>>
> Currently, browsers don't agree at all about this example. May be Firefox
> is the most conform.
>
> Attached are tests I did.
> (or see http://196.200.140.8/Tests/testOptionAlign.html)
>
> Najib
>
>
>
>  Test<option>'s alignment
>
>  Option A Option B  A longer string
>
>
>  align when select
>
>  align when dropdown
>  marked when dropdown  browsers Opt A
>  Opt B
>  Opt A Opt B
>  Option selected
>   FireFox 3.6
>   right
>  right
>  left
>  right
>
>   Chrome 6.0
>  right
>  right
>  left left
>
>   Opera 9.52
>  right
>  right
>  right
>  right
>
>   Safari 4.0
>  left
>  left
>  left
>  left
>  ✓
>
>
>
>
Received on Sunday, 23 May 2010 15:41:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:37 UTC