- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Mon, 24 May 2010 10:37:12 +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: <AANLkTilVc7yjhN4TY38t6sljMtdznHIw_oXfk19ZO_lr@mail.gmail.com>
> This translates to making "match-parent" the default text-align value for <ol> and <ul>. Actually, I should have said "the default text-align value for <li>". On Mon, May 24, 2010 at 10:34 AM, Aharon (Vladimir) Lanin <aharon@google.com > wrote: > > 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:38:05 UTC