- From: Ojan Vafai <ojan@chromium.org>
- Date: Wed, 2 May 2012 10:06:55 -0700
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. :)
Received on Wednesday, 2 May 2012 10:06:55 UTC