On 20/03/2013, at 8:18 PM, Markus Ernst wrote: > Am 20.03.2013 02:20 schrieb Kit Grose: >> In almost every case the placeholder remains visible until the user has >> begun typing, as I strongly believe it ought to be remain in the >> specification, since it provides the contextual hint for as long as possible. > Do you refer to author implementations via scripting? As in Opera and IE 10, > the placeholder gets hidden when the field is focused; thus, regarding > browser implementations, the "almost every case" refers to Firefox, Chrome, > and some versions of Safari.
As Rafał noted, I was referring to the behaviour of the application chrome itself (e.g. its built-in address bar), not its implementation of the HTML5 placeholder attribute. On 21/03/2013, at 8:54 AM, Roger Hågensen wrote: > On 2013-03-20 10:18, Markus Ernst wrote: >> The problem is that some users do not even start to type when they see text >> in the field they focused. Thus I strongly believe that some visible hint at >> the _focusing_ moment would be helpful for these users. If the Opera and IE >> behaviour of totally hiding the placeholder is considered as suboptimal, the >> placeholder could be blurred, made semi-transparent or whatever; but I am >> sure that something should happen when the control gets focus, and not only >> when the user starts typing. > > Have it dim/vanish at not just onfocus but onmouseover as well? (and TAB, but > that should be the same as onfocus usually) > I agree that this would be beneficial. > > Here is an example: (go to http://htmledit.squarefree.com/ or someplace > similar or save it locally as .html and test it that way) …snip… > So maybe a placeholder opacity of 0.5 on hover, and opacity of 0.0 on focus > would be a suitable browser default. (web authors should still be able to > style the behavior like I just did) This behaviour still makes it effectively impossible to use placeholders in combination with autofocus, which I think is unnecessary. On 20/03/2013, at 8:18 PM, Markus Ernst wrote: > The current implementations of Firefox and Chrome seem to imply selectable > content at least to some users, as Tim and myself reported in this thread. > Both show the placeholder in a lighter color than the input text; this does > not seem to fully solve the issue, maybe because many web designers color > text in form fields anyway. I can say I've never observed this issue myself in usability testing, but I'm not willing to outright discount the possibility that it's a real issue. Does anyone have any empirical evidence/test results that show the issue of users trying to select text is more prevalent than the issue of users forgetting what the placeholder said once it's been hidden, especially while using the HTML5 placeholder attribute? As I said previously, I predict that these issues would be sorted out simply by the widespread adoption of the placeholder attribute (and therefore the standardisation of its behaviour). Simulating placeholders has been variously done by dynamically setting the input to have the placeholder as its value—with or without dynamically styling the content differently—or by positioning an actual label element over the field. In both cases, the implementation effort required to make the field retain its placeholder but not be selectable in Javascript is higher than to simply blank the value on focus and restore it on blur if the field is left empty. As people transition to the placeholder attribute, the variation in the implementations by different page authors will be removed and UAs should be able to standardise the behaviour to match their own application UI. Here's a discussion on the usability of each option, with a few different references: http://ux.stackexchange.com/questions/21299/removing-placeholder-text-on-focus > The problem is that some users do not even start to type when they see text > in the field they focused. Thus I strongly believe that some visible hint at > the _focusing_ moment would be helpful for these users. If the Opera and IE > behaviour of totally hiding the placeholder is considered as suboptimal, the > placeholder could be blurred, made semi-transparent or whatever; but I am > sure that something should happen when the control gets focus, and not only > when the user starts typing. I'm skeptical that this is genuinely a significant issue with users, chiefly because I've never really seen any page authors feel the need to implement anything like this, and because as stated earlier Safari, Firefox and Chrome all use non-hiding placeholders in various places in their browser chrome without any sort of special treatment on focus. Surprisingly, the only example I could find of a developer doing something both on focus *and* once the user starts typing is Opera in its address bar and search field, which behaves as you describe; the placeholder text goes lighter on focus. Nevertheless, the _only_ browser I can find which actively removes its placeholder text on focus is IE 8 (in its search field). I can't believe that there needs to be a different implementation for fields in the browser's own chrome as for in-page form fields. Kit Grose User Experience + Tech Director, iQmultimedia
