Re: Styling HTML placeholder attribute

Obviously it would be terribly confusing, but has the option of both
pseudo-class and pseudo-element been discussed?

`input:placeholder` would be used to describe an input element whose
placeholder is visible and `input::placeholder` would be used to style the
placeholder.

The spec specifically defines placeholders as only existing when there is
no text in the input, but in my mind I've always wanted placeholders to
double as type-ahead hint text as well.

If something like this were ever allowed in the future (input text and
placeholder text being shown at the same time) then the color property of
`input:placeholder` clearly couldn't apply to the placeholder text. It
seems like using the color property to refer to both is limiting.



On Thu, Jan 24, 2013 at 11:51 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Jan 24, 2013 at 11:42 AM, Brad Kemper <brad.kemper@gmail.com>
> wrote:
> > On Jan 24, 2013, at 10:32 AM, "Tab Atkins Jr." <jackalmage@gmail.com>
> wrote:
> >> Arguments from theoretical purity are interesting and all, but that's
> >> the lowest level in the hierarchy of constituents.  The most important
> >> thing is to figure out what kind of styling would produce the desired
> >> effect for placeholder text, and then we reason backwards from there
> >> to figure out what kind of properties and/or selectors we need to
> >> achieve that effect in the best manner.
> >
> > I disagree. Its not just a matter of purity. If there is an
> easy-to-understand way to describe the desired effect without a logically
> surprising distortion of what we already defined as the difference between
> pseudo-element and pseudo-class, then that should be the clear winner over
> something unjustifiably assumes a cross-UA internal structure of a form
> element in order to twist it into something that 'opacity' works well with.
> Especially when said twisting also reduces styling choices for the form
> element (styling borders based on the placeholder state), and when doing it
> another way increases styling opportunities in other situations (changing a
> color's alpha in any element without simultaneously having to set the other
> color components).
> >
> > If we need to define how something that is clearly a pseudo-class works
> in order to allow better author styling, then we shouldn't limit ourselves
> to not creating new properties or color values to do it.
>
> Given that I'm arguing specifically *for* creating new properties (or
> rather, pulling in SVG-specific properties to general CSS), I think
> your argument is misplaced. ^_^
>
> I'm arguing against Arron and Sylvain's assertions that we should
> decide, from a theoretical perspective, whether to address placeholder
> styling with a pseudoclass or pseudo-element, and then after making
> that decision, decide on the styling.
>
> Theoretical purity arguments certainly have a place, but they're just
> much less important than other concerns.  We should feel free to bring
> them up as support for an option that has other good reasons for
> existing, but it shouldn't be used as an early filter to rule out
> potential solutions.
>
> ~TJ
>
>