Re: Styling HTML placeholder attribute

Just had an idea and thought I’d throw it out there. How about, instead of a :placeholder pseudo-class, we introduce a :completed/:filled/:some-other-name pseudo-class that matches when a textual form control (i.e. textarea and all inputs except checkbox, radio, button, submit, image, reset) has text entered in it? Then :placeholder is practically equivalent to [placeholder]:not(:completed) and all we have to specify is that browsers follow whatever styling authors define there, including color. The benefit of this approach is that by solving the :placeholder issue, it solves a bunch of other use cases too, at no extra cost. Or a pseudo-class that only matches in the opposite case since that's more frequently needed, but I have no ideas for naming that (:empty is taken).

The main issue with that is that if authors don't style it but they do style input, the UA stylesheet can't override that with input:not(:completed), similarly to how a UA’s a:hover won't override the author’s a. But a :placeholder pseudo-class has the same issue. I wonder how browsers implementing placeholders with a pseudo-class have solved this. Are they violating the cascade or am I missing something?


Lea Verou
W3C developer relations
http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou






On Jan 23, 2013, at 20:31, Tab Atkins Jr. wrote:

> So, summary of the issue from the call.  This email also exists in
> wiki from at <http://wiki.csswg.org/ideas/placeholder-styling> - if we
> come up with anything new, it will be kept updated there.
> 
> The overarching issue is whether to use a pseudoclass or
> pseudo-element.  A sub-issue here is how to style the placeholder
> text; different methods bias us toward resolving the main issue in
> different ways.
> 
> If we add a pseudoclass, it represents an input element in the state
> of showing its placeholder.  Using a pseudoclass is generally more
> powerful, as it lets you style the input in useful ways, such as
> adding a border to all placeholder-showing inputs.
> 
> If we add a pseudo-element, it represents an inline element *inside
> of* the input, wrapping the placeholder text.  This is more powerful
> in a narrow way, as it lets you apply some properties to the text
> without having them apply to the input as a whole, such as opacity.
> 
> Here are the options that we've come up with so far:
> 
> 1. Add nothing new, use a :placeholder pseudoclass.  Specify that UA
> styles for placeholders are roughly "input:placeholder { color: #999;
> }".
> 
> 2. Add nothing new, use a ::placeholder pseudo-element.  Specify that
> UA styles for placeholders are roughly "input::placeholder { opacity:
> .5; }".
> 
> 3. Add a :placeholder pseudoclass, and revive the ::value
> pseudo-element that once existed in CSS3 UI.  Specify that UA styles
> for placeholders are roughly "input:placeholder::value { opacity: .5;
> }".
> 
> 4. Add a new 'color-opacity' or 'foreground-opacity' property, use a
> :placeholder pseudoclass.  Specify that UA styles for placeholders
> are roughly "input:placeholder { foreground-opacity: .5; }".
> 
> 5. Adopt SVG's fill/fill-opacity/stroke/stroke-opacity properties,
> specifying that they only apply to text, and use a :placeholder
> pseudoclass.  Specify that UA styles for placeholders are roughly
> "input:placeholder { fill-opacity: .5; }".
> 
> I think that #1 is bad.  It requires the author to remember to change
> *two* 'color' properties whenever they change the 'background-color'
> of an input.  dbaron states that FF's experience is that authors
> generally don't, which matches my intuition.
> 
> I agree with Sylvain that #2 isn't great either - adding a
> pseudo-element to solve such a specific problem feels like overkill,
> and it doesn't allow some reasonable stylings that we think authors
> will want to use.
> 
> #3 is a better variant of #2, as it gets us the best of both worlds.
> However, nobody's cared much about ::value so far.  On the other hand,
> two browsers *already have* ::placeholder, so switching the code over
> to just always wrap the displayed value in a ::value (rather than only
> sometimes, when it's a placeholder, wrapping it) probably isn't hard.
> 
> However, I prefer #4 and #5 the best, as they're nice generative
> solutions that would additionally fulfill some long-standing dev
> requests.  (Accidentally solving other problems beyond your own is a
> great property for any solution to have. ^_^)  #5 is my favorite, as
> lots of people have asked for the ability to stroke text, and fill it
> with something other than flat colors (and WebKit already has prefixed
> properties that allow this).  It also pulls some existing SVG
> properties into CSS proper, which is always nice when it happens as it
> reduces duplication across technologies.
> 
> So, I recommend we adopt #5.  We can look to WebKit's existing
> properties for guidance in figuring out the fiddly details (like
> sizing/positioning of images used for fill/stroke).  The properties
> will probably go in Text Decoration, but we can figure out exactly
> where to put them later.
> 
> ~TJ
>

Received on Thursday, 24 January 2013 01:12:28 UTC