Input — User agent stylesheet в поле ввода Поиск


Содержание

Форум

Справочник

Поиск по форуму
Расширенный поиск
К странице.
Страница 1 из 2 1 2 >
Нужно проверять именно DOMControlValueChange и его аналоги.

совсем не обязательно, можно еще по таймеру проверять содержимое value Сообщение от subzey Нужно проверять именно DOMControlValueChange и его аналоги.

И какие у него аналоги?!

  • DOMControlValueChanged — опера
  • input — XUL (гекконы)
  • propertychange (где property=»value») — ослик
  • DOMCharacterDataModified, DOMSubtreeModified — вебкит

Все это расписано в статье по ссылке выше.

Здравствуйте! Есть код:

Во всех браузерах прекрасно работает эта функция:

А вот такая функция не работает в FireFox3 (значение при вводе не меняется):

Где ошибка?? (Необходимо ограничить ввод иных символов кроме цифр на основной клаве и цифровой, Backspase и Delete)
Спасибо!

Поле ввода поискового запроса

Компонент служит для вывода поля ввода поискового запроса с подсказкой. Компонент стандартный и входит в дистрибутив модуля.

Компонент относится к модулю Поиск.

Описание параметров

Поле Параметр Описание
Основные параметры
Имя поля ввода NAME Указывается имя поля ввода.
Содержимое поля ввода VALUE Указывается текст, который будет отображаться в поле ввода по умолчанию.
Размер поля ввода INPUT_SIZE Задается ширина поля ввода в символах.
Размер выпадающего списка DROPDOWN_SIZE Задается количество пунктов, отображаемых в выпадающем списке.

Пользовательские комментарии

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

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

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

Работа с input: подборка полезных решений на HTML и CSS

В рамках работы над полями ввода (input) существуют не всегда очевидные и, как правило, редко используемые CSS-приёмы и HTML-атрибуты, позволяющие без использования JavaScript преобразовать внешний вид элементов формы и позаботиться об их юзабилити. Вниманию читателя представляется небольшая подборка таких «фишек» — как уже давно применяемых, так и относительно новых, ещё не поддерживаемых всеми браузерами.

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

Стиль выделения ошибок

Стандартное уведомление об ошибках в словах, введенных в поле ввода, представляет собой волнистое подчеркивание. CSS4 позволит установить иной способ выделения орфографических и грамматических ошибок — посредством новых псевдоэлементов — ::spelling-error и ::grammar-error . На текущий момент изменить оформление ошибок невозможно, так как эти псевдоэлементы не поддерживаются браузерами, однако их появление — лишь вопрос времени.

Указанные селекторы будут ограничены следующим набор свойств: color , background-color , cursor , caret-color , outline , text-decoration , text-shadow и text-emphasis .

Стиль выделения текста

В отличие от предыдущих псевдоэлементов из CSS4 ::selection поддерживается большинством браузеров и представляет собой способ стилизации выделяемого пользователем содержимого как внутри отдельного поля ввода, так и во всём документе.

Для ::selection есть пара нюансов, относящихся не только к input :

  • Браузеры на движке Webkit добавляют прозрачность к цвету, указанному в свойствах color и background-color, в результате чего фактический цвет выделения не соответствует заданному в CSS, поэтому их значение следует преобразовывать в формат rgba() с альфа-каналом 0.996 (255/256). При этом манипуляции со свойством opacity не приносят никакого эффекта;
  • Firefox не применяет стиль для картинок, поэтому они всегда выделяются стандартной синей заливкой.

С учетом особенностей Webkit цвета при выделении рекомендуется задавать следующим образом:

Пользовательское изменение габаритов поля ввода настраивается благодаря свойству resize , применяемому также ко всем элементам со значением overflow отличным от visible. Вместе с его указанием для элемента рекомендуется также добавлять минимальную и максимальную ширину и высоту, чтобы избежать нежелательных смещений макета сайта:

Добавление эллипсиса

