[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
focused.
I agree with everything else you say above in terms of cases that should
show the placeholder. :)
More information about the whatwg
mailing list