Эпиграф
Здравствуйте дорогие читатели, жаль что почти полгода не писала никаких статей, а эту статью нужно было написать год назад, я всё не знала как за неё сесть. Наверное статья так бы никогда и не увидела свет, если бы мой друг и коллега mr.troll, не написал её за меня.Тема для меня является одной из самых важных. Речь пойдёт о текстовых полях ввода, а вы знаете как трепетно я отношусь к всевозможным формам, например: «Мастерство авторизации», «Основные ошибки проектирования процесса авторизации», «Пользователь важен для вас? Просто дайте ему зарегистрироваться», «Комментарии open_id». Статью можно считать гостевым постом, поскольку я давно приглашаю кого-нибудь написать свою статью в моём блоге. Надеюсь вам понравится. Итак, слово автору.
ваша Moony.
История проблемы
У всех движков есть свои баги, и некоторые баги глубоко печалят меня, я не могу спать и худею.
Здравствуйте читатели милого блога Usabili.ru,
Вы наверное знаете а таком атрибуте тега <input> как placeholder. Это такая небольшая подсказочка к текстовому полю ввода (включая пароли и textarea), которая отображается там до тех пор, пока пользователь не активировал этот input. Такую же штуку, но по старинке на яваскриптах и label'ах ребята из Яндекса делают в своих интерфейсах, например yandex.ru, http://mail.yandex.com/ и т.п. Сейчас у двух браузеров: Оперы (пока не перешла на вебкит) и IE (9-10) абсолютно правильная реализация данного атрибута, т.е. текст подсказки необходимо сразу прятать, как только пользователь передал фокус в поле ввода (кликнул на него например). Так вот, нынешняя тенденция поведения браузеров — не является удобным для пользователя, уже почти год вебкит не убирает текстовую подсказку по клику, т.е она убирается только тогда когда пользователь начал печатать текст. Я считаю что это поведение смущает пользователя, поскольку естественным является печать в поле в котором нет текста. Печать в поле в котором текст уже есть, и который не удаляется (через delete или backspace) — очень негативно сказывается на UX.
Данное поведение вебкита — изначально противоречило спецификации, однако из-за него Хикси (Ян Хигсон, единоличный и ответственный редактор html5) разрешил оба варианта — см http://lists.w3.org/Archives/Public/public-html-diffs/2011Oct/0174.html . Я связывался с ним по поводу его решения, увы он сказал что спецификация лишь отражает поведение браузеров, и это все вопросы юзабилити должны решать вендоры браузеров. Правильное поведение сейчас есть у Оперы (Presto) и MSIE 9 и даже в новом IE10.
Не правильное поведение сейчас у Хрома (и многих вебкитовых браузеров) и Файрфокса, который так же не предупреждая изменил его в 16й версии.
Плюсы и минусы нового поведения placeholder
- Пользователь не может отличить placeholder и предустановленное value. Цвет placeholder - наследуется напрямую от input. Поэтому если вы изменили цвет текста для input цвет value и placeholder будут одинаковый. По умолчанию в некоторых браузерах placeholder светлее, однако нельзя сделать его всегда светлее, ибо при другом цвете фона лучше использовать тот цвет который задал пользователь для input.
- Пользователь не уверен, кликнул ли он в поле ввода. Что особенно трудно сказать на тач-устройствах.
- Пользователь может попытаться удалить текст в поле ввода - и это не получится ни клавишу delete ни через backspace
+ Пользователь знает какой плейсхолдер используется в поле ввода, даже кликнув на него (но перед тем как начать печатать). На мой взгляд это сомнительный плюс, только если у пользователя после клика наступил склероз и он реально забыл что же было в поле ввода. Хотя многие видные люди не хотят ориентироваться на "достаточно умных" пользователей, я полагаю что распространённым поведением пользователя - является смотреть куда он тыкает мышкой. Для пользователей которые не смотрят куда они тыкают - априори не возможно сделать качественный интерфейс.
+ Пользователь знает какой плейсхолдер используется, если поле ввода имеет автофокус (пример mail.yandex.com ). Это тоже очень сомнительный плюс. Поскольку по правилам юзабилити - плейсхолдер конечно должен использоваться для описания поле ввода, но не должен использоваться как единственное описание. Так же в случае со связкой логин/пароль - автофокус на поле логина (скрывающий подсказку что первое поле логин) - может быть очевидным для пользователей которые привыкли что на сайтах авторизация через поля логин/пароль, а так же абсолютно очевидна для пользователей которые уже использовали эту форму входа. Вообще автофокус - это единственный и редкий случай где не скрывание текста подсказки хоть как-то оправдано.
Подробнее
О том почему критически важно чтобы подсказка убиралась по клику, а не при вводе текста я подробно писал в трекере мозиллы https://bugzilla.mozilla.org/show_bug.cgi?id=673873#c57 — тут несколько моих комментариев, ну и https://bugzilla.mozilla.org/show_bug.cgi?id=758996 тоже можно глянуть. Если кратко, основная проблема такая: Когда пользователь кликает на поле ввода и placeholder пропадает, он думает: "О. Тут был placeholder". Когда пользователь кликает на поле и placeholder остаётся видимым, он думает: "Что это? Это placeholder или value? Могу ли я печатать текст или сначала нужно удалить то что в поле ввода?". и т.п. Пока я добился от мозиллы настройки dom.placeholder.show_on_focus однако это лишь частичное решение. Как вебмастер мне приходится использовать такую конструкцию:
input:focus:-moz-placeholder {color:transparent;}
input:focus::-webkit-input-placeholder {color:transparent;}
input:-moz-placeholder {font-style:italic;color:#ccc;}
input::-webkit-input-placeholder {font-style:italic;color:#ccc;}
/* Замечу — свойства вебкита и мозиллы не группируются между собой! */
А в будущем вместо псевдокласса :-moz-placeholder (для старых версий фф) нужно будет писать ещё и псевдоэлемент ::-moz-placeholder. и т.п.
Далее небольшой перевод моих комментариев из багзиллы фф:
Hixie изменил "И" на "И/ИЛИ", и браузер-вендоры стали бездумно реализовывать такое поведение. Разве так можно? часть "И" никто не отменял.
По мне, так у нового поведения серьезная проблема с UX. Быть такого не может, чтобы кому-либо было удобно начинать печатать в поле, уже содержащем текст! Разве я могу предвидеть, что текст магическим образом исчезнет, стоит начать печатать? Замещаемый текст нельзя удалить ни клавишей Delete, ни сочетанием Ctrl+A, Backspace. От него вообще нельзя избавить никоим образом, кроме как начать печатать.
Хотите пример поля с текстом в фокусе, который замещается при начале ввода? Это mcedit (linux Midnight Commander). При открытии поискового диалога, в поле запроса уже находится последнее использованное ключевое слово. И если начнете вводить в это поле текст, это слово поведет себя, как замещающийся текст. Но если не начнете, — оно произведет поиск по ключевому слову, а не по пустой строке! Поэтому это не placeholder - это предопределённое значение (predefined value).
Хотите ещё? Далеко ходить не надо, в Windows просто нажмите Win+R, и вы получите диалоговое окно Run, в котором отображена последняя выбранная в нем команда – если вы начнете печатать, она, ясное дело, удалится, потому что это был выделенный текст, но если не начнете печатать – выполнена будет последняя команда.
Как пользователю различить, то ли это замещаемый текст, то ли предопределённое значение? Единственный метод – поставить курсор!
Таким образом, разве может пользователь при работе с браузером ожидать, что поле, которое ведет себя как с предопределенным значением при установке курсора, будет обработана как пустая строка? Раньше всё было просто: если после установки курсора строка становится пустой – то в форму отправится пустая строка.
Вы когда-нибудь опробовали это поведение на мобильных устройствах, таких, как небольшие устройства на Android, в которых с трудом различим текстовый курсор? Там вы не сможете быть уверенными, что попадете, куда хотите.
По мне, так вы сломали всю функциональность замещаемого текста. Единственный способ – имитировать его java-скриптом, как мы делали лет десять назад. И как http://mail.yandex.com/ делает ныне.
И ради чего? Ради пользователей, которые могут забыть замещаемый текст сразу после того, как кликнули на поле для ввода? Так, что ли?
Сайт, над которым я сейчас работаю включает светло-серый цвет вводимого текста (#a0a4ad), и если вы сможете выбрать цвет, вы увидете, что замещаемый текст, в моем случае, использует цвет вводимого текста. И при наведении фокуса ничего не изменяется (кроме текстового курсора), вот в чем соль.
Если у поля ввода с замещаемым текстом есть автофокус – замечательно. Если нет – веб-мастеру следует поместить пометку вне поля ввода. Опять же смотрите http://mail.yandex.com/, там автофокус на поле ввода. Если пользователь недостаточно сообразителен, чтобы понять, что это поле для логина, он уберет курсор и прочитает, и в следующий раз уже будет в курсе, для чего это поле. Но текст в поле с курсором будет напрягать его при каждом посещении! И ничего с этим не поделать. Почему бы не показывать замещаемый текст только для автоматически наводящегося курсора, раз уж так необходимо?
Примените следующий код и попытайтесь ввести значение поля:
<form><input type="text" required placeholder="Something"></form>
Это может заставить понервничать даже меня! Оно заявляет мне, что поле пусто – но, эй! – в нем установлен курсор и, я могу поклясться Мозилле, что вижу в нем текст!
Почему не делают никаких UX ревью? Старое доброе правило юзабилити гласит: «Когда достаточно места, и метка для поля ввода важна – используй <label> вне поля ввода вместо placeholder; используй <label>, когда много полей для ввода. Но если есть только одиночная форма поиска, или пара полей логин/пароль, или что-либо столь же очевидное для пользователя – можешь использовать замещаемый текст.» Таким образом, я полагаю, что атрибут замещаемого текста используется только в том случае, если пользователь может догадаться о его содержании (ie8 вообще не способен его отображать). Получается, программисты мозиллы считают, что замещаемый текст всегда настолько важен, что должен пользователь должен видеть его даже после клика?! Я не верю, что пользователь может забыть его сразу после клика.
Вот мой основной вопрос: если у вас есть работающий код, зачем его менять? Если у вас есть код, работающий ХОРОШО и всех устраивающий, то зачем его менять?
Может кто-нибудь будет любезен и выскажет личное недовольство старым поведением? И тем самым дать мне причину?
Славно, что этот баг не будет подтвержден в Gnome по причинам, которые я описал выше.
https://bugzilla.gnome.org/show_bug.cgi?id=667502 - Хорошо для Gnome.
Пользователя гораздо больше смущает ситуация, когда он попал курсором в поле и больше не видит подсказки, которая была в поле. Когда он увидит её, прочтёт и поймёт, что писать — она изсчезнет. Это поведение, к примеру, идёт сквозь все интерфейсы системы Mac OS X.
Я считаю это очень правильным решением. Это не баг, это хорошая идея.
Если вы с этим не согласны, вы вольны сделать тот самый фикс в CSS ваших проектов. Но на мой взгляд, вы только запутаете его. А пока обратите на плейсхолдер в адресном и поисковом полях интерфейса Оперы — подсказки в них не исчезают при установке курсора.
Пруф того что в IE10 плейсхолдер специально убирается по клику можно посмотреть тут:
везде пишут "Placeholder text is visible until focus is placed in the element." и т.п.
А вот список связанных багов в FF:
P.S. Moony: Статья была написана вообще-то полгода назад. Но перечитать несколько раз и выложить её руки дошли только сегодня. Сорри. Надеюсь вам интересна проблема с placeholder.
Под катом вы можете также посмотреть переписку с Хикси:
