[Bug 15488] it makes no sense to limit the placeholder attribute to values of the same direction as the <input>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15488

--- Comment #2 from Aharon Lanin <aharon.lists.lanin@gmail.com> 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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Sunday, 5 February 2012 11:12:00 UTC