[whatwg] Should editable elements have placeholder attribute?

Ojan Vafai ojan at chromium.org
Wed May 2 10:06:55 PDT 2012

On Wed, May 2, 2012 at 3:02 AM, Aryeh Gregor <ayg at aryeh.name> wrote:

> On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > Great. I think the tricky part will be defining exactly how and when the
> > placeholder is displayed.
> >
> > e.g. Should it be treated as if there is a text node in the editable
> > element? Should we ignore things like "<br>" or collapsible spaces when
> > determining whether the element is empty or not?
> Currently the spec isn't clear about this for <input>, so I don't
> think it needs to specify exactly for <textarea> or contenteditable
> either.  It can be left as a UI decision.  As far as QoI goes, I think
> you'd want to display it as long as there's no visible text or images
> or things.  <p><br></p> should still display the placeholder, and
> probably so should <p><font color=red><br></font></p>, etc.  As long
> as there's no text (or <img>, etc.) that's visible to the user -- if
> it *looks* empty, the placeholder should display.
> But this should be up to the UA.

I'm OK with having when the placeholder is displayed be up to the UA. I can
see that being platform specific.

But, we should spec when content is eligible for showing a placeholder
(i.e. we should define what "looks empty" means). I don't see any benefit
in browsers behaving differently here. This part is not platform-specific.
It's just hard to figure out how to spec it.

Input is a different situation since the contents are plain text. It's very
straightforward. The placeholder is shown when the input is empty and not

I agree with everything else you say above in terms of cases that should
show the placeholder. :)

More information about the whatwg mailing list