Святой Грааль фронтального развития

Атрибут формы

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

Учиться на ошибках других

Ирония в том, что вопиющие ошибки иногда могут раскрыть основную правду о конкретных проблемах. Если вы достаточно долго занимались разработкой интерфейса, вы могли бы вспомнить дни, когда фоновые разработчики представляли таблицу данных (типичные списки пар метка / значение на страницах сведений) в виде формы с полями ввода, для которых установлено значение «отключено». Эта конкретная структура значительно упростила их работу, поскольку им просто пришлось удалить отключенные атрибуты из полей ввода, чтобы перевести таблицу данных в режим редактирования (создание обычной формы).

Хотя все это звучит довольно глупо в наши дни, еще есть что сказать по поводу их рассуждений. Как таблица данных, так и форма в основном представляют собой одну и ту же семантическую сущность, форма просто является режимом редактирования таблицы данных. Эта семантическая связь между обоими элементами очень реальна и очевидна, поэтому, честно говоря, эта ссылка должна быть одинаково очевидна в нашем HTML-коде. В конце концов, семантика и структура — вот что такое html.

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

Варианты резки

Старый (но популярный) способ разметки форм — использование таблиц. Это на самом деле стало в некоторой степени принятой практикой, поскольку большинство программ для чтения с экрана имеют особые режимы табличных форм, которые направляют своих пользователей через несемантический беспорядок. Однако, принимая во внимание наценку для таблиц данных, таблицы здесь просто недопустимы. Мы не будем использовать таблицы для разметки пар метка / значение, к тому же я не очень доволен использованием таблиц для разметки форм.

Итак, каков наилучший способ разметки пар метка / значение? Что ж, согласно спецификации html5, структура dl-dd-dt была недавно переработана, чтобы охватить именно это. Это достаточно элегантное решение для простых таблиц данных, но если учесть все дополнительные функции, которые нужны обычной форме (обратная связь с пользователем, подсказки / помощь при вводе, несколько входов в одной строке), то недостатки пар дд-дт без родителей становятся реальными боль в заднице. Структура просто не дает нам достаточной гибкости для стилизации и не дает нам средств для построения логической структуры HTML. Еще одна причина, по которой у меня есть сомнения относительно предлагаемой структуры списков определений.

Таким образом, все, что осталось, — это построить нашу собственную таблицу данных / структуру формы, используя div и некоторые подходящие классы. Давайте попробуем.

Базовая настройка

<section class="dataSheet (editable)">
  (<form id="formID" action="#" method="#">)
   <header> (heading/form feedback/required indication) </header>
   <div class="main"> (label/value pairs) </div>
   <footer> (crud links/options/submit) </footer> 
 (</form>) 
</section> 

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

Элементы верхнего и нижнего колонтитула не всегда необходимы, но они очень удобны для отделения пар метка / значение от компонентов, связанных с действием, и / или метаданных. Заголовок может использоваться для заголовков, обратной связи формы (обзор ошибок формы или общая справка) и классического объяснения требуемого индикатора. Нижний колонтитул можно использовать для кнопок отправки и отмены ссылок в режиме формы или для типичных параметров crud в режиме данных. И если design / css не разрешает это, вместо этого всегда можно добавить опцию crud.

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

Метка / группы значений

<section class="fieldset">
  <h1> ... </h1> 
</section> 

<fieldset>
  <legend> ... </legend> 
</fieldset> 

Как видите, теги меняются в зависимости от их контекста, но структура остается прежней. Для простоты стилизации вы можете добавить дополнительный div-обертку, следуя легенде / h1, которая может быть использована для лучшего межбраузерного заполнения / контроля полей (наборы полей общеизвестно сложны для стиля). Точно так же вы можете вложить тег span внутри тега легенды для некоторого кросс-браузерного pos: abs magic, но это все косметические изменения и имеют мало общего с семантикой и / или структурой.

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

слабые уступки HTML

<div class="row">
 ...
 <div class="feedback (error) (confirmation)"> ... 
</div> </div> 

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

Пары метка / значение — наконец-то!

<div class="spec (inputtype)"> 
  <div class="label"> (<label for="id">)...(</label>) </div> 
  <div class="value"> ... 
</div> </div> 

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

В div.value вы можете добавить фактические данные или элементы управления вводом + все дополнительные типичные лакомые кусочки формы (наложения календаря и всплывающие подсказки), которые идут с элементом ввода.

Вывод

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

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

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