[whatwg] Placeholder option for text input boxes
mjs at apple.com
Sat Oct 4 14:55:44 PDT 2008
On Oct 4, 2008, at 7:01 AM, Tab Atkins Jr. wrote:
> On Fri, Oct 3, 2008 at 8:24 PM, Andy Lyttle <whatwg at phroggy.com>
> On Oct 3, 2008, at 4:35 PM, Tab Atkins Jr. wrote:
>> Man, I could *really* see the "hint" function being viable and
>> quite useful. It offers up a completely new-and-useful semantic,
>> and there's no particular place it should already go. I'd accept
>> this as a new attribute without reservation if it was renamed
>> @hint, so it's absolutely clear what the semantic for it is.
> The only reason to use placeholder instead of hint is that Apple
> already implemented placeholder. Documentation should explain that
> placeholder is to be used for hints, not for labels (and people can
> then ignore the documentation and use it for labels anyway, but at
> least we tried).
> Well, we don't really have interop yet, since *only* Webkit
> implements it currently, and officially only on a single non-
> standard input type (though it happens to apply to text and similar
> input types). If we can shift the name over *now*, before FF
> implements it fully, it would probably be fine.
> On the other hand, I don't want to be one of those jerks who tries
> to block a feature solely because they don't like its name.
> However, it's a proven fact that most people don't look at
> documentation *ever*, and so having the name provide a perfectly
> intuitive hint for what the attribute is supposed to do would
> probably be best. At the very least it would set up some cognitive
> dissonance for people using it as a label, hopefully.
I think "placeholder" is as good a name as "hint"; it may sound less
"semantic" but it's more clear that it would result in a tooltip like
"title" would. That being said, it would not be an excessive burden
for us to support "hint" as well as "placeholder" for compatibility.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg