[whatwg] <input placeholder="">

[Ojan Vafai]

On Tue, Dec 2, 2008 at 2:44 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 17 Nov 2008, Ojan Vafai wrote:
> > This is a useful property on any text input element. Seems like it
> > should apply to textareas as well as contentEditable elements and
> > iframes with designMode on. I can point to real-world examples of the
> > latter if need be. I think it's acceptable that it be a plain-text
> > string in all cases, but that it ought to also be CSS styleable. I don't
> > know if html5 is the right place to spec that. WebKit currently uses the
> > input::-webkit-input-placeholder.
>
> I think for contentEditable it's definitely not something we want to
> support natively; I've no idea how that would even work. I'd recommend
> doing it in CSS, using generated content based on the title="" attribute
> or some such.
>

I don't follow. What's the difficulty with supporting placeholder for
contentEditable? The point is that you want it to correspond to focus state,
so generated content doesn't really help you much there. You still end up
with complicated code that's hard to get right. For example, I only know of
Google properties that do this (GoogleBase, Groups, Page Creator and
Presentations).


> For <textarea>, a placeholder value seems odd. Do you have examples of
> people doing that?
>

I don't have examples other than Thomas's, however, a quick google
search<http://www.google.com/search?rlz=1C1GGLD_enUS289US301&sourceid=chrome&ie=UTF-8&q=textarea+with+placeholder+text>does
point to a lot of tutorial sites for adding placeholder text to
textareas. I don't quite see what's odd about it though. It's just another
case where you want to communicate what the user should put into an
text-entry area and it has all the same complexity to the web developer that
a text input has.

Ojan


> On Tue, 25 Nov 2008, Matthew Paul Thomas wrote:
> >
> > I was asking, obviously, what use is a default value if you can't edit
> > it. If an enabled text field had a displayed value= but the value was
> > not actually editable, that would be unpleasantly surprising.
> >
> > That problem applies just as much to <input placeholder="foo"> as it
> > would have done to <input value="foo" clearonfocus>: depending on
> > whether the placeholder text is greyed out, it would make the field
> > either look like it has a value when it actually doesn't, or look
> > disabled when it actually isn't. It would also hide the label or hint
> > for the field for *precisely* the period when you need it most. I'm not
> > aware of any possible presentation that avoids both (or even one of!)
> > those problems, and previously HTML5 has shied away from expecting
> > browsers to implement things that have no known reasonable presentation.
> >
> > I appreciate that Web authors currently go to some scripting lengths to
> > position labels for text fields inside the fields, and I think it's
> > quite appropriate that they should have to go to those lengths, because
> > it makes bad design more difficult. I would rather see, as I've
> > previously suggested, markup for associating form controls with hints
> > outside them in a similar way as labels can be associated now.
>
> I understand your position, but it seems that the industry has moved
> towards this as a pretty standard feature of user interfaces now, for
> better or worse.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081202/7a815ca1/attachment.htm>