Re: Styling HTML placeholder attribute

My 2 cents:

1) Existing implementations aside (which are a strong point for (:):placeholder, agreed), weren't use cases like this supposed to be tackled in a general way by enabling authors to style shadow DOM elements? What happened to that idea? Same goes for ::value.
2) Is there any other use case for a pseudoelement apart from opacity? I can't see any, but my imagination might be limited. :)
3) *-opacity properties are masking the real issue here. Authors need to individually set color and alpha and had wanted to do that for a while, in many different properties. This is a value-related problem, not a property-related problem. Introducing an *-opacity property for every property that accepts a <color> value adds redundancy to the language, not to mention it’s inelegant. Perhaps a solution could be to introduce an alpha(<color>, <number>) function, which in combination with CSS Variables provides a rudimentary solution for all these use cases. CSS preprocessors have a multitude of such functions and frankly, they're the only thing I miss as an author when I compare existing CSS preprocessors with our new preprocessor-inspired specs (Variables and nesting). 
4) Regarding CSS-ifying the placeholder behavior (Sylvain raised this), a pseudoclass for whether the value is empty would solve not only this, but many other use cases as well. Two birds with one stone :) I've often needed such a pseudoclass as an author, and many other authors have asked me if one exists.
5) Why adopt a fill property from SVG that does exactly the same thing as the existing color property? It sounds very confusing. 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 Wednesday, 23 January 2013 22:24:52 UTC