W3C home > Mailing lists > Public > www-style@w3.org > January 2013

RE: Styling HTML placeholder attribute

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 23 Jan 2013 03:08:40 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Mounir Lamouri <mounir@lamouri.fr>, www-style list <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178291BF49E3B@TK5EX14MBXC221.redmond.corp.microsoft.com>

[Tab Atkins Jr.:] 
> Has anyone requested that?  It seems slightly weird to have text fade out
> underneath the text you're currently typing.

Sure. We're not talking about long effects; how many characters do people 
type within .2s of clicking/tabbing into a field? There are many other 
things you may want to do with this state that do not require timed effects; 
you can adjust the background-color or the border slightly to visually 
separate the things you've visited from the ones you haven't yet. Hiding 
some grayed text is not the only you might want to style when a control 
exits the placeholder state.

> 
> However, I'm sympathetic to the desire for more value out of the
> placeholder.  In one of the earlier threads that I linked, you suggested
> we use the old specification that <input> exposes a ::value pseudo-
> element, and combine that with a :placeholder pseudo-class.
> That would achieve the exact same thing, while offering more power, by
> building the same functionality out of more basic functionality.

We did expose a ::value pseudo-class; none of the motivations to do so 
had anything to do with the cosmetic issue that preoccupies you, however. 
Our design was merely a consequence of our input controls having multiple 
subparts and a requirement to be able to style them separately; this in 
turn required independent selection so there was no choice, really. 

While adding a pseudo-element is *a* possible solution to the color 
scenario you mention it seems more of a workaround i.e. we can't specify 
text opacity independently of text color so we hack around it by adding a 
pseudo-element in the control's internals. 

Now, if there are other obvious use-cases for making this a pseudo-element 
and the improved color matching comes along for the ride, great. Otherwise it 
just seems an odd way to fix what seems to be a more general issue. 

Finally, a :placeholder pseudo-class adds value independently of the model
chosen to contain the placeholder text. It just allows the styling of this
control state, which doesn't need a pseudo-element to be useful.
 
> 
> 
> >> > 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.
> >>
> >> The background color is set on the element itself, not the pseudo
> >> inside of it.
> >
> > If a) the placeholder pseudo renders above the element's background
> > and b) its default background color is the initial transparent value
> > then your UA stylesheet rule will also affect the background color
> specified by the author for the element.
> 
>o I still don't understand what you're trying to say here.  The UA
> stylesheet rules are assumed to be something like:
> 
> input[type='text'] { color: black; background: white; }
> input[type='text']::placeholder { opacity: .5; }
> 
> The placeholder's background is transparent, so the opacity doesn't affect
> anything.  The input's background isn't affected by a child's opacity in
> any case.  Can you be more specific about what you see happening?

My bad. My sample already had an rgba() background color so I used an 
rgba(0,0,0,0.4) to make some shade of transparent black. Definitely 
not equivalent to opacity:0.4 with background-color:transparent...Doh :)

So this would only be awkward when the author sets a background-color on 
the placeholder state; in which case they'll have to deal with the combination
of one or two background colors with the default opacity. 

Received on Wednesday, 23 January 2013 03:10:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT