W3C home > Mailing lists > Public > www-style@w3.org > March 2010

Re: Customize HTML5 forms placeholder style

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 16 Mar 2010 22:28:30 -0700
Cc: Mounir Lamouri <mounir.lamouri@gmail.com>, www-style@w3.org
Message-Id: <571114EE-5C35-4BD0-BFA3-33A3020D634A@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
I prefer your #2, because it seems simpler and easier to explain, and more intuitive. It is pretty much what I would expect to be able to select and color, independently of the input itself. It is also the way Webkit handles it (you can set the input color without setting the color of the placeholder text). It feels wrong to me that setting the text color of the input should have any effect at all on the placeholder, as I really think of it as something closer in concept to a well-placed, no-hover-needed tooltip, or as a label positioned over the top of the input that disappears when you click in the input. I do not think if it at all as input text.

As for styling the entire box based on the state of the placeholder, this doesn't seem that important to me, personally (I realize I don't speak for everyone, but I have been using placeholder for a while). If I create an input with a placeholder, I know that it is there. Then the problem becomes simply one of styling the input based on if it is empty or not, regardless of the placeholder. I suppose it might be different if I had many, many inputs on a page, some with placeholders and some without, and without styles to differentiate them. But in general, I think if a required field was left empty, I would want to style it the same as other empty required fields, regardless of placeholder.

I think the text, font, and color are obvious properties to include. But I could imagine using other properties like 'clip' or 'left' (or marquee) in order to animate the words, to call attention to the box the user is supposed to type into.

On Mar 16, 2010, at 6:59 PM, Tab Atkins Jr. wrote:

> On Sun, Mar 7, 2010 at 1:28 PM, Mounir Lamouri <mounir.lamouri@gmail.com> wrote:
>> Hi,
>> I have already opened this discussion in whatwg mailing list [1] but we
>> did not reach a consensus and I have been told to use this mailing list
>> which seems more appropriate.
>> To summarize, the placeholder attribute is now available in Gecko [2]
>> and Webkit and we are now face of the placeholder customization [3] [4]
>> [5]. Indeed, styling input or textarea can make the default placeholder
>> style inappropriate.
>> There is two ways to do that: using a pseudo-element or a pseudo-class.
>> If it is a pseudo-element, the properties that will applied have to be
>> limited probably like the :first-line pseudo-element.
>> The pros and cons related to both ways are detailed in the discussion in
>> whatwg mailing list. I would like to know your opinion and maybe get a
>> consensus and write a specification before implementing something in Gecko.
>> [1]
>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/thread.html#25190
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=457800
>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=457801
>> [4] https://bugs.webkit.org/show_bug.cgi?id=21227
>> [5] https://bugs.webkit.org/show_bug.cgi?id=21299
> So that people don't have to go diving into other lists and bugs, let
> me summarize the issues:
> First, we may want to be able to style the placeholder.  This is
> mainly so that, when we're styling the input, the placeholder doesn't
> accidentally become unreadable.  (Frex, if the input's background was
> changed to a light gray, that would make it unreadable with the
> current placeholder styling, which is light gray text.)
> Second, we may want to be able to style the input based on whether
> it's in the placeholder state.  For example, we may want to put a
> special border on inputs that are showing a placeholder, to draw extra
> attention to them.  This can *almost* be done with existing selectors:
> "input[placeholder]:not(:focus)".  That does not capture the fact that
> the input is empty of text, though, which is the final requirement for
> the placeholder state.  It's also pretty complex, so even if there was
> a pseudoclass for no-content inputs, it would be an extremely unwieldy
> selector that the average author can't be expected to write.
> There are two suggested ways to address one or both of these.
> 1) A :placeholder pseudoclass, which matches an input that has the
> placeholder attribute, is currently empty of text, and which is not
> currently focused.
> 2) A ::placeholder pseudoelement, which represents the placeholder
> text itself.  This pseudoelement only exists when the input is in the
> placeholder state.
> #1 addresses both requirements.  However, it has a problem with
> cascading.  If an author only sets the color on the input, the
> placeholder will automatically be that color, rather than light gray.
> The author has to set a color on both "input" and "input:placeholder"
> to get it to work as expected.  This won't break any pages (that
> aren't already broken by bad color choices for input text), but it is
> slightly suboptimal.  I'm not sure how many existing pages use
> @placeholder and set a text color on inputs (probably very few), but
> this would be a change in behavior for them.
> #2 only addresses the first requirement, but it does not have the
> cascading issue that #1 does.  However, it requires us to define what
> properties can be applied to ::placeholder.  These would be equivalent
> to the properties that can be applied to ::value (defined in CSS3 UI),
> but these are not defined yet either.
> ~TJ

Received on Wednesday, 17 March 2010 05:29:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:43 UTC