- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Sun, 23 May 2010 18:40:44 +0300
- 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>
- Message-ID: <AANLkTin7E3y_h44gxFp_FcXj8OgjiFVvhEikPzllOe0G@mail.gmail.com>
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