This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16160 - dir=auto does not work for user-visible attribute values
Summary: dir=auto does not work for user-visible attribute values
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Silvia Pfeiffer
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
: 16977 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-29 15:11 UTC by Aharon Lanin
Modified: 2013-04-15 03:37 UTC (History)
12 users (show)

See Also:


Attachments
screenshot of the problem in Hebrew Firefox options page (31.36 KB, image/png)
2012-05-10 20:36 UTC, Aharon Lanin
Details

Description Aharon Lanin 2012-02-29 15:11:26 UTC
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.
Comment 1 Addison Phillips 2012-03-28 00:42:35 UTC
http://www.w3.org/International/track/actions/103

The I18N Core WG has reviewed this request and has not objections (see above action item)
Comment 2 Addison Phillips 2012-05-07 18:04:55 UTC
*** Bug 16977 has been marked as a duplicate of this bug. ***
Comment 3 Anne 2012-05-08 18:47:51 UTC
Would it not be better to simply advise people to use ‎ and ‏?
Comment 4 Aharon Lanin 2012-05-08 19:19:48 UTC
(In reply to comment #3)
> Would it not be better to simply advise people to use ‎ and ‏?

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.
Comment 5 Ian 'Hixie' Hickson 2012-05-10 17:48:36 UTC
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?
Comment 6 Aharon Lanin 2012-05-10 20:32:16 UTC
(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.
Comment 7 Aharon Lanin 2012-05-10 20:36:23 UTC
Created attachment 1129 [details]
screenshot of the problem in Hebrew Firefox options page
Comment 8 contributor 2012-07-18 06:57:51 UTC
This bug was cloned to create bug 17829 as part of operation convergence.
Comment 9 Edward O'Connor 2012-10-02 23:51:20 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: Let's consider this for HTML.next.
Comment 10 jam0410a 2012-11-24 22:56:09 UTC
(In reply to comment #0)
> 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.
Comment 11 Robin Berjon 2013-01-21 16:00:19 UTC
Mass move to "HTML WG"
Comment 12 Robin Berjon 2013-01-21 16:03:04 UTC
Mass move to "HTML WG"
Comment 13 Silvia Pfeiffer 2013-04-15 03:37:57 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If
you are satisfied with this response, please change the state of
this bug to CLOSED. If you have additional information and would
like the Editor to reconsider, please reopen this bug. If you would
like to escalate the issue to the full HTML Working Group, please
add the TrackerRequest keyword to this bug, and suggest title and
text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this
document:   http://dev.w3.org/html5/decision-policy/decision-policy-v2.html

Status: Partially Accepted

Change Description:
https://github.com/w3c/html/commit/39dd173eebedc3f7c58c1a8dee8eb58bdccc6c19

Rationale: Introduction of a new attribute seems overkill for this situation when bidi formatting characters already provide a solution for this problem. However, we clarify 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. This adopts the solution from the WHATWG.