- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Tue, 28 Feb 2012 14:47:36 +0200
- To: Matitiahu Allouche <matial@il.ibm.com>
- Cc: Martin J. Dürst <duerst@it.aoyama.ac.jp>, Ehsan Akhgari <ehsan@mozilla.com>, Najib Tounsi <ntounsi@emi.ac.ma>, public-i18n-bidi@w3.org
- Message-ID: <CA+FsOYYtu1RacUJncQdM4BkutJx7vd9Ee=c0b6qbVw=fQL510g@mail.gmail.com>
Please note that I did not include the "bell or whistle" of the <input> / <textarea> exception. On Tue, Feb 28, 2012 at 2:46 PM, Aharon (Vladimir) Lanin <aharon@google.com>wrote: > That just makes sure that we have the problem that I brought up. To fix > it, one needs the opposite change, i.e. to say "the value of the dir > attribute of the element or its closest ancestor having an explicit or > default dir attribute value". But I fear that for most people this would be > misleading, since most people think, as you did, that the dir attribute > inherits. They would not know that the only element that has a default dir > value is <bdi>. > > So, once again, please consider using the definition with the dir=auto > exception. That is: > > The attribsdir attribute determines the directionality in which the text > of the element's attributes must be displayed to the user. For > attribsdir="auto", the direction is computed independently for each > attribute. If attribsdir is not explicitly specified, the element's > attributes must be displayed in the direction specified by the value of the > dir attribute of the closest ancestor of the element (or the element > itself) having an explicit, valid dir attribute with a value other than > "auto". If there is no such element, the attributes must be displayed ltr. > > Aharon > > > On Tue, Feb 28, 2012 at 2:08 PM, Matitiahu Allouche <matial@il.ibm.com>wrote: > >> I think it can fixed as follows. >> Instead of (old phrasing): >> b. If the element has no attribsdir attribute, the direction of >> the text of visible attributes is the same as the value of the dir >> attribute of the element or its closest ancestor having a dir >> attribute (if the value is "auto", the direction is computed >> independently for each visible attribute). If neither the element >> nor any ancestor has a dir attribute, it is 'ltr'. >> Let's have (new phrasing): >> b. If the element has no attribsdir attribute, the direction of >> the text of visible attributes is the same as the value of the >> explicit (not default) dir >> attribute of the element or its closest ancestor having an explicit >> (not default) dir >> >> attribute (if the value is "auto", the direction is computed >> independently for each visible attribute). If neither the element >> nor any ancestor has a dir attribute, it is 'ltr'. >> >> Shalom (Regards), Mati >> Bidi Architect >> Globalization Center Of Competency - Bidirectional Scripts >> IBM Israel >> Mobile: +972 52 2554160 >> >> >> >> >> From: "Aharon (Vladimir) Lanin" <aharon@google.com> >> To: Najib Tounsi <ntounsi@emi.ac.ma> >> Cc: Matitiahu Allouche/Israel/IBM@IBMIL, "Martin J. Dürst" < >> duerst@it.aoyama.ac.jp>, Ehsan Akhgari <ehsan@mozilla.com>, >> public-i18n-bidi@w3.org >> Date: 28/02/2012 12:52 >> Subject: Re: dir=auto makes no sense for descendant user-visible >> attributes >> ------------------------------ >> >> >> >> Oops, I just realized that there is a problem with the simplified >> formulation. The <bdi> element has dir=auto by default. Thus, the title in >> <html dir=rtl><bdi dir=auto title="C++"> will be displayed as "C++", but >> the title in <html dir=rtl><bdi title="C++"> will be displayed as "++C", >> even though <bdi> is supposed to be the same as <bdi dir=auto>. >> >> I am not sure how to fix this in the simplified formulation while keeping >> it simple. >> >> Please note that my formulation *with* the dir=auto exception does not >> suffer from this problem. And I am still convinced that it will usually >> give better results. >> >> Thoughts? >> >> Aharon >> >> On Tue, Feb 28, 2012 at 11:02 AM, Najib Tounsi <*ntounsi@emi.ac.ma*<ntounsi@emi.ac.ma>> >> wrote: >> Aharon (Vladimir) Lanin wrote: >> Ok, so how about we propose it as you have phrased it, but afterwards >> also list a number of optional "bells and whistles" (input/textarea >> exception, dir=auto exception, the more complicated syntax). Let the editor >> reject them. He enjoys doing that anyway :-) >> >> Ehsan, Najib: is Mati's formulation acceptable to you? >> >> Yes! This proposal seems clear to me too. I support it. No more need of >> ‫ and ‬ :-) >> >> >> Aharon >> >> >> On Mon, Feb 27, *2012* <2012> at 3:50 PM, Matitiahu Allouche <* >> matial@il.ibm.com* <matial@il.ibm.com> <mailto:*matial@il.ibm.com*<matial@il.ibm.com>>> >> wrote: >> >> Thanks to Aharon for improving the phrasing of my proposal. I now >> phrase it as follows: >> >> a. If the element has an attribsdir attribute, the value of this >> attribute determines the direction of the text of each visible >> attribute (for attribsdir="auto", the direction is computed >> independently for each attribute). >> b. If the element has no attribsdir attribute, the direction of >> the text of visible attributes is the same as the value of the dir >> attribute of the element or its closest ancestor having a dir >> attribute (if the value is "auto", the direction is computed >> independently for each visible attribute). If neither the element >> nor any ancestor has a dir attribute, it is 'ltr'. >> >> I prefer this simpler specification even at the cost of what >> Aharon calls a loss of usability. In fact, this loss of usability >> is that with my spec it is necessary to specify a value for >> attribsdir in cases when this would not be needed with Aharon's >> specification. There is no case that can be handled with Aharon's >> spec and cannot be handled with mine. >> Simple wins, IMHO. >> >> Aharon wrote: "I presume this means that you would be against >> allowing attribsdir to take a more complicated (explicit) value >> like "title:ltr;placeholder:rtl", correct?" >> I think that this a nice syntactic format, but since it has not >> found its place in HTML until now, and since it is possible to >> express the same meaning with formats already existing in HTML, I >> would rather not introduce it, to say nothing on the fact that its >> chances to be accepted by the WHATWG seem very slim. >> >> >> Shalom (Regards), Mati >> Bidi Architect >> Globalization Center Of Competency - Bidirectional Scripts >> IBM Israel >> Mobile: *+972 52 2554160* <%2B972%2052%202554160><tel:%2B972%2052%202554160> >> >> >> >> >> >> From: "Aharon (Vladimir) Lanin" <*aharon@google.com*<aharon@google.com> >> <mailto:*aharon@google.com* <aharon@google.com>>> >> >> To: Matitiahu Allouche/Israel/IBM@IBMIL >> Cc: Ehsan Akhgari <*ehsan@mozilla.com* <ehsan@mozilla.com> >> <mailto:*ehsan@mozilla.com* <ehsan@mozilla.com>>>, Martin J. Dürst >> <*duerst@it.aoyama.ac.jp* <duerst@it.aoyama.ac.jp> <mailto:* >> duerst@it.aoyama.ac.jp* <duerst@it.aoyama.ac.jp>>>, >> *public-i18n-bidi@w3.org* <public-i18n-bidi@w3.org> <mailto:* >> public-i18n-bidi@w3.org* <public-i18n-bidi@w3.org>> >> >> Date: 27/02/2012 14:09 >> Subject: Re: dir=auto makes no sense for descendant >> user-visible attributes >> >> ------------------------------------------------------------------------ >> >> >> >> See below >> >> On Sun, Feb 26, *2012* <2012> <tel:*2012* <2012>> at 5:13 PM, >> Matitiahu Allouche >> >> <_matial@il.ibm.com_ <mailto:*matial@il.ibm.com* <matial@il.ibm.com>>> >> wrote: >> I am afraid that I have no silver bullet for this issue, and I >> will go along with Aharon's proposal, but with some needed (IMHO) >> simplification, because if it needs 9 examples to describe it >> >> The examples are not there to describe it, and I was not trying to >> give as few examples as possible. I give a definition, and it's >> not complicated. But let me re-phrase the definition of the >> default value of attribsdir even more simply: >> >> - If the element is not <input> or <textarea>, and has a dir >> attribute with a value other than auto, the same as its dir >> attribute. >> - Otherwise, if any ancestor of the element has a dir attribute >> with a value other than auto, the same as the dir attribute of the >> closest such ancestor >> - Otherwise, 'ltr'. >> >> , it is too complicated for my feeble mind. >> So here is what I propose. >> a. If attribsdir is not specified and the element has (explicitly >> or by inheritance) a dir different from auto, its dir applies to >> its visible attributes (no change from current spec). b. If >> attribsdir is not specified and the element has dir=auto >> (explicitly or by inheritance), dir=auto also applies >> independently to each of the visible attributes. >> c. If attribsdir is specified, it overrides the dir of the >> element. If attribsdir=auto, the direction is computed >> independently for each of the visible attributes. >> >> I do not think that the definition can be phrased in terms of dir >> inheritance because the dir attribute does not inherit. For >> example, <span dir=ltr>א<span >> dir=ltr>bc</span>ד</span> is *not* the same as <span >> dir=ltr>א<span>bc</span>ד</span> (the first comes >> out דbcא, while the second comes out אbcד). >> >> Thus, I would phrase the definition you are proposing (for the >> attribsdir default value) as: >> >> - If the element has a dir attribute, the same as its dir attribute. >> - Otherwise, if any ancestor of the element has a dir attribute, >> the same as the dir attribute of the closest such ancestor. >> - Otherwise, 'ltr'. >> >> Or, perhaps more simply, as: The default value of attribsdir is >> the same as the value of the dir attribute of the element or its >> closest ancestor having a dir attribute. If neither the element >> nor any ancestor has a dir attribute, it is 'ltr'. >> >> There are two simplifications in this definition compared to mine: >> - no exception for <input> and <textarea> >> - no exception for dir=auto >> >> I can live with either or both of these simplifications, even >> though I think that usually the results would be better without >> the simplifications. However, I would prefer to let the HTML5 spec >> editor be the one to make simplifications that only make the >> definition simpler, not more usable. >> >> Unless I am wrong (it has happened in the past), this proposal >> creates no backward compatibility problem, >> >> Correct. >> it is easy to understand and it allows any weird combination of >> different directions for element data and attributes' text to be >> solved by specifying attribsdir=auto and prefixing the attribute >> value by ‎ or ‏ as needed. >> >> True. >> >> I presume this means that you would be against allowing attribsdir >> to take a more complicated (explicit) value like >> "title:ltr;placeholder:rtl", correct? >> >> >> Shalom (Regards), Mati >> Bidi Architect >> Globalization Center Of Competency - Bidirectional Scripts >> IBM Israel >> Mobile: _*+972 52 2554160* <%2B972%2052%202554160>_ >> <tel:%2B972%2052%202554160> >> >> >> >> >> From: Ehsan Akhgari <_ehsan@mozilla.com_ >> <mailto:*ehsan@mozilla.com* <ehsan@mozilla.com>>> >> To: "Aharon (Vladimir) Lanin" <_aharon@google.com_ >> <mailto:*aharon@google.com* <aharon@google.com>>> >> Cc: _public-i18n-bidi@w3.org_ >> <mailto:*public-i18n-bidi@w3.org* <public-i18n-bidi@w3.org>>, Martin >> J. Dürst >> <_duerst@it.aoyama.ac.jp_ <mailto:*duerst@it.aoyama.ac.jp*<duerst@it.aoyama.ac.jp> >> >> >> >> Date: 24/02/2012 19:30 >> Subject: Re: dir=auto makes no sense for descendant >> user-visible attributes >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> I'm fine with attribsdir as you proposed, although I'm not quite >> sure about the more complex syntax, since it's so different to the >> way other attributes in HTML work. >> >> Let's hear what others think. >> >> Cheers, >> -- >> Ehsan >> <_*http://ehsanakhgari.org/_* <http://ehsanakhgari.org/_>> >> >> >> On Thu, Feb 23, _*2012* <2012>_ <tel:*2012* <2012>> at 11:53 PM, >> Aharon (Vladimir) >> >> Lanin <_aharon@google.com_ <mailto:*aharon@google.com*<aharon@google.com>>> >> wrote: >> Good example. >> >> In the past, Ian has already rejected titledir etc. >> >> Perhaps they will be more receptive to attribsdir, since it's just >> one attribute and tackles some serious problems. >> >> Your example could be handled by also allowing syntax like >> "title:rtl;placeholder:ltr". Even just " placeholder:ltr" could do >> if the other attributes then follow the default (which in this >> case would presumably be rtl despite dir=ltr on the <input>). >> Since it does not inherit, there would not be too much difficulty >> supporting the complex syntax. >> >> But attribsdir would still be useful even if it only allowed a >> simple value. >> >> Aharon >> >> On Feb 23, _*2012* <2012>_ <tel:*2012* <2012>> 6:11 PM, "Ehsan >> Akhgari" >> >> <_ehsan@mozilla.com_ <mailto:*ehsan@mozilla.com* <ehsan@mozilla.com>>> >> wrote: >> How about something like: >> >> <input name="phone" title="TELEPHONE" placeholder="(123) 456-7890"> >> >> If we introduce an attribsdir attribute, I can see people asking >> to differentiate between different attributes, such as the example >> above. From a bidi perspective, the ultimate solution is to have >> a directional attribute for every user visible attribute, such as >> titledir, placeholderdir, etc. But honestly I don't expect such a >> proposal to be easily accepted in WHATWG, given the recent >> resistance towards placeholderdir. >> >> -- >> Ehsan >> <_*http://ehsanakhgari.org/_* <http://ehsanakhgari.org/_>> >> >> >> On Thu, Feb 23, _*2012* <2012>_ <tel:*2012* <2012>> at 6:49 AM, >> Aharon (Vladimir) >> >> Lanin <_aharon@google.com_ <mailto:*aharon@google.com*<aharon@google.com>>> >> wrote: >> Well, I, for one, am not so happy with my proposal :-). >> >> Its solution is to apply dir=auto to the individual user-visible >> attributes, even though in most cases the values of such >> attributes are not dynamic, but localized to the page locale, e.g. >> (in an English page) <input dir="auto" name="purpose" >> placeholder="The purpose of your visit.">. Using estimation for >> them is not just wasteful, but bound to reach the wrong conclusion >> occasionally. >> >> And it does not address the long-standing issue of no way to set >> the directionality of an attribute (other than using formatting >> characters). The canonical examples are: >> >> - <input dir="ltr" name="telephone" title="PHONE NUMBER.">, which >> has to be worked around as <span title="PHONE NUMBER."><input >> dir="ltr" name="telephone"></span> >> - <input dir="ltr" name="telephone" placeholder="PHONE NUMBER.">, >> which has no workaround other than RLE + PDF. >> >> What if we could instead have a new attribute, >> attribsdir="ltr|rtl|auto", which would determine the >> directionality in which the element's user-visible attributes must >> be displayed. A very important part of this would be the default >> value. IMO, it would be best if it could default to the dir >> attribute value of the closest ancestor - or the element itself >> unless it is <input> or <textarea> - that has an explicit dir >> attribute with a value other than "auto". If there is no such >> ancestor, the default is "ltr". Thus: >> >> - the only way to get attribsdir=auto is to specify it explicitly >> - the explicit dir attribute value of <input> and <textarea>, >> which is presumably meant to correspond to the directionality of >> their content, not their user-visible attributes, does not affect >> their default attribsdir. >> - with the exceptions of <input dir="...">, <textarea dir="...">, >> and <whatever dir=auto>, the result is backward-compatible. >> >> Examples: >> >> 1. <html><body><div title="?">: ltr >> >> 2. <html dir=rtl><body><div title="?">: rtl >> >> 3. <html><body><div dir=rtl title="?">: rtl >> >> 4. <html><body><div><div dir=rtl><div><div title="?">: rtl >> >> 5. <html dir=rtl><body><div><input dir=ltr title="?"> : rtl >> >> 6. <html><body><div dir=rtl><div dir="auto" title="?">hello</div>: >> rtl >> >> 7. <html><body><div dir=rtl><div dir="auto">ltr >> content<div title="?">: rtl >> >> 8. <html dir=rtl><body><div title="?" attribsdir="ltr">: ltr >> >> 9. <html dir=rtl><body><div title="?" attribsdir="auto">: auto >> >> Even if we couldn't get the <input> and <textarea> exception, we >> would still be ok - the page would just have to >> specify attribsdir explicitly on the problematic inputs. >> >> Aharon >> >> On Thu, Feb 23, _*2012* <2012>_ <tel:*2012* <2012>> at 11:32 AM, >> "Martin J. Dürst" >> >> <_duerst@it.aoyama.ac.jp_ <mailto:*duerst@it.aoyama.ac.jp*<duerst@it.aoyama.ac.jp>>> >> wrote: >> On 2012/02/23 1:11, Ehsan Akhgari wrote: >> On Wed, Feb 22, _*2012* <2012>_ <tel:*2012* <2012>> at 10:04 AM, >> Aharon (Vladimir) >> Lanin<_aharon@google.com_ <mailto:*aharon@google.com*<aharon@google.com> >> > >> >> wrote: >> >> One possibility is to divorce user-visible attributes from their >> elements' >> directionality completely, always estimating the directionality of >> each >> attribute by its content. This suffers from backwards compatibility >> problems (since estimation is a heuristic that sometimes gives the >> wrong >> answer). >> >> A better possibility is to divorce it only for elements under the >> influence of dir=auto. Thus, if an element has dir=auto (explicitly or >> implicitly, the latter being the case for<bdi>), each of the >> attributes in >> the subrtree rooted at that element, with the exception of elements >> specifying dir="ltr" or dir="rtl" and their descendants, must be >> displayed >> to the user as if they had a dir=auto of heir own. >> >> >> I like the second proposal better. Although I have to say that it >> has been >> worded a bit vaguely. What I have in mind is for the title >> attribute in >> the following example to have a resolved RTL direction: >> >> <p dir="auto" title="RTL TEXT followed by ltr text">ltr text >> FOLLOWED BY >> RTL TEXT</p> >> >> I agree with Ehsan that the second proposal is better. It's >> something that comes quite naturally once one gets used to it. >> >> Regards, Martin. >> >> >> >> >> >> -- >> Najib TOUNSI (tounsi at *w3.org* <http://w3.org/>) >> W3C Office in Morocco (*http://www.w3c.org.ma/* <http://www.w3c.org.ma/>) >> Ecole Mohammadia d'Ingénieurs, BP. 765 Agdal-RABAT Morocco >> Mobile: *+212 (0) 661 22 00 30* <%2B212%20%280%29%20661%2022%2000%2030> >> >> >> >> >
Received on Tuesday, 28 February 2012 12:48:31 UTC