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 15488 - it makes no sense to limit the placeholder attribute to values of the same direction as the <input>
Summary: it makes no sense to limit the placeholder attribute to values of the same di...
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:
Depends on:
Blocks:
 
Reported: 2012-01-10 05:10 UTC by Aharon Lanin
Modified: 2012-09-28 13:59 UTC (History)
9 users (show)

See Also:

Attachments

Description Aharon Lanin 2012-01-10 05:10:18 UTC 
Currently, the HTML spec (http://dev.w3.org/html5/spec/Overview.html#text-rendered-in-native-user-interfaces) states 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 usually what one wants, there are cases that it is does not suit the placeholder attribute.

For example, say that one has a Hebrew or Arabic page containing an <input type="text"> intended for the user to enter a snippet of JavaScript. One would then make it <input type="text" dir="ltr">, since JavaScript code is always LTR. One might want a placeholder on the input, however, that would be in the language of the rest of the page, and thus RTL. According to the spec, however, it would be displayed in LTR, and thus garbled. Another example would be an <input type="tel">, since telephone numbers are always LTR, but one would might easily want an RTL placeholder on it.

We had a similar problem with the title attribute in https://www.w3.org/Bugs/Public/show_bug.cgi?id=10818: the title's value sometimes needs to have one direction while the element needs another. With the title attribute, however, we at least had a workaround: wrap the element in a span, move the title to the span, and set the dir attribute on both elements as each needs. This does not work for placeholder because placeholder does not work on a <span>.

Two possible solutions to this problem are:

1. define a placeholderdir attribute for <input>.

2. always display the placeholder as if it had dir=auto.

The second possibility is not perfect, but at least setting the placeholder description explicitly is more easily done by prefixing it with an &lrm; or &rlm; than by wrapping it in LRE|RLE and PDF characters.
Comment 1 Ian 'Hixie' Hickson 2012-02-03 06:38:27 UTC 
Why would it be garbled? dir=rtl isn't an override, just an embedding. The most it would do is change the positioning of punctuation (easily fixed with explicit embedding information) or the alignment.

I guess I don't mind if we make it dir=auto, but I really find this allergy to Unicode bidi formatting characters to be getting out of control. This is an extreme edge case, we shouldn't add an attribute for it.
Comment 2 Aharon Lanin 2012-02-05 11:11:58 UTC 
> Why would it be garbled? [...] The most
> it would do is change the positioning of punctuation

Well, first of all, misplaced punctuation is already sufficiently annoying.
But it can certainly get worse. For example, let's say that I have a site named "foo", with my own set of user accounts. The account names are limited to Latin letters, numbers, periods, underscores, and dashes. I support user interfaces in several languages, including RTL ones. Since "foo" is my brand, it remains "foo" in all locales.

Where the English UI has an <input type="text" placeholder="your foo username">, an RTL one has it as <input type="text" dir="ltr" placeholder="YOUR foo USERNAME">. (I am using the convention of uppercase Latin for RTL characters here to make this example intelligible to all readers.)

Why did I make it dir="ltr"? So that a username like john.doe will not go through the stage of looking like ".john" while being typed, with the caret jumping around and/or being displayed in strange places.

To be intelligible, my placeholder has to be displayed RTL, as:

EMANRESU foo RUOY

Instead, because of the dir=ltr, it is displayed in LTR, as

RUOY foo EMANRESU

This is as intelligible as "username OOF your" would be in English.

So, I try to fix it by making my input dir="auto". It does not help, since the spec says that the value of any attribute has to be displayed in the element's *directionality*. This is either "ltr" or "rtl", never "auto". And for an empty <input> (which it has to be for the placeholder to be displayed), the dir=auto evaluates to "ltr" directionality.

> This is an extreme edge case

Not at all. My guess is that a very significant percentage of inputs is for types of data that has to be LTR, such as numeric data (e.g. phone number, age, item count) and always-ltr text data like the username above. In a well-designed RTL page, these should all be marked with dir=ltr. And once dir=auto becomes available in more browsers, most of the rest should be marked with dir=auto. In either case, the placeholder will be displayed LTR, and thus will be garbled in an RTL page if it (besides containing some RTL words):
- starts with a number, or
- ends with punctuation, or
- contains an LTR word (e.g. a brand name)

> easily fixed with explicit embedding information

There is nothing easy about using LRE/RLE + PDF for the average human being. By and large, users do not even know that they exist. They can not generate them on their keyboards, and if they could, their invisibility makes it a challenge to edit the placeholder later. And if they type them as entities, they wind up becoming discombobulated. For example, here is what "&#8234;hello&#8236;" looks like once I substitute actual RTL character for the "hello":

placeholder="&#8234;שלום&#8236;"

Having said all this and hopefully shown that the problem is real, I must admit that I do not know of a solution that really makes me happy.
Comment 3 contributor 2012-07-18 06:54:00 UTC 
This bug was cloned to create bug 17814 as part of operation convergence.
Comment 4 Robin Berjon 2012-09-14 11:55:21 UTC 
Silvia: assigning to you since there actually were changes made to the spec (added examples) for this.

Aharon: can you indicate if you are happy with the examples?
Comment 5 Silvia Pfeiffer 2012-09-28 05:07:05 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: Accepted
Change Description: applied patch
https://github.com/w3c/html/commit/8ff8266583f7cebd62393ca1f58e33954e8c9002
Rationale: adopted resolution by WHATWG
Comment 6 Aharon Lanin 2012-09-28 13:59:09 UTC 
(In reply to comment #5)
The examples could be made a bit more clear by adding a dir="ltr" to each of the <input> tags (as would be typically done in an RTL page). Otherwise, they are fine.

I am still unhappy about having to use LRE/RLE/PDF to indicate the overall directionality of a placeholder. An attribsdir attribute as proposed by https://www.w3.org/Bugs/Public/show_bug.cgi?id=16160 (a.k.a. https://www.w3.org/Bugs/Public/show_bug.cgi?id=17829) would be a better solution to this problem.