GNOME Bugzilla – Bug 752622
Placeholder text should always be shown when the entry is empty even if it's not focused
Last modified: 2015-07-20 11:05:17 UTC
That's the behaviour of all browsers in all platforms. It's not only a matter of consistency with the web, not showing the placeholder text on focused entries has also some problems. For example, when you open a dialog and the first entry is focused, you see the placeholder text in all entries except the current one, and you don't know what you are supposed to enter there, unless you move the focus to a different entry. That's even worse if there's only one entry in the dialog. I implemented it this way for consistency with WebKitGTK+, but we are going to change that in WebKitGTK+ too, see https://bugs.webkit.org/show_bug.cgi?id=147104
Created attachment 307743 [details] [review] gtkentry: Show placeholder text even when the entry is currently focused
(In reply to Carlos Garcia Campos from comment #0) > That's the behaviour of all browsers in all platforms. That's not entirely true — it depends on the entry (ain't the Web great?). The search entry in Chrome's new tab page shows the "Search Google or type URL" hint until the entry is focused — then it'll remove it. Twitter's entry will also show the hint "What's happening?" until focused (though that also resizes the entry). Facebook's "Find Friends" entry, on the other hand, will show the hint even when focused — but it also shows a drop-down for quick actions, so it's less of an entry and more of a combo box. The same happens with Google Plus, where "Search for people, pages or post" remains as the hint even when focused (plus it does not use the Oxford Comma, and it makes me twitch). The "Share what's new" hint also stays, but it *does* change the color to a more subtle hue on key focus. So it seems to me that there isn't a real consensus on whether the hint should stay when focused or not.
I was talking about the default, I think in the case of the web it can be changed with CSS. See https://lists.webkit.org/pipermail/webkit-dev/2013-August/025305.html
The W3C spec for the 'placeholder' attribute is not the best I've ever read: http://www.w3.org/TR/html51/semantics.html#the-placeholder-attribute """ User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string, especially if the control is not focused. """ What does "especially" mean in this case, it's unknown. It seems it's an escape hatch for platform specific behaviour, considering the following paragraph: """ If a user agent normally doesn't show this hint to the user when the control is focused, then the user agent should nonetheless show the hint for the control if it was focused as a result of the autofocus attribute, since in that case the user will not have had an opportunity to examine the control before focusing it. """ Which I guess it's the whole point of the exercise: show the placeholder hint on focus if the focus operation is the result of a programmatic grab_focus(), but hide it if the user explicitly focused the entry with the pointer or with the keyboard.
I guess this is really a duplicate of bug 667502, which was opened by Mozilla devs after they changed their own input entries to match with the spec and other platforms. *** This bug has been marked as a duplicate of bug 667502 ***
(In reply to Emmanuele Bassi (:ebassi) from comment #5) > I guess this is really a duplicate of bug 667502, which was opened by > Mozilla devs after they changed their own input entries to match with the > spec and other platforms. > > *** This bug has been marked as a duplicate of bug 667502 *** Right! and jjardon's patch there is better than mine, since I forgot to update the docs :-P