- From: Sylvain Galineau <galineau@adobe.com>
- Date: Fri, 3 May 2013 15:21:59 -0700
- To: "www-style@w3.org" <www-style@w3.org>
- CC: fantasai <fantasai@inkedblade.net>
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.
Received on Friday, 3 May 2013 22:22:45 UTC