зачем нужен label в html
Всегда используйте label
Это перевод статьи Адама Сильвера — «Always use a label».
Иногда дизайнеры слишком сильно упрощают форму, убирая подпись к полю (примечание переводчика: здесь и далее имеется в виду тег label). Проблема в том, что минимализм не всегда означает простоту в использовании, а это, безусловно, и происходит с подписями.
На самом деле, подпись к полю является важной частью для создания лёгких в использовании форм. Вот почему:
1) Зрячие пользователи смогут видеть инструкции и будут знать, что делать. Без подписей к полям в лучшем случае это будет сложно.
Подпись к полю помогает зрячим пользователям понять, что нужно вводить
2) Незрячие пользователи смогут услышать инструкции благодаря использованию скринридеров. Без подписей к полям это будет невозможно.
Поле «Username» доступно для чтения скринридерами
3) Пользователи с моторными нарушениями смогут легче найти и активировать элементы с помощью мышки или пальца благодаря увеличению размеров активной области. Это происходит потому, что клик и нажатие пальцем по подписи работает так, будто пользователь кликнул по самому элементу управления.
Большая площадь поля помогает пользователям с моторными нарушениями активировать элемент
Но для меню выбора вида/размера/цвета/количества не нужны подписи, не так ли?
Нужны, и, к сожалению, довольно часто подписей нет в формах выбора товаров. ASOS страдает этой проблемой, как вы видите.
Форма выбора товаров на ASOS пренебрегает подписями у раскрывающихся списков
Вместо подписей здесь используется первое значение из раскрывающегося списка. Пока значение не выбрано это допустимо для хорошо видящих пользователей, но создаёт трудности для пользователей с нарушением зрения или моторных функций. Если значение выбрано, как в примере выше с выбором цвета, сложности возникают уже у всех типов пользователей.
House of Fraser показывает подпись к раскрывающемуся списку выбора количества вещей, улучшая удобство использования всем пользователям.
House of Fraser имеет подпись у поля с выбором количества вещей
Простая форма поиска не нуждается в подписях, не так ли?
Нуждается, но, к сожалению, формы поиска часто разрабатываются без подписей. В качестве примера можно посмотреть на Selfridges.
Форма поиска Selfridges пренебрегает подписью к полю
Чтобы объяснить назначение формы, вместо подписи здесь используется подсказка для поля и кнопка отправки (иконка лупы). Но это чересчур сложно для использования людьми с ограниченными возможностями — и, конечно — подсказки полей не должны использоваться как замена подписям.
Smashing Magazine показывает, как использование подписей может быть красивым и функциональным одновременно.
Форма поиска Smashing Magazine использует подпись у поля
Использование подписей к полям может нести дополнительные сложности в дизайне, но уход от этих проблем — это не решение. Принимайте этот вызов, и не стоит чересчур упрощать. И конечно, всегда используйте тег label.
Когда стоит вкладывать input в label, а когда нет?
В целом, с точки зрения правильности/валидности кода, как заметил Danny Arty, разницы нет. В примитивных случаях верстки визуальной разницы тоже особо не наблюдается.
Но если нужно сверстать что-то посложнее, сделать более интересное оформление, разница появляется, поскольку нам нужно взаимодействовать с разным порядком и вложенностью различных тегов. Сравните:
1. В таком варианте у нас имеется два рядом расположенных тега. Чтобы выбрать второй, идущий после первого, можно использовать «соседский» селектор «+» (Label идет сразу после Input). Данный вариант более «независимый», так как мы можем менять местами input и label, и даже разносить их на удаленное расстояние.
А теперь представим, что нам нужно сверстать нечто подобное на основе (см. картинку): 
Как это реализовать? Для label соорудим «:before» и «:after», которым дадим форму скругленного прямоугольника и круга (который, к тому же будет перемещаться).
Формы — Основы вёрстки контента
Формы — важный интерактивный элемент веб-страницы. Как и ссылки, формы обеспечивают взаимодействие пользователя и страницы, позволяя отправлять данные. Для этого в HTML существуют специальные конструкции, которые говорят браузеру, какие поля может использовать пользователь и как их обрабатывать.
Тема форм достаточно большая, чтобы описать её в рамках одного урока, ведь со всеми возможными нюансами это может вылиться в целый курс. Не бойтесь — в этом уроке вы узнаете достаточно, чтобы научиться делать хорошие формы.
Создание формы
Для отделения формы от остальных участков вёрстки используется специальный тег
Сервер — удалённый компьютер, на котором хранится весь проект. Сейчас вы смотрите на страницу, которая сгенерирована на сервере и отдана вам по определённому адресу. Этот адрес указан сейчас в вашем браузере.
Примером взаимодействия с формой является любой сайт-поисковик. Например, Google или Yandex. Вы вводите поисковый запрос, который отправляется на сервер. Сервер обрабатывает результат и выдаёт вам подходящие сайты. Это взаимодействие происходит с помощью серверных языков программирования, таких как PHP, Ruby и так далее. В рамках вёрстки мы не можем влиять на то, как обработается результат. Результат вёрстки — набор тегов, с помощью которых браузер соберёт данные и отправит их на сервер.
Смысл этого действия вы лучше поймёте, если будете заниматься Backend разработкой. Например, на языке PHP или Python. Если сейчас вам кажется это сложным, то не отчаивайтесь. Разработчики всегда вам подскажут, куда стоит отправлять данные.
Поля формы
В примере вы можете увидеть два атрибута тега
Попробуйте изменить размер элемента
. Это можно сделать потянув за правый нижний угол. Так вы можете не только увеличить ширину, но и высоту элемента.
Такое поведение зачастую вредит нашему дизайну. Поэтому разработчики в большинстве случаев запрещают такое поведение. Тут есть несколько вариантов:
input
type=»text»
Самый простой вид input, который позволяет ввести любую пользовательскую информацию. Никаких проверок полей не происходит. Единственное исключение — удаление переносов строк перед отправкой на сервер. Если нужны данные с переносом текста, то используйте тег
Заметьте, что сейчас поле никак не подписано и из-за этого абсолютно непонятно что надо ввести пользователю. Первое, что приходит в голову — добавить перед полем заголовок или параграф. Да, это создаст видимость описания поля. Но только видимость! С точки зрения семантики в таком варианте нет никакой связи между текстом и полем ввода. Это критично для слепых, которые пользуются скринридерами, так как они не смогут связать название и поле для ввода.
Скринридер (Screen Reader) — устройство для чтения текста с экрана. Используется слепыми или слабовидящими людьми.
. Это справедливо даже в случае визуального отсутствия подписи к полю.
type=»radio»
Радиокнопки используются для выбора одного варианта из множества доступных. Почему такой тип называется radio? Есть мнение, что такое название тип получил от первых автомобильных радиоприёмников. В них было доступно несколько радиостанций, но выбрать можно было только одну. Здесь смысл очень похож на принцип таких приёмников.
type=»checkbox»
Чекбоксы немного похожи на радиокнопки, но имеют существенное отличие — возможность выбора сразу нескольких значений. Представьте, что пользователь выбирает любимые блюда. Скорее всего это не одно блюдо, а сразу несколько. Можно дать возможность просто их написать с помощью
, но грамотнее будет использовать чекбоксы.
Списки
Отдельным элементом формы являются списки. Представьте себе фильтр на сайте по продаже техники. Одновременно вы можете отфильтровать товары только в одной категории. Для этого можно использовать радиокнопки или даже чекбоксы в случае множественного выбора. Но есть ещё один способ — использование списка.
Для элементов радиокнопок и чекбоксов для выбора по умолчанию используется атрибут checked
Отправка формы
В прошлом разделе мы рассмотрели различные способы взаимодействия пользователя и формы. Но это не имеет никакого смысла, если форма не будет отправлена. Для этого нужно создать элемент, при взаимодействии с которым будет отправлена форма.
Отправка формы может быть осуществлена одним из двух способов:
Разделение участков формы
Текст внутри текстового поля
Во всех примерах этого урока текстовые поля изначально были пустыми. Наверное вы часто видели, что до фокуса на поле есть текст, предлагающий ввести данные или показывает формат, в котором ожидаются данные.
Самостоятельная работа
Создайте форму для регистрации пользователя на сайте. Форма должна принимать следующие данные:
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Нашли опечатку или неточность?
Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.
Что-то не получается или материал кажется сложным?
Загляните в раздел «Обсуждение»:
Об обучении на Хекслете
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Наши выпускники работают в компаниях:
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Критерии качества вёрстки 2021
6 лет назад мы обсуждали с сообществом критерии качества вёрстки, которые мы используем в обучении, чтобы наши выпускники радовали рынок своими умениями и подходом к работе.
С тех пор в разработке интерфейсов произошло море изменений: сначала в продакшн пришли флексы, потом подтянулись гриды, умер IE, все переехали из Фотошопа в Фигму, и много чего ещё. Каждое это изменение влияло на наши критерии, и мы постоянно их дорабатывали.
Сейчас пришло время снова обсудить с сообществом обновлённые критерии, чтобы наши выпускники продолжали радовать индустрию своим уровнем.
Ниже представлена обновлённая система критериев, которую мы планируем внедрить на осенних запусках курсов. Мы публикуем её сейчас, чтобы собрать обратную связь от сообщества и внести изменения в критерии.
Что описывают и что не описывают эти критерии
Эти критерии касаются нашего первого уровня вёрстки, то есть задач, связанных с фиксированной вёрсткой без адаптивности и без специфичных требований к вёрстке (например, по натяжке на конкретную CMS).
Критерии для задач, связанных с адаптивностью, автоматизацией, натяжкой на CMS или вёрсткой под React, мы тоже планируем обсудить с сообществом, когда подготовим их.
Как устроена система критериев
На курсе ученик верстает макет (вот такого уровня сложности), и на защите в конце курса эту вёрстку по критериям качества проверяет случайный наставник. Защита считается успешной, если зачтены все обязательные критерии.
Помимо обязательных есть и дополнительные критерии, их выполнение для успешной защиты не нужно, но они позволяют более точно оценить качество работы и показать ученику как улучшить свой код. Дополнительные критерии в нашей системе помечены звёздочкой.
Для удобства обсуждения критерии разбиты на категории, некоторые критерии относятся к процессу приёмки проекта, некоторые к качеству кода.
Также для многих критериев мы попытались написать обоснование, зачем нужен критерий, и почему он именно такой. И будем рады, если в результате обсуждений появятся новые обоснования или дополнятся текущие.
TEST-01. Кроссбраузерность
Необходимо смотреть на размеры и расположение блоков, внешнее сходство с макетом.
Необходимо проверить работу анимации, если такая имеется.
Допускаются небольшие отличия в отображениях шрифтов.
Вёрстка должна идентично отображаться в последних стабильных версиях браузеров Chrome, Firefox, Safari, если иное не указано в техзадании проекта.
Пользователи сайта могут использовать разные браузеры в разных системах, поэтому нужно добиваться единого отображения.
TEST-02. Технологии
Проект должен быть сделан на HTML и CSS без использования сторонних библиотек и фреймворков.
Задача курса — научить решать задачи с помощью базовых технологий. Полученная база позволит разобраться, как работают фреймворки или библиотеки.
TEST-03. Размеры страницы
У каждой страницы есть минимальная ширина по фрейму.
При ширине окна больше минимальной страница центрируется.
Горизонтальная прокрутка появляется только при ширине, меньше минимальной.
Допускаются расхождения по горизонтали, не превышающие ширину полосы вертикальной прокрутки.
Примеры и назначение критерия
Зачем нужен критерий
В качестве ориентира для ширины страницы используется фрейм, потому что мы считаем Figma преобладающим форматом макетов и поэтому пользуемся терминами этого графического редактора. В учебных макетах мы учли минимальную ширину, но в реальной разработке минимальная ширина страницы может отличаться от размера фрейма.
У страницы должна быть минимальная ширина, чтобы у пользователей с меньшим разрешением при просмотре страницы оставались работоспособны все элементы сайта.
Контент страницы должен быть отцентрирован, чтобы у пользователей с большим разрешением при просмотре страницы контент находился перед глазами — в центре страницы.
TEST-04. Переполнение
Длина текста
Текст должен оставаться в рамках родительского блока при переполнении.
Текст не должен обрезаться или вываливаться из родительского блока при переполнении.
Текст не должен смещать другие блоки.
Родительский блок должен сохранять минимальные размеры при недополнении.
Слова, длиннее минимальной ширины, должны переноситься.
Размеры элементов
Контент больше ширины родителя не должен выходить за его пределы, ломать сетку или смещать другие блоки.
Количество элементов
При увеличении количества элементов они должны оставаться в рамках родительского блока.
Элементы могут переноситься на следующую строку при уменьшении размера родителя.
При минимальном количестве элементов или их отсутствии родительский блок должен сохранять минимальные размеры.
Последние блоки в сетках должны выравниваться по направлению текста.
Примеры и назначение критерия
Длина текста
Текст должен оставаться в рамках родительского блока при переполнении и не должен вываливаться или обрезаться из родительского блока.
Родительский блок должен сохранять минимальные размеры при недополнении.
Слова длиннее минимальной ширины должны переноситься.
Размеры элементов
Контент больше ширины родителя не должен выходить за его пределы, ломать сетку или смещать другие блоки.
Контент больше ширины родителя не должен выходить за его пределы, ломать сетку или смещать другие блоки.
Количество элементов
При увеличении количества элементов они должны оставаться в рамках родительского блока и последние блоки должны выравниваться по направлению текста.
Элементы могут переноситься на следующую строку при уменьшении размера родителя.
При проверке переполнения в браузере Safari необходимо добавлять текст не через инспектор браузера, а через редактор кода, редактируя страницу HTML. В противном случае текст будет добавляться в одну длинную строчку.
Зачем нужен критерий
Верстальщик должен предусматривать ситуации, в которых контент может меняться, и подготавливать вёрстку к изменениям контента.
TEST-05. Шрифты
Следующие текстовые параметры должны соответствовать параметрам из макета:
семейство шрифта font-family ;
насыщенность шрифта font-weight ;
начертание шрифта font-style ;
размер шрифта font-size ;
высота строки line-height ;
При проверке этого пункта следует ориентироваться именно на параметры, указанные в макете. Из-за особенностей отображения шрифтов на разных платформах, определение этого критерия на глаз может привести к ошибке. Помимо этого, стоит допускать разное межбуквенное расстояние в макете и в финальной вёрстке. Считать разное межбуквенное расстояние ошибкой стоит только в том случае, если оно явно указано в макете.
TEST-06. Pixel Perfect
При наполнении контентом, как в макете, элементы каждой страницы соответствуют макету.
различия в 5 пикселей по высоте при расстояниях более 30 пикселей и 2 пикселя по ширине;
различия в отображении шрифтов, связанные со сглаживанием на различных платформах.
Примеры и назначение критерия
Рекомендуем проверять с помощью инструмента PerfectPixel (работает в Chrome, Firefox).
Зачем нужен критерий
Заказчик может не принять работу, если вёрстка будет отличаться от согласованному макета. Поэтому веб-разработчик должен не просто сверстать сайт по образцу, а сделать это близко к согласованному макету.
Чтобы сайт как можно точнее совпадал с утвержденным дизайном, веб-разработчики придерживаются концепции Pixel Perfect. Это способ вёрстки строго по макету, при котором размеры и интервалы из макета соблюдаются с точностью до нескольких пикселей.
Допустимые различия нужны для компенсации несоответствий макету, связанных с отличиями отображения элементов в разных графических редакторах, браузерах и операционных системах.
TEST-07. Стайлгайд
Все состояния элементов должны соответствовать стайлгайду, предусмотренному в макете. Стайлгайд — это часть дизайна проекта, он имеет наивысший приоритет. При наличии стайлгайда верстальщик должен ему следовать.
Если в стайлгайде не предусмотрены состояния элемента, то их нужно реализовать на своё усмотрение.
При проверке этого пункта следует оценивать наличие эффектов и их соответствие стайлгайду.
TEST-08. Взаимодействие
При взаимодействии с элементами (наведение, нажатие) ни сам элемент, ни окружающие его блоки не меняют своего положения, если такое поведение не предусмотрено макетом.
Почему не работает label вне формы?
Простой 1 комментарий
.label.l-3 <
display: inline-block;
position: absolute;
top: 75px;
right: 0px;
left: 0px:
>
Для точечного позиционирования подберите свои значения top, right или top, left конкретно в вашем случае. Таким образом вы извлечете этот элемент из нормального потока и расположите его где вашей душе вздумается!)
Других не слушайте, они несут глупости про спецификации. Спецификация (1, 2) не запрещает связывать с формой и при этом помещать label куда угодно на странице. Они даже соответствующий атрибут (form) у label убрали из спецификации за ненадобностью.
Labels are not themselves directly associated with forms. They are only indirectly associated with forms through the controls with which they’re associated.
The for attribute may be specified to indicate a form control with which the caption is to be associated. If the attribute is specified, the attribute’s value must be the ID of a labelable element in the same Document as the label element.