Re: dir=auto makes no sense for descendant user-visible attributes

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 at 3:50 PM, Matitiahu Allouche <matial@il.ibm.com 
> <mailto: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 <tel:%2B972%2052%202554160>
>
>
>
>
>     From:        "Aharon (Vladimir) Lanin" <aharon@google.com
>     <mailto:aharon@google.com>>
>     To:        Matitiahu Allouche/Israel/IBM@IBMIL
>     Cc:        Ehsan Akhgari <ehsan@mozilla.com
>     <mailto:ehsan@mozilla.com>>, Martin J. Dürst
>     <duerst@it.aoyama.ac.jp <mailto:duerst@it.aoyama.ac.jp>>,
>     public-i18n-bidi@w3.org <mailto: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 <tel:2012> at 5:13 PM, Matitiahu Allouche
>     <_matial@il.ibm.com_ <mailto: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>&#x05D0;<span
>     dir=ltr>bc</span>&#x05D3;</span> is *not* the same as <span
>     dir=ltr>&#x05D0;<span>bc</span>&#x05D3;</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 &lrm; or &rlm; 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_ <tel:%2B972%2052%202554160>
>
>
>
>
>     From:        Ehsan Akhgari <_ehsan@mozilla.com_
>     <mailto:ehsan@mozilla.com>>
>     To:        "Aharon (Vladimir) Lanin" <_aharon@google.com_
>     <mailto:aharon@google.com>>
>     Cc:        _public-i18n-bidi@w3.org_
>     <mailto:public-i18n-bidi@w3.org>, Martin J. Dürst
>     <_duerst@it.aoyama.ac.jp_ <mailto: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/_>
>
>
>     On Thu, Feb 23, _2012_ <tel:2012> at 11:53 PM, Aharon (Vladimir)
>     Lanin <_aharon@google.com_ <mailto: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_ <tel:2012> 6:11 PM, "Ehsan Akhgari"
>     <_ehsan@mozilla.com_ <mailto: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/_>
>
>
>     On Thu, Feb 23, _2012_ <tel:2012> at 6:49 AM, Aharon (Vladimir)
>     Lanin <_aharon@google.com_ <mailto: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_ <tel:2012> at 11:32 AM, "Martin J. Dürst"
>     <_duerst@it.aoyama.ac.jp_ <mailto:duerst@it.aoyama.ac.jp>> wrote:
>     On 2012/02/23 1:11, Ehsan Akhgari wrote:
>     On Wed, Feb 22, _2012_ <tel:2012> at 10:04 AM, Aharon (Vladimir)
>     Lanin<_aharon@google.com_ <mailto: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)
W3C Office in Morocco (http://www.w3c.org.ma/)
Ecole Mohammadia d'Ingénieurs, BP. 765 Agdal-RABAT Morocco
Mobile: +212 (0) 661 22 00 30 

Received on Tuesday, 28 February 2012 08:59:23 UTC