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

RE: Styling HTML placeholder attribute

From: Arron Eicholz <Arron.Eicholz@microsoft.com>
Date: Thu, 24 Jan 2013 18:18:55 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, Brad Kemper <brad.kemper@gmail.com>
CC: Sylvain Galineau <sylvaing@microsoft.com>, Mounir Lamouri <mounir@lamouri.fr>, www-style list <www-style@w3.org>, "Lea Verou (leaverou@gmail.com)" <leaverou@gmail.com>
Message-ID: <71ae629a51db47ea98a0051eaa429fa8@BLUPR03MB602.namprd03.prod.outlook.com>
I see we are getting a little away from the issue at hand and I think I need to rope everyone back into the problem we are trying to solve.

What is the 'placeholder' pseudo? Is it a pseudo-element or a pseudo-class? This is the topic of this entire thread and we seem to be moving off into a naming and what styles apply to a pseudo that we haven't even defined what and how it works yet. We first need to identify what 'placeholder' really is and all agree on that. If we can do that then this conversation can be much easier and go a lot faster.

First order of business what is the 'placeholder'?
From an HTML point of view it is an attribute and its value is "content" for the control. However, really the value of 'placeholder' is not even content it is only visually content and not submittable "real" content. So really HTML doesn't represent this as anything real this makes it 'pseudo'. 

Let's look at this from a CSS point of view a 'placeholder' is a state of the control. (This as Sylvain pointed out is where I was getting confused.) Specifically 'placeholder' is an unedited state of a control.

So now that we determine that 'placeholder' is a state in CSS this clearly defines the 'placeholder' as a pseudo-class since pseudo-classes represents states of elements. Pseudo-elements represent parts of elements and 'placeholder' is not a "part" it is a "state".

Furthermore what properties can apply to the 'placeholder' or how we can apply them to the placeholder is not a primary issue until we figure out what 'placeholder' is and as I have already stated above it is a pseudo-class.

This now leads me to Tab's mail and where this topic has drifted from.

On Wednesday, January 23, 2013 10:32 AM 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; }".

A 'placeholder' represents a state thus is cannot be anything but a pseudo-class. So I am in favor of #1 so far...

> 2. Add nothing new, use a ::placeholder pseudo-element.  Specify that UA
> styles for placeholders are roughly "input::placeholder { opacity:
> .5; }".

A 'placeholder' as a pseudo-element doesn't make sense in this scenario. Since 'placeholder' is a "state" if we make the 'placeholder' a pseudo-element we would have to introduce a pseudo-class that represents the state of an edited or unedited control. This seems like it is a lot of extra overhead for little or no gain. Though we might want to explore renaming the 'placeholder' pseudo in the future that is a different discussion.

If we have a pseudo-element some things don't function properly. For instance what if I have a rule like the following?

input::placeholder { border: 3px solid red; }

This would place a border around the pseudo-element that we created within the input control and when I typed in the control I would still have my red border because the border is outside of the content box where I am placing my value. You could argue that we could to "magic" here and also have the border disappear but why not follow the rules we already have defined in CSS and not have browsers do "magic" to make things work correctly. 

I am not in favor of this option so moving on to the next.

> 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; }".

This I think is a really weak argument. The '::value'  pseudo-element is a section of the control where the value goes and that makes '::value' a pseudo-element. This argument doesn't change the fact that 'placeholder' is a "state" of the control.

> 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; }".

Personally I like the idea of adding a 'color-opacity' or something similar to allow for opacity control specifically on text. Though I think this is a separate discussion because we are talking about what 'placeholder' is and not talking about styling of a state of a control. Again styling of a 'part' or 'state' of a control is a separate issue. We still may need to address this issue once we determine what placeholder but they are separate issues that are only linked because there are

> 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; }".

This may be overkill and I think we would have to be very caution and deliberate on what we pull over from SVG. But again this is not the real topic of this discussion the topic is what is 'placeholder'? Not what can we set on the 'placeholder'. These are two separate issues that should be addressed separately.

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

I actually agree with you here that #4 and #5 is probably the best long term solution. This means that we go with a pseudo-class for this 'placeholder' functionality since we are dealing with a state. Then we need to have a SEPARATE longer discussion on what properties we need to add to provide all the flexibility we may want in the future.

Arron Eicholz

Received on Thursday, 24 January 2013 18:21:21 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:23 UTC