Когда ширина текстового содержимого обычного input type=»text» больше его фактической ширины, текст по умолчанию обрезается по правому краю и появляется возможность горизонтальной прокрутки. Чтобы сделать обрезку текста визуально привлекательнее через многоточие (эллипсис), следует применить text-overflow :

Удаление лишних элементов внутри полей в IE

Начиная с версии 10 в Internet Explorer такие типы полей как text или password по умолчанию содержат внутри себя дополнительные элементы, вставляемые браузером для улучшения юзабилити, — иконку очистки поля (крестик) и отображения пароля (глаз). Они легко удаляются благодаря соответствующим псевдоэлементам:

Удаление желтого фона при автозаполнении полей

В Webkit после автозаполнения (как правило, форм с логином и паролем) поля приобретают желтый фон и черный цвет текста, которые добавляются непосредственно стилями браузера:

Переопределить данные правила невозможно, поэтому в качестве решения по удалению фона и указанию другого цвета текста предлагается сочетание свойств box-shadow и -webkit-text-fill-color :

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

Удаление стрелки в поле с datalist

При использовании атрибута list (подробнее рассмотрен ниже) в браузерах Webkit к input добавляется иконка в виде стрелки, указывающая на возможность выбора значений из выпадающего списка. За отображение иконки отвечает специальный псевдоэлемент, который может быть скрыт:

Увеличение затенённых символов пароля

Как известно, вводимые в input type=»password» данные затеняются другими символами (как правило, маской служит астериск или черный круг). В Webkit размер этих символов значительно меньше, чем в остальных браузерах. Для их увеличения рекомендуется использовать для поля с паролем шрифт более жирного начертания. Из безопасных шрифтов на эту роль хорошо подходит Verdana, а так как изменения необходимы только для Webkit, селектор можно обернуть в специфический @media :

Затенение символов в поле ввода

Если для поля, отличного от типа password, требуется создать маску, т. е. затенить вводимые символы, стоит прибегнуть к свойству text-security . Оно принимает значения circle , disc , none или square , но, к сожалению, на сегодняшний день доступно только для Webkit с соответствующим префиксом:

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

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

Цукерберг рекомендует:  Как выглядят рабочие столы программистов

Полезные HTML-атрибуты

Среди множества атрибутов input следует подробнее остановиться на autofocus , inputmode , autocapitalize и list , основной целью которых служит улучшение юзабилити форм. Они не так популярны среди прочих, а их функции в отдельных случаях заменяются JS-кодом.

Стоит так же отметить, что несмотря на все атрибуты и способы стилизации, возможности стандартного текстового поля сильно ограничены. Если требуется создать многофункциональную область ввода аналогичную тем, что используются в месседжерах и социальных сетях, например, input со вставкой emoji, следует прибегнуть к помощи HTML5-атрибута contenteditable.

Автофокус на элементе формы

Атрибут autofocus позволяет заранее сфокусироваться на элементе формы, что в определенных ситуациях является прекрасной альтернативой методу HTMLElement.focus() в JS:

Предопределение формата вводимых в поле данных

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

«Некоторые устройства, в частности с виртуальными клавиатурами, могут предоставлять пользователю несколько методов ввода. Например, при вводе номера кредитной карты пользователь захочет видеть только клавиши для цифр 0−9, тогда как при вводе имени предпочтительнее работать с полем, которое автоматически начинает каждое слово с заглавной буквы». Спецификация HTML

Для этих целей существует атрибут inputmode , сигнализирующий браузеру о том, клавиатуру какого именно формата использовать при вводе данных. Несмотря на большую полезность, из всех браузеров его полноценно поддерживает (включая элементы с contenteditable ) только Google Chrome самых свежих версий, а Opera и Firefox — через флаги.

Атрибут inputmode применяется на input с типами text , password , email или url и согласно спецификации содержит следующие возможные значения:

  • none — запрет на отображение клавиатуры;
  • text — текст, соответствующий языку пользователя;
  • tel — телефонный формат, содержащий цифры 0−9, знак решётки и астериска, — аналог input type=»tel» ;
  • url — формат URL, где присутствуют слеш, точка и элементы автозаполнения вроде «www.» или «.com», — аналог input type=»url» ;
  • email — формат для электронной почты с наличием символа «собака» и точки — аналог input type=»email» ;
  • numeric — только цифровая клавиатура — аналог input type=»number» ;
  • decimal — цифровая клавиатура, адаптированная для ввода дробных значений с точкой или запятой;
  • search — клавиатура, оптимизированная для поиска и, как правило, содержащая соответствующую иконку ввода.

