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

Re: [css4-ui] ::placeholder and :placeholder feedback

From: Sylvain Galineau <galineau@adobe.com>
Date: Mon, 6 May 2013 10:42:48 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
Message-ID: <CDAD3849.3A7A%galineau@adobe.com>


On 5/6/13 10:14 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Fri, May 3, 2013 at 3:21 PM, Sylvain Galineau <galineau@adobe.com>
>wrote:
>> Arron, Elika and were discussing this topic at TTWF Seattle almost a
>>month
>> ago; Elika asked me to resend some feedback that may have been lost in
>>the
>> shuffle back in our February discussions. My bad for taking so long.
>>
>> Back in my previous gig a ::placeholder element initially made a lot of
>> sense to some of us. We thought it generated more issues than benefits
>> though.
>>
>> The main one being that as people start styling their control layout to
>> position/size the ::value pseudo they will quickly learn that
>> ::placeholder does not magically follow its sibling. While it's easy to
>> figure out and fix both items are expected to share a number of
>>properties
>> most of the time. So every time authors want to style more than colors
>> they may have to write an extra rule to declare those things they need
>> ::value and ::placeholder to have in common. I can't claim we were a
>> representative sample but there seemed to be a strong expectation that
>> ::value and ::placeholder are, by default, two faces of the same coin.
>> Which suggested we were really dealing with a state.
>>
>> Having two pseudo-elements makes it also possible to step out of the
>> placeholder use-case entirely e.g. lay out placeholder and value side by
>> side to use the former for other purposes such as a small graphical
>>prompt
>> or any other odd bits we may not think of today. I have no strong
>>opinion
>> as to whether this is good or bad but custom scenarios like these (or
>> enabling interesting fades) may come with other interesting requirements
>> that are best addressed with Shadow DOM.
>>
>> (The previous paragraph assumes the implementation's default stylesheet
>> uses the :placeholder pseudo-class to show/hide ::placeholder, thus
>> allowing authors to override these defaults; I think that is a
>>reasonable
>> expectation for authors to have).
>>
>> Yes, setting opacity on the placeholder text is easier with
>>::placeholder.
>> As such, it is a cheaper solution to spec and implement than improving
>> opacity; but I'm not sure authors will be better off with the result. Or
>> implementors, who will have to maintain this slightly awkward setup for
>> many years to come.
>
>The ::value pseudo-element doesn't meaningfully exist, though.  If
>we'd *like* it to exist, then we can talk about its interaction with
>::placeholder, and whether ::value+:placeholder-shown is a sufficient
>replacement for ::placeholder.

I have no idea what 'meaningful existence'…means; ::value remains
defined in css3-ui [1] (though at risk). I do not see any language that
suggests it will be removed vs. moved up to level 4.

This feedback thus applies until this is clarified.

[1] http://dev.w3.org/csswg/css-ui/#pseudo-elements


Received on Monday, 6 May 2013 17:44:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC