- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Mon, 24 May 2010 10:34:16 +0300
- To: Shachar Shemesh <shachar@shemesh.biz>
- Cc: ntounsi@emi.ac.ma, fantasai <fantasai.lists@inkedblade.net>, Xiaomei Ji <xji@google.com>, "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>
- Message-ID: <AANLkTiniLbdoojluFYIMRETV6Xkot6dGzCA256XQorPb@mail.gmail.com>
> 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. I am ok with this reading of the spec - if we really can add the "match-parent" to it. (I had called it "inherit" because there seems to be mention of it in some places, e.g. < http://www.w3schools.com/css/pr_text_text-align.asp>, but that's probably a good reason not to call it that...) "match-parent" is a little verbose, though. Perhaps "frozen"? >> 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. > Above would solve it should that what you want. Just to make sure I understand: you are saying that given text-align:start working according to Firefox rules, but with the addition of "match-parent" (or whatever) to text-align's vocubulary, <select style="text-align:match-parent"> will keep all the options uniformly aligned despite changes in direction. I agree. > I just claim that is not, typically, what I would want. And here, I guess you (Shachar) are saying that you prefer each option to be aligned to its own direction? Is this correct? If so, that is what I meant by competing preferences. I find options changing alignment disconcerting and difficult to read. I wonder, what did you think of the proposal's section on lists (3.10, < http://www.w3.org/TR/html-bidi/#lists>), which basically said that the location of the bullet or number should follow the list's - and not the list item's - direction? (There was subsequent discussion that said that this should become controlled by a new style property, but that is not the issue right now.) There was then a proposal (< http://lists.w3.org/Archives/Public/public-i18n-bidi/2010AprJun/0006.html>) to make the list item's alignment by default follow the list's alignment, and not the list item's direction. This translates to making "match-parent" the default text-align value for <ol> and <ul>. Is this not to your taste as well? On Sun, May 23, 2010 at 7:57 PM, Shachar Shemesh <shachar@shemesh.biz>wrote: > Aharon (Vladimir) Lanin wrote: > > > 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 :-)) > > I haven't read the specs either, but the very fact it is called "start", > and not "right", seem to suggest (to me) that Firefox got it right (pun > intended). > > 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. > > Both approaches might be confusing under certain circumstances. Common > sense dictates that if an attribute is inherited, specifying it to > explicitly be the same as the parent would not change anything. Your > suggestion breaks that. > > I agree that, in general, the problem needs to be addressed. I think that > your "inherited" suggestion is the way to go. > > > 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. > > Above would solve it should that what you want. I just claim that is not, > typically, what *I* would want. > > > 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 > > another reason to go my way :-) > > Shachar > > -- > Shachar Shemesh > Lingnu Open Source Consulting Ltd.http://www.lingnu.com > >
Received on Monday, 24 May 2010 07:35:07 UTC