On Oct 4, 2008, at 7:01 AM, Tab Atkins Jr. wrote:
On Fri, Oct 3, 2008 at 8:24 PM, Andy Lyttle <[EMAIL PROTECTED]>
wrote:
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.
Regards,
Maciej