Кроме вышеперечисленных значений браузеры так же принимают:

  • verbatim — дословный ввод букв и цифр, при котором, как правило, не применяется автокоррекция введённых данных, что полезно для имён пользователей или паролей;
  • latin — латинский алфавит, как правило, с предикативным вводом, служащий для взаимодействия между пользователем и компьютером (например, поиск данных);
  • latin-name — latin, но для ввода имён;
  • latin-prose — latin, предназначенный для взаимодействия пользователя с другими пользователями и поэтому содержащий более широкий набор возможностей ввода (например, встроенные смайлы);
  • full-width-latin — latin-prose с добавлением дополнительных пользовательских языков;
  • kana и katakana — служат для ввода текста на японском языке;

Для большей «пуленепробиваемости» атрибут inputmode рекомендуется применять вместе с соответствующим type , который должен отражать семантически верный тип данных, и, если необходимо, pattern , являющийся дополнительной подсказкой браузеру о том, какие данные следует считать верными:

Перевод вводимых данных в верхний регистр букв

Атрибут autocapitalize позволяет выполнять для виртуальной клавиатуры автоматический перевод данных поля в верхний регистр. Он применяется для textarea , а также для полей с типами text или search и может иметь следующие значения:

  • off или none — перевод в верхний регистр не осуществляется (по умолчанию);
  • characters — для символов (артикулы, различные коды);
  • words — для слов (имена, адреса, названия организаций);
  • sentences — для предложений (полезно для textarea , где контент должен представляться как абзац текста);

Например, подобным образом может выглядеть область ввода для контента, который разработчик хочет видеть оформленным как абзац:

Стоит отметить, что как и inputmode , этот атрибут не будет оказывать на данные никакого эффекта в desktop-версиях. Информации о поддержке мобильными браузерами autocapitalize крайне мало, однако по публикациям на официальных сайтах следует, что атрибут работает как минимум в Safari и Google Chrome.

Добавление готовых вариантов для ввода

Юзабилити полей можно улучшить, если предложить пользователю выбрать заданное значение из списка готовых через атрибут list и дополняющий его элемент datalist . Отличие от традиционного select заключается в том, что поле доступно для редактирования и ввода любых значений, а предлагаемые варианты — элементы option — показываются либо по желанию пользователя, либо во время ввода при условии частичного совпадения по первым (и далее) символам. Это отличное решение в тех случаях, когда вводимые данные можно предугадать засчёт ограниченного количества вариантов.

Для добавления в поле доступных опций в его атрибуте codelist указывается идентификатор списка, которым, в свою очередь, должен обладать datalist :

Кроссбраузерный поиск в select через input на jQuery

На одном из сайтов, с которыми мне довелось поработать, был select, в котором хранились названия всех городов России. Ну, может и не всех, но в районе 2000 городов точно было. Представьте себе, что вы открываете такой список и пытаетесь найти нужный вам город. Зрелище так себе, согласитесь.

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

Поискав информацию по этому поводу, я узнал, что в jQuery есть очень интересная штука под названием «autocomplete» – плагин, который помогает пользователю заполнять текстовое поле на основе сравнения введенной информации с существующей. Именно это и легло в основу моего скрипта.

Итак, приступим к реализации. Для начала нам нужно составить какой-нибудь select и input:


При этом, как вы заметили, мы сразу скрываем select.

Далее в секции HEAD подключаем необходимые библиотеки:

И завершающим этапом будет вставка скрипта перед закрывающим тегом

Кроссбраузерный поиск в select list

Ниже пойдёт речь о методе поиска по выпадающему списку (select).

Для этого требуется поле ввода текста и собственно сам выпадающий список:

Чтобы результат поиска был нагляднее для пользователя, стоит задать тегу select атрибут size со значением 10.

Добавим к этому немного css:

При вводе данных в поле input всё, что не совпадает со строкой поиска, будем скрывать, оставляя в списке только нужные результаты.

Поиск в списке основывается на использовании регулярных выражений, а так как значение в поле ввода — штука не постоянная, я использую объектную запись регулярных выражений (new RegExp()) вместо литеральной:

Видно, что непосредственно поиск не представляет ничего сложного: весь интерес в отображении найденных результатов.
Дело в том, что простое применение свойств, скрывающих элементы списка, невсегда приводит к ожидаемому результату.
Например, в некоторых браузерах (Chrome, Internet Explorer) если просто добавить display:none к тегу option, последний всё равно останется видимым.

Однако простой финт ушами этот же тег option, обёрнутый тегом span, прекрасно понимает display: none, и ведёт себя именно так, как ожидается.

Как поместить fa-поиск в текстовое поле ввода HTML?

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

Вы можете поместить значок с помощью нескольких строк пользовательского CSS:

Ответ, который вам нужен из документации Bootstrap.

Цукерберг рекомендует:  Использование RabbitMQ в связке с PHP

Вы также можете добавить дополнительные значки обратной связи с добавлением .has-feedback и значка справа.

Пишем свой простой вариант «живого поиска».

Сегодня я напишу статью, о том как сделать простую версию так называемого «живого поиска». Для тех кто не в курсе, живой поиск — это когда при вводе искомого текста, появляется подсказка, с возможными вариантами. Примером тому служит Яндекс и Google.

По сути «живой поиск» это обычный AJAX скрипт, который обращается к базе данных, производит в ней поиск, и возвращает ответ скрипту. Для работы поиска я буду использовать Jquery.

Итак, создадим простую форму поиска:

Обратите внимание на autocomplete=»off» у input’а, это для того чтобы отключить подсказки браузера, которые он показывает при повторном наборе текста в форме.

Теперь займемся созданием javascript скрипта.

Я постарался описать этот скрипт по максимуму в комментариях. По сути скрипт делется на несколько частей:

  1. Считываем ввод с клавиатуры, получаем данные из базы данных и выводим их
  2. Делаем скрытие слоя с подсказками, при нажатии на Escape и Enter
  3. Делаем переход по слою с подсказками, через нажатие стрелок клавиатуры ( вверх и вниз)
  4. Скрытие слоя с подсказками при клике на поле сайта и открытие его при клике на input
  5. При клике на подсказку мы вписываем слово в input поиска и прячем форму подсказки.

Jquery поиск input [type=“text|email”]

Как правильно выбрать первый попавшийся input, type у которого равен text, email или tel, а если равен redio или checkbox, то ненужно брать?

1 ответ 1

Похоже на костыль

Всё ещё ищете ответ? Посмотрите другие вопросы с метками jquery или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2020 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2020.11.13.35431

Placeholder, и юзабилити текстовых полей ввода.

Эпиграф

Здравствуйте дорогие читатели, жаль что почти полгода не писала никаких статей, а эту статью нужно было написать год назад, я всё не знала как за неё сесть. Наверное статья так бы никогда и не увидела свет, если бы мой друг и коллега mr.troll, не написал её за меня.Тема для меня является одной из самых важных. Речь пойдёт о текстовых полях ввода, а вы знаете как трепетно я отношусь к всевозможным формам, например: « Мастерство авторизации», « Основные ошибки проектирования процесса авторизации», « Пользователь важен для вас? Просто дайте ему зарегистрироваться», « Комментарии open_id». Статью можно считать гостевым постом, поскольку я давно приглашаю кого-нибудь написать свою статью в моём блоге. Надеюсь вам понравится. Итак, слово автору.

История проблемы

У всех движков есть свои баги, и некоторые баги глубоко печалят меня, я не могу спать и худею.

Здравствуйте читатели милого блога Usabili.ru,
Вы наверное знаете а таком атрибуте тега как 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 ). Это тоже очень сомнительный плюс. Поскольку по правилам юзабилити — плейсхолдер конечно должен использоваться для описания поле ввода, но не должен использоваться как единственное описание. Так же в случае со связкой логин/пароль — автофокус на поле логина (скрывающий подсказку что первое поле логин) — может быть очевидным для пользователей которые привыкли что на сайтах авторизация через поля логин/пароль, а так же абсолютно очевидна для пользователей которые уже использовали эту форму входа. Вообще автофокус — это единственный и редкий случай где не скрывание текста подсказки хоть как-то оправдано.

Подробнее

А в будущем вместо псевдокласса :-moz-placeholder ( для старых версий фф) нужно будет писать ещё и псевдоэлемент ::-moz-placeholder. и т.п.

Далее небольшой перевод моих комментариев из багзиллы фф:

Hixie изменил «И» на «И/ИЛИ», и браузер-вендоры стали бездумно реализовывать такое поведение. Разве так можно? часть «И» никто не отменял.

По мне, так у нового поведения серьезная проблема с UX. Быть такого не может, чтобы кому-либо было удобно начинать печатать в поле, уже содержащем текст! Разве я могу предвидеть, что текст магическим образом исчезнет, стоит начать печатать? Замещаемый текст нельзя удалить ни клавишей Delete, ни сочетанием Ctrl+A, Backspace. От него вообще нельзя избавить никоим образом, кроме как начать печатать.

Хотите пример поля с текстом в фокусе, который замещается при начале ввода? Это mcedit ( linux Midnight Commander). При открытии поискового диалога, в поле запроса уже находится последнее использованное ключевое слово. И если начнете вводить в это поле текст, это слово поведет себя, как замещающийся текст. Но если не начнете, — оно произведет поиск по ключевому слову, а не по пустой строке! Поэтому это не placeholder — это предопределённое значение (predefined value).

Цукерберг рекомендует:  Как правильно выбрать монитор Ч.2

Хотите ещё? Далеко ходить не надо, в Windows просто нажмите Win+R, и вы получите диалоговое окно Run, в котором отображена последняя выбранная в нем команда – если вы начнете печатать, она, ясное дело, удалится, потому что это был выделенный текст, но если не начнете печатать ­­– выполнена будет последняя команда.

Как пользователю различить, то ли это замещаемый текст, то ли предопределённое значение? Единственный метод – поставить курсор!

Таким образом, разве может пользователь при работе с браузером ожидать, что поле, которое ведет себя как с предопределенным значением при установке курсора, будет обработана как пустая строка? Раньше всё было просто: если после установки курсора строка становится пустой – то в форму отправится пустая строка.

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

По мне, так вы сломали всю функциональность замещаемого текста. Единственный способ – имитировать его java-скриптом, как мы делали лет десять назад. И как http://mail.yandex.com/ делает ныне.

И ради чего? Ради пользователей, которые могут забыть замещаемый текст сразу после того, как кликнули на поле для ввода? Так, что ли?

Сайт, над которым я сейчас работаю включает светло-серый цвет вводимого текста ( #a0a4ad), и если вы сможете выбрать цвет, вы увидете, что замещаемый текст, в моем случае, использует цвет вводимого текста. И при наведении фокуса ничего не изменяется ( кроме текстового курсора), вот в чем соль.

Если у поля ввода с замещаемым текстом есть автофокус – замечательно. Если нет – веб-мастеру следует поместить пометку вне поля ввода. Опять же смотрите http://mail.yandex.com/, там автофокус на поле ввода. Если пользователь недостаточно сообразителен, чтобы понять, что это поле для логина, он уберет курсор и прочитает, и в следующий раз уже будет в курсе, для чего это поле. Но текст в поле с курсором будет напрягать его при каждом посещении! И ничего с этим не поделать. Почему бы не показывать замещаемый текст только для автоматически наводящегося курсора, раз уж так необходимо?

Примените следующий код и попытайтесь ввести значение поля:

Это может заставить понервничать даже меня! Оно заявляет мне, что поле пусто – но, эй! – в нем установлен курсор и, я могу поклясться Мозилле, что вижу в нем текст!

Почему не делают никаких UX ревью? Старое доброе правило юзабилити гласит: « Когда достаточно места, и метка для поля ввода важна – используй вне поля ввода вместо placeholder; используй , когда много полей для ввода. Но если есть только одиночная форма поиска, или пара полей логин/пароль, или что-либо столь же очевидное для пользователя – можешь использовать замещаемый текст.» Таким образом, я полагаю, что атрибут замещаемого текста используется только в том случае, если пользователь может догадаться о его содержании ( ie8 вообще не способен его отображать). Получается, программисты мозиллы считают, что замещаемый текст всегда настолько важен, что должен пользователь должен видеть его даже после клика?! Я не верю, что пользователь может забыть его сразу после клика.

Вот мой основной вопрос: если у вас есть работающий код, зачем его менять? Если у вас есть код, работающий ХОРОШО и всех устраивающий, то зачем его менять?

Может кто-нибудь будет любезен и выскажет личное недовольство старым поведением? И тем самым дать мне причину?

Славно, что этот баг не будет подтвержден в Gnome по причинам, которые я описал выше.

Пользователя гораздо больше смущает ситуация, когда он попал курсором в поле и больше не видит подсказки, которая была в поле. Когда он увидит её, прочтёт и поймёт, что писать — она изсчезнет. Это поведение, к примеру, идёт сквозь все интерфейсы системы Mac OS X.

Я считаю это очень правильным решением. Это не баг, это хорошая идея.

Если вы с этим не согласны, вы вольны сделать тот самый фикс в CSS ваших проектов. Но на мой взгляд, вы только запутаете его. А пока обратите на плейсхолдер в адресном и поисковом полях интерфейса Оперы — подсказки в них не исчезают при установке курсора.

Пруф того что в IE10 плейсхолдер специально убирается по клику можно посмотреть тут:

везде пишут «Placeholder text is visible until focus is placed in the element.» и т.п.

А вот список связанных багов в FF:

P.S. Moony: Статья была написана вообще-то полгода назад. Но перечитать несколько раз и выложить её руки дошли только сегодня. Сорри. Надеюсь вам интересна проблема с placeholder.

Под катом вы можете также посмотреть переписку с Хикси:

Заголовок для поля ввода и его доступность :: Хранитель заметок

Заголовок для поля ввода и его доступность

Подпись или заголовок для поля ввода размечается тегом . Наличие связанного с ним элемента ,

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

может быть как обёрткой для поля ввода, так и быть связанным с ним с помощью атрибутов. Вот несколько типовых вариантов разметки:

Клик по надписи в обоих случаях приведёт к том, что связанное с этой надписью поле ввода получит фокус. В первом случае связь инпута и лейбла определяется явно (фокус получает первое дочернее поле ввода). Во втором случае связь осуществляется с помощью атрибута id у поля ввода и аналогично значения у атрибута for лейбла.

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

Подсказка в поле ввода

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

Но не стоит путать подсказку и подпись.

Доступность

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

Скрыв подпись к полю ввода с помощью стиля display: none , мы не решили проблему с доступностью текста подписи. Вспомогательные технологии игнорируют элементы, к которым применён такой стиль.

Вернуть видимость текста можно опять же несколькими способами.

Текст подсказки оборачивается в дополнительный элемент, который уже скрывается стилем display: none .

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

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

Как вариант, явно указать подпись можно с помощью атрибута aria-label .

Класс visuallyhidden выключает элемент из потока и делает его размеры 1×1 пиксель. Формально подсказка остаётся видимой и зачитывается ридерами, но фактически её не видно на экране.

У всех способов есть свои плюсы и минусы:

  • первый вариант оказался в итоге самым компактным и универсальным, но появился дополнительный элемент в разметке;
  • второй вариант самый громоздкий (требуется слишком много атрибутов и два уникальных идентификатора), но в то же время и самый надёжный;
  • третий вариант выглядит хорошим компромиссом, если не позаботиться о том, чтобы id инпута не повторялся на странице.
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих