RE: Styling HTML placeholder attribute

[Tab Atkins Jr.:] 
> On Tue, Jan 22, 2013 at 12:23 PM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> > [Tab Atkins Jr.:]
> >> It's been explored in past threads on the matter.
> > Links? I don't recall this being settled one way or the other.
> 
> http://lists.w3.org/Archives/Public/www-style/2011Apr/0240.html

> (thread conversation between me and you ^_^)
> http://lists.w3.org/Archives/Public/www-style/2010Mar/0095.html

> (two-year-old thread from Mounir on the same subject)
> 
> There may be more, but that's all a quick search dug up.

Right. I'm mostly interested in any thread where we came to some
kind of conclusion? 
> 
> >> Basically, a pseudo-
> >> element lets you achieve the intended placeholder appearance in a
> >> more reliable way.
> >
> > Can you elaborate on scenarios that are less reliable in pseudo-class
> > based implementations? Given that we have implementations, examples are
> best.
> 
> I gave them in somewhat abstract terms in the message you're replying to.
> In more concrete terms, say that we used a pseudo-class, and the UA style
> was:
> 
> input:placeholder { color: #999; } /* approximately the color WebKit ends
> up on by default */
> 
> Then, an author comes along and makes a website with a dark theme, and so
> adjusts the input coloring to have a gray background of their own:
> 
> input { color: white; background: gray; }
> 
> As you can see at
> <http://leaverou.github.com/contrast-ratio/#white-on-gray>, the author's
> chosen color combination is reasonably contrasted.  It's not an ideal mix,
> but it's not horrible either.  On the other hand, a placeholder'd input
> would have terrible contrast <http://leaverou.github.com/contrast-

> ratio/#%23999-on-gray>.  If the author rarely writes placeholder'd inputs
> and didn't test them, ey might not notice the bad contrast for a while.
> When ey does notice, ey's got to manually fix up the placeholder color
> with an "input:placeholder{}" rule emself.
> 
> On the other hand, if we used a pseudo-element, the UA style could be:
> 
> input::placeholder { opacity: .54; }
> /* for black-on-white, produces a color that is approximately #8a8a8a */
> 
> Then, if the author changed to "color: white; background: gray;", the
> placeholder text color would be approximately #c5c5c5, which, while not
> great for contrast, is still nearly double the contrast value of
> #999 <http://leaverou.github.com/contrast-ratio/#%23c5c5c5-on-gray>.
> 
> It should be easy to come up with a similar example for non-black/white
> colors, where the opacity approach preserves the author's intended color,
> while the color approach changes it to gray.
> 
> 
> > I don't follow this reasoning. If :placeholder is a state of the
> > element what prevents the author from using the exact same style he
> > would otherwise apply to the pseudo-element?
> 
> It requires the author to specifically override the placeholder style if
> they ever change the normal input style.  The pseudo-element approach
> works automatically in most cases.
> 
Sorry, I still don't follow. If the author sets his inputs' background to 
black we currently expect her to also change the foreground color accordingly
in order to make users' input visible as they type. I don't get why it is OK 
to require her to do that for the stuff the user will actually type in but it's 
somehow too large a burden for placeholder text that we need a dedicated 
pseudo-element?

There are other issues e.g. as it presumably overlays above the control the 
opacity set on the pseudo-element will also affect the underlying background 
color the author has chosen which may not be what she wanted.

This particular scenario doesn't suggests a pseudo-element to me as much as a 
property to set foreground color alpha independently of foreground color. That 
could be more generally useful.

Received on Tuesday, 22 January 2013 21:42:41 UTC