This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 16160 as part of operation convergence. Originally filed: 2012-02-29 15:11:00 +0000 Original reporter: Aharon Lanin <aharon.lists.lanin@gmail.com> ================================================================================ #0 Aharon Lanin 2012-02-29 15:11:26 +0000 -------------------------------------------------------------------------------- Currently, the HTML5 spec says that "Text from elements (either attribute values or the contents of elements) is expected to be rendered in a manner that honors the directionality of the element from which the text was obtained." While this is generally useful, it does not make sense for elements whose directionality was determined using dir=auto (on the element or an ancestor), since the directionality of an element with dir=auto is chosen on the basis of descendant text nodes and is completely unrelated to the value of the attributes in its scope of influence. The dir=auto feature is designed for use in web application that need to plop some text of unknown direction into the page. There is no reason to assume that the title on the element holding this text is also "plopped in" data; in fact, it is more likely to be an explanation in the page's own language of what got plopped in. The situation is exacerbated by there being no way to specify the directionality of attribute values except wrapping them in LRE|RLE and PDF, which were never designed for human use. This has been reported as https://www.w3.org/Bugs/Public/show_bug.cgi?id=10818 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=15488. The converse situation, when the data of unknown directionality needs to be used for a user-visible attribute, is even more problematic: there is no way to get the user agent to base the directionality of an attribute on its own value. This problem has been discussed on public-18n-bidi@w3.org, and we would like to suggest a potential solution for all three problems (i.e. dir=auto having unintended results on user-visible attribute values, no dir=auto for user-visible attribute values, 3. and no way to declare the directionality of user-visible attributes). We propose a new attribute, attribsdir="ltr|rtl|auto", which would determine the directionality in which an element's attributes (for example title, alt, and placeholder) must appear when displayed to the user: * attribsdir="ltr": the directionality of the element's attributes is 'ltr' * attribsdir="rtl": the directionality of the element's attributes is 'rtl' * attribsdir = "auto": the directionality of each of the element's attributes must be computed based on that attribute's value. If an attribute's value contains a character of bidirectional character type AL or R, and there is no character of bidirectional character type L anywhere before it in the attribute's value, then the directionality of the attribute is 'rtl'. Otherwise, the directionality of the attribute is 'ltr'. * attribsdir not specified: o If the element has dir=auto (explicitly or by default, as is the case for the bdi element), or if the element inherits its directionality from such an element, then the directionality of each of the element's attributes must be computed as if attribsdir="auto" had been specified. o Otherwise, the directionality of the element's attributes is the same as the element's directionality. ================================================================================ #1 Addison Phillips 2012-03-28 00:42:35 +0000 -------------------------------------------------------------------------------- http://www.w3.org/International/track/actions/103 The I18N Core WG has reviewed this request and has not objections (see above action item) ================================================================================ #2 Addison Phillips 2012-05-07 18:04:55 +0000 -------------------------------------------------------------------------------- *** Bug 16977 has been marked as a duplicate of this bug. *** ================================================================================ #3 Anne 2012-05-08 18:47:51 +0000 -------------------------------------------------------------------------------- Would it not be better to simply advise people to use ‎ and ‏? ================================================================================ #4 Aharon Lanin 2012-05-08 19:19:48 +0000 -------------------------------------------------------------------------------- Not sure what you mean. As things stand right now, all attributes inherit the directionality (either ltr or rtl) of the element. They do not have their own dir=auto, so to speak. Thus, starting an attribute with ‎ or ‏ does not set its directionality. ================================================================================ #5 Ian 'Hixie' Hickson 2012-05-10 17:48:36 +0000 -------------------------------------------------------------------------------- If you need to set the directionality of an attribute, the established pattern is to use an element specifically for that attribute, as in: <span dir=rtl title="CBA"><span dir=ltr>abc</span></span> Are there specific use cases on concrete Web sites today for which this is insufficient? ================================================================================ #6 Aharon Lanin 2012-05-10 20:32:16 +0000 -------------------------------------------------------------------------------- (In reply to comment #5) > If you need to set the directionality of an attribute, the established pattern > is to use an element specifically for that attribute, as in: > > <span dir=rtl title="CBA"><span dir=ltr>abc</span></span> This workaround does not work for the placeholder attribute. It needs to be on the input, and the directionality needed for the input may not be the directionality needed for the placeholder. > > Are there specific use cases on concrete Web sites today for which this is > insufficient? Yes, the Firefox options page where you set the home page URL. (It is done in HTML.) The field needs to be LTR. In an RTL installation, the placeholder needs to be RTL. Currently, it gets displayed in LTR like the input, and comes out garbled. I will try to attach a screenshot. Similar case in Google Accounts sign-up page (https://accounts.google.com/accounts/SignUp?hl=iw). The Day and Tear fields need to be LTR, but the placeholders are RTL. Luckily, the placeholders there don't have any LTR words in them, so they don't actually come out garbled like the Firefox options page, but you get the idea. Please note that these examples are for the placeholder problem. I do not yet have cases of problems due to dir=auto, but with it only starting to become available in browsers, no one is using it yet. ================================================================================ #7 Aharon Lanin 2012-05-10 20:36:23 +0000 -------------------------------------------------------------------------------- Created attachment 1129 [details] screenshot of the problem in Hebrew Firefox options page ================================================================================
I don't see any sane solution to this short of using the Unicode bidi characters. Yes, I know that's not a popular answer, but what else do we have?
(In reply to comment #1) > I don't see any sane solution to this short of using the Unicode bidi > characters. Yes, I know that's not a popular answer, but what else do we have? Well, how about what was proposed in the bug, i.e.: a new attribute, attribsdir="ltr|rtl|auto", which would determine the directionality in which an element's attributes (for example title, alt, and placeholder) must appear when displayed to the user: * attribsdir="ltr": the directionality of the element's attributes is 'ltr' * attribsdir="rtl": the directionality of the element's attributes is 'rtl' * attribsdir = "auto": the directionality of each of the element's attributes must be computed based on that attribute's value. If an attribute's value contains a character of bidirectional character type AL or R, and there is no character of bidirectional character type L anywhere before it in the attribute's value, then the directionality of the attribute is 'rtl'. Otherwise, the directionality of the attribute is 'ltr'. * attribsdir not specified: o If the element has dir=auto (explicitly or by default, as is the case for the bdi element), or if the element inherits its directionality from such an element, then the directionality of each of the element's attributes must be computed as if attribsdir="auto" had been specified. o Otherwise, the directionality of the element's attributes is the same as the element's directionality.
What if title="" and placeholder="" have different directions? I don't think this is a good direction to go in. Next we'll be adding attributes for the language of each attribute, etc... Just use the bidi formatting characters when this comes up.
(In reply to comment #3) > Just use the bidi formatting characters when this comes up. The bidi formatting characters are a pain generally (but I do not want to get into that discussion again). They are also completely inadequate for the second use case indicated in the original description, "when the data of unknown directionality needs to be used for a user-visible attribute". For example, I want to put a title attribute on some element, e.g. a picture. The value that I want to display in the tooltip could be the address of the location in the picture, perhaps obtained from some database. I do not know the language or directionality of the title value, but it may not be the same as that of the page. Thus, the LTR address "50 Main Street, Portalnd, OR" will be displayed as "Main Street, Portland, OR 50" in an RTL page. Since I do not know the directionality of the title value, I can not indicate it using bidi formatting characters. If I put dir="auto" on the picture, it will not be set according to the title value because dir="auto" only looks at the text contents of the element, not its attributes. Nor would I want attribute values generally to influence the outcome of dir="auto" on an element. I want a way to say that this title value needs "auto" directionality, but there is currently simply no way to do it. > What if title="" and placeholder="" have different directions? One way to handle it would be to wrap the element with another one, put the title on that, and specify different attribsdir values for the two elements. Another way to handle it would be to allow attribsdir to take a more complicated syntax, e.g. "title:rtl;placeholder:ltr". > I don't think this is a good direction to go in. Next we'll be adding > attributes for the language of each attribute, etc... I agree that attribute language (etc.?) is a real problem too. So, can you suggest a better direction that would solve the problem for all of them? Obviously, it would be great if things like title, alt and placeholder could be specified as child elements instead of attributes. But then we run into a problem with elements like IMG and INPUT that do not allow end tags. Perhaps there is some way to overcome that?
(In reply to comment #4) > I agree that attribute language (etc.?) is a real problem too. I don't think it's a real problem. I don't really think any of these issues are real problems. They're all obscure edge cases that have easy workarounds. > For example, I want to put a title attribute on some element, e.g. a > picture. The value that I want to display in the tooltip could be the > address of the location in the picture, perhaps obtained from some database. > I do not know the language or directionality of the title value, but it may > not be the same as that of the page. Just implement the automatic directionality algorithm on the server and put in the appropriate bidi formatting character. > Another way to handle it would be to allow attribsdir to take a more > complicated syntax, e.g. "title:rtl;placeholder:ltr". I understand that you live in the bidi world and so this seems like a really important issue, but relative to the entire rest of the Web platform this is a tiny corner. Having a dedicated microsyntax just for this, in addition to the microsyntax for languages, plus the complicated algorithms like bidi itself, not to mention paragraph splitting, automatic directionality, attribute value inheritance, etc, is completely disproportionate to the size of the problem.
I tend to agree about the attribsdir syntax idea. I think that's hugely complicated compared to the potential benefit. If we had it to do over again, we would eschew natural language text in attributes altogether. However, we are where we are... I disagree with the statement "[j]ust implement the automatic directionality algorithm on the server and put in the appropriate bidi formatting character." Most folks don't have that level of code available server-side, let alone want to implement it for every insert. Many of the pages I work with on a daily basis consist of largely generated content. I have gone to a lot of trouble to get language and directionality information for each item. Having somewhere to put that information (or have the auto-detection be run separately for each item) make a lot of sense. In this case, we have an element whose direction is indeterminate until runtime whose determined direction then controls sometimes unrelated attribute values. Yes, this is a "corner case". But the desire is to make construction---especially runtime construction---of bidi pages straightforward and requiring the least amount of Unicode bidi control insertion and special markup as it is reasonable to do.
Can we at least have the change that the directionality of each user-visible attribute on an element with dir="auto" be determined from its content, by the usual algorithm, independently of the element's content or that of the other attributes?
Checked in as WHATWG revision r7799. Check-in comment: Let human-readable attributes honour dir=auto separately from the element's contents. http://html5.org/tools/web-apps-tracker?from=7798&to=7799
Comment 7 seems reasonable. The diff in comment 8 attempts to do that. Is that sufficient?
Looks good to me, thanks!