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