Удаление текста заполнителя в фокусе

  • Chrome, Safari и Firefox 15+ удаляют текст заполнителя после первого нажатия кнопки «пользователи» в поле ввода текста.
  • Opera, IE и Firefox 14 и ниже удаляют текст заполнителя сразу после фокусировки ввода текста.

Какой подход лучше для пользователей и почему?

Заполните тег в своем браузере jsfiddle .

Обновление: Заполнители в полях формы вредны

95 голосов | спросил webvitaly 14 Maypm12 2012, 18:41:12

12 ответов


97

Интересно, что w3 Spec for placeholder допускает любое поведение:

  

Пользовательские агенты должны представить эту подсказку пользователю после того, как разделили на нем разрывы строк, когда значение элемента является пустой строкой и /или элемент управления не сфокусирован (например, отображая его внутри пустого несфокусированного элемента управления и скрывая его в противном случае).

Но, функционально говоря, нет причин для его устранения, прежде чем пользователь начнет печатать. Пользователи, перемещающиеся по вашей форме, никогда не смогут увидеть это, потому что они будут вставлять вкладку в поле перед тем, как увидеть текст заполнителя. Пользователи мыши, возможно, не закончили читать текст заполнителя перед тем, как щелкнуть.

Если ваше поле достаточно сложно, чтобы потребовать местозаполнитель, это, вероятно, требует некоторой мысли; какое лучшее время подумать «что мне вводить?» чем когда вы сосредоточены на поле? Зачем убирать этот намек от пользователей, сфокусированных в поле, но путайте, что набирать?

ответил Ben Brocka 14 Maypm12 2012, 19:11:47
44

Я был бы сторонником того, чтобы текст заполнителя был как можно дольше, не мешая.

Как это делается в Chrome, лучше, на мой взгляд.

Однако я нашел способы обойти это во всех браузерах.

То, что я делал в прошлом, это удалить текст заполнителя в фокусе, но также повторно отобразить этот текст, сделав ярлык, который почти всегда является дубликатом заполнителя и, если нет, по крайней мере, как или более описательный - отображается как вкладка.

Например, вот часть моей формы без полей в фокусе:

введите описание изображения здесь

И вот часть моей формы с фокусом в поле:

введите описание изображения здесь>> </p>

<p> Таким образом, пользователь никогда не смешивается с тем, что именно они ввели в поле. Они могут проверять путем повторной фокусировки на поле. </p></div>
										<div class=ответил magzalez 14 Maypm12 2012, 19:46:02

14

Удалять его при начале ввода

В зависимости от того, как фокус был перемещен в поле ввода, пользователь может не обязательно видеть текст заполнителя, прежде чем он быстро исчезнет.

Да, вы можете прочитать его перед тем, как вы вручную щелкните в поле, но, возможно, нет, если вы столкнулись с вкладкой в поле с предыдущего ввода.

Также существует вероятность того, что первое поле ввода получает фокус по умолчанию при отображении страницы, и в этом случае местозаполнитель будет по-прежнему хорошо видеть.

ответил Roger Attrill 14 Maypm12 2012, 19:08:45
9

изменить , чтобы сохранить текст заполнителя в фокусе в недавнем Firefox 15 релиз смутил меня в первый раз, когда я это увидел. Я действительно думал, что поле отключено. В Firefox стиль по умолчанию (цвет текста) для замещающего и отключенного очень похож, и, в отличие от Chrome, подсветка фокуса по умолчанию отсутствует, поэтому основным признаком того, что поле доступно для редактирования, является курсор, который можно легко пропустить , Если вы не можете выделить или удалить текст, который находится на вашем пути, ваш первый инстинкт, если вы незнакомы с соглашением пользовательского интерфейса, не обязательно должен начинать вводить текст в любом случае.

Несмотря на наличие хороших практических аргументов в пользу сохранения текста в фокусе, существует также множество прецедентов (по крайней мере, в Windows) для противоположного поведения. Один комментатор указал, что окно поиска в меню запуска Windows работает таким образом, и сам Firefox имеет несколько полей пользовательского интерфейса, которые очищаются от фокуса. Начальное меню Windows на самом деле является примером гибридного подхода. Его окно поиска первоначально сфокусировано и отображает текст по умолчанию, но когда пользователь вручную фокусирует его, текст очищается. Я предпочитаю такой компромисс с точки зрения удобства использования.

Однако в среде HTML чистое сопоставление с CSS (если только для override hacks ) также не существует, и нет селектора для автоматической фокусировки и пользовательского фокуса. И на данный момент все поставщики браузеров, похоже, находятся в редком согласии, поэтому немного опасаться. Возможно, более простой компромисс в Firefox заключался бы в добавлении стиля фокуса по умолчанию для текста заполнителя, который больше терял текст заполнителя, поэтому у пользователя была более сильная обратная связь, что поле могло бы принять их печатание, даже несмотря на то, что на этом был еще текст-заполнитель.

Отмечая проблемы, связанные с реализацией в конкретном браузере, мое предпочтение в целом остается скрыть от фокуса. Хотя большая его часть заключается в том, что это то, к чему я привык, я думаю, что существует также фундаментальное отвращение к тому, чтобы писать в пространстве, которое еще не было пустым. Опыт написания рукописного ввода, ввода (с помощью пишущей машинки!) И вычислений научил меня, что если там уже есть текст, мне сначала нужно что-то сделать. Я инстинктивно предпочитаю пустой холст, прежде чем начать. Я могу приспособиться к сохранению на фокусе, но я думаю, что будет трудно чувствовать себя полностью комфортно с ним, если не будет больше смысла в том, что текст заполнителя убирается с пути, когда я фокусирую поле для редактирования.

ответил Nathan Williams 2 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 02 Sep 2012 02:11:14 +0400 2012, 02:11:14
7

Увидев, что кто-то пытается выделить какой-то текст-заполнитель в течение нескольких минут, чтобы она могла удалить его и начать печатать, я бы сказал, что удаление по фокусу было бы самым удобным для всех диапазонов пользователей.

Я думаю, что цвет текста заполнителя здесь имеет значение, поскольку он был того же цвета, что и входной текст, может быть, светло-серый или что-то подобное не путало бы этого конкретного пользователя.

ответил GP89 14 Maypm12 2012, 22:17:22
7

Пользовательский сценарий:

  1. Пользователь начинает заполнять форму из 6 полей (все заполненные заполнители)
  2. Пользователь видит заполнители каждый раз перед заполнением поля и понимает, что нужно заполнить.
  3. Пользователь нажимает на поле, и фокус делает заполнитель исчезают.
  4. Прежде чем пользователь сможет начать заполнять поле, пользователь получает сообщение или почту и отвлекается на несколько секунд.

Теперь, когда пользователь возвращается, чтобы заполнить это поле, которое находится в фокусе и без заполнителя. Есть очень высокие шансы, что пользователь забыл, что он увидел в заполнителе, и может что-то ввести в свои предположения.

  

Следовательно,    Удаление, когда вы начинаете печатать, нехорошо.

ответил Pratheep ch 14 Maypm12 2012, 19:22:59
7

Мы проверили это недавно в пользовательском тесте, и он ясно показал, что поле должно быть пустым после того, как пользователь щелкнул его. Если текст остается там, они думали, что не могут изменить это поле и даже не попытались ввести текст.

Другое дело: я помню, как консультант UX из Nielsen Norman сообщил, что если пользователи видят пустое поле, они, как правило, что-то пишут в нем. Таким образом, не имея заполнителей может увеличить конверсию. : -)

ответил Steffen Kastner 18 TueEurope/Moscow2012-12-18T11:32:03+04:00Europe/Moscow12bEurope/MoscowTue, 18 Dec 2012 11:32:03 +0400 2012, 11:32:03
6
  

Какой подход лучше для пользователей и почему?

Лучшим подходом является подход по умолчанию. Пользователь выбрал браузер и используется для того, как браузер делает то, что он делает. Не связывайтесь со значениями по умолчанию.

ответил DA01 14 Maypm12 2012, 20:57:32
5

Чтение ответа GP89, увидевшего, что пользователи пытаются выделить или даже удалить текст заполнителя, как представляется, настоятельно предлагает удалить текст с замещающим текстом в фокусе.

Также текст-заполнитель ДОЛЖЕН использоваться как незначительная помощь.

Проблема, кажется, заключается в том, что люди используют ее как замену для ярлыков, которые явно заполнитель не является. Любая форма, которая может быть повторно заполнена фактическим содержимым, которое затем, разумеется, заменяет местозаполнитель, неприменимо без ярлыков. Даже простая форма входа (пользователь + пароль) может быть предварительно заполнена, если, например, сообщение подтверждения будет показано после отправки (возможно, неизвестный пароль, и да, я знаю, а не рекомендованный способ сделать это, но лучший пример, о котором я мог только сейчас подумать). Приведенные выше примеры, похоже, используют именно это ложное использование ...: (

ответил Chris 14 Maypm12 2012, 23:17:02
3

Лучший подход - избегать использования текста-заполнителя вообще. Существует много доказательств того, что многие, многие пользователи не поймут, что это местозаполнитель (см. Вышеприведенный ответ) и запутаются. Это плохая модель и совершенно не нужна.

ответил David More 5 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 05 Sep 2012 05:23:04 +0400 2012, 05:23:04
2

Хром лучше, в общем. Однако это также зависит от контекста. Это времена, когда текст-заполнитель может быть настолько важным, что желательно, чтобы пользователь вручную удалял сам текст (крайний регистр).

Правильное использование меток должно помочь пользователю и предотвратить зависимость значений по умолчанию от полей.

ответил timworks 14 Maypm12 2012, 20:01:41
2

Большинство ответов здесь касаются форм с несколькими входами. Конечно, есть некоторые сценарии (с использованием ввода для поля поиска), где на странице будет только один вход.

В этом случае я считаю, что было бы лучше удалить местозаполнитель в фокусе. Пользователь знает, что там было, и оставляя его на месте, может смутить их.

ответил Kevin Hanes 3 PMpWed, 03 Apr 2013 21:51:42 +040051Wednesday 2013, 21:51:42

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132