RE: Styling HTML placeholder attribute

[Tab Atkins Jr.:]

<snip>
> 
> 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.

dbaron talked about people who don't test across browsers, or not well 
enough to notice the placeholder color they set in favorite browser X is 
off in browser Y; or who don't care; which, if browser X is popular with 
authors, puts pressure on Y and other browsers like it to follow. I can 
definitely sympathize here; it's not hard to find folks who assume this 
to be a WebKit-only thing; also, during Windows 8 developers often 
claimed our placeholder styling didn't work. Nearly every single time 
it turned out they wrote '::' instead of ':'. (More on that later)
 
And this kind of confusion seems the main motivation for the thread. But 
that's a different argument from 'regardless of browser too many people 
won't notice their placeholder color isn't what they want until after 
they're in production'. I doubt we'll agree on this; nor do I think we 
need to.


> 
> 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.

As I told you privately, we actually explored the pseudo-element approach 
at one point. But as we wanted to express as much control behavior as 
possible in CSS we ran into an issue: how do we set display:none 
on this pseudo-element at the right time? Or, conversely, when do we set 
display:inline-block and the other styling it needs when it ought to be 
visible? :focus is clearly not the answer. One option is to keep the 
visibility logic hard-coded; or it can become a new pseudo-class. Once 
we did the latter the need for a separate pseudo-element effectively 
vanished. (And made our life quite easier, frankly).

Side note: I think much confusion here arises from naming. It's unnatural 
to think of a noun like placeholder as a state. (Even our own Arron was 
confused by this earlier, in fact). It may even partly explain why some 
folks will first write this pseudo with a '::' prefix.
 
So if we define a pseudo-class I'll incur some bikeshedding risk and suggest 
we think of other names for it?

But even if we do not expose this state in CSS, interoperable agreement 
on when this content is/isn't visible would be best.

> 
> #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.

IE10 does this today so I'm in not opposed to the idea in principle :) But 
I am very uncomfortable resolving to such a significant addition just to fix 
cross-browser placeholder styling. In other words, same as #2: overkill.

> 
> 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.
> 
I'm also happiest with #4 and #5 together with a better-named pseudo-class
for the unedited state. The problem you pointed out seems a general one. I've 
even run into the scenario Brad mentioned a couple of times and assumed I was 
doing it wrong.

Received on Wednesday, 23 January 2013 20:00:35 UTC