[whatwg] Customize HTML5 forms placeholder style

On Thu, Feb 18, 2010 at 4:40 PM, L. David Baron <dbaron at dbaron.org> wrote:
> On Thursday 2010-02-18 16:21 -0600, Tab Atkins Jr. wrote:
>> Ah, got it.
>>
>> That doesn't seem like a horrible problem to me. ?Most people don't
>> set color on inputs, and when they do, it's at least guaranteed that
>> the color is *usable* for placeholder, even if it's not ideal. ?They
>> can just set color on the placeholder directly if they care, though.
>>
>> (My windows theme is green-on-black, so I am very aware when people
>> *do* style their inputs. ?Setting color:black without a
>> background-color:white is distressingly common, but overall most
>> inputs are unstyled in my experience.)
>>
>> I don't personally feel this is important enough of an issue to
>> justify specificity trickery.
>
> I think the question is whether, given author style for the input's
> text but no specific style for the placeholder, you're better off
> falling back to the default style for the placeholder or to the
> author style for the input. ?It's not obvious to me which is the
> right answer.
>
> Falling back to the author style for the input (what you'd get with
> a pseudo-class) has the advantage of being more likely to produce
> legible text (assuming the author styled the input properly). ?This
> case may matter for cases where the markup and style are coming from
> different sources.
>
> Falling back to the default color for the placeholder text (what
> you'd get with a pseudo-element) has the advantage that the
> placeholder text is more likely to be distinguishable from
> non-placeholder text. ?However, there's no guarantee of that, nor is
> there any guarantee that it's legible or visible at all. ?(However,
> having no placeholder text show up at all is already the
> old-browsers failure mode of the placeholder attribute, right?)
>
> I'd be inclined towards the pseudo-class, though, partly since that
> failure mode bothers me less, and partly since it's a lot simpler
> (maybe not to implement in one engine, but probably to implement
> interoperably and to specify, since you need to be careful about
> what applies and doesn't apply to the pseudo-element).

Anne suggested in IRC using the pseudoclass approach, and pairing it
with the ::value pseudoelem from the Basic UI Module.  You could get
whichever behavior you wanted then, and theoretically lean on an
existing definition to decide what properties should apply. (Actually,
the Basic UI module says nothing about what properties are
appropriate, but this could be a decent opportunity to finally clean
up that definition.  Tantek's said he plans to revive the draft
soon...)

~TJ

Received on Thursday, 18 February 2010 14:45:12 UTC