Cтатьи по тегу «button»

Оформление элементов форм — пожалуй, главный источник боли в современной верстке. Каждое поле ввода, каждая кнопка — «вещь в себе», причем в каждом браузере реализованная чуть по-своему. И управлять их стилями тоже часто приходится в каждом браузере по-своему. А некоторые задачи (например, отобразить кнопку как обычный элемент с display: inline, с переносом на новую строку, если надо) и вовсе никак не решаются (внешне такой эффект дает display: contents, но в теперешних реализациях это ломает доступность, так что это не решение). Много надежд на избавление от этой боли возлагалось на свойство appearance, но судьба этого свойства оказалась сложной и запутанной. Сейчас в браузерах есть лишь старые его реализации с префиксами, тоже везде свои, и ни одна из них не решает задачу полностью.

И вот, пока все браузеры с досады не скопировали «в лоб» -webkit-appearance и не пополнили список «нестандартных стандартов» де-факто, после долгого обсуждения в ишью на Гитхабе давний активист веб-стандартизации Саймон Питерс решил взять дело в свои руки и набросать «правильный» черновик спецификации для этого свойства — учитывающий и пожелания верстальщиков, и браузерную реальность. И стандартизировать наконец и сами браузерные стили для элементов форм, и способ их сброса.

Работа предстоит громадная, но темп взят неплохой. За считанные дни заготовка документа на Google Docs выросла до внушительных 19 страниц. Учитывая опыт Саймона в работе над спецификациями WHATWG, где как раз много приходилось «приводить к общему знаменателю» разнобраузерные зоопарки реализаций, есть надежда, что в этот раз всё получится!

Перевод статьи When <button> isn’t the best choice (it’s slow to create and render and problematic to style) с сайта benfrain.com, автор — Бен Фрейн.

Элемент <button> значительно медленнее при создании в JavaScript, он медленнее отображается в браузере и крайне трудно стилизуется кроссбраузерно. Несмотря на то, что <button>, это «правильный» выбор для задач кнопки, это не обязательно должен быть «лучший» выбор.

Представьте картину. Я пытаюсь убедить главного инженера программного обеспечения использовать более семантические элементы в разметке, а не только общие элементы, типа div  и span. Такие семантические элементы, как section, header, footer и nav. Разговор выглядел примерно следующим образом. «Нам нужно проверить, что они не медленнее при создании в JavaScript», — говорит он. «Конечно, нет проблем», — отвечаю я, с полной уверенностью.