В старые добрые времена веб-разработки правила основывались на таблицах. В то время как их было относительно легко понять, сложные конструкции требовали сложных, глубоко вложенных структур таблиц, которые следовали за визуальным расположением. Если генеральный директор или веб-дизайнер впоследствии решат, что правая навигационная панель будет хорошей, плохому веб-разработчику придется менять структуру HTML на каждой странице.
Когда CSS впервые появился, независимость от макета была объявлена ключевым преимуществом. Другими словами, порядок источника содержимого HTML не имеет значения — CSS можно использовать для создания любого визуального дизайна. Элементы можно переставить, изменив несколько свойств стиля в одном файле. Теоретически.
На самом деле, мы знаем, что изменения в дизайне могут быть гораздо сложнее, и часто бывает необходимо изменить исходный код HTML. Как красноречиво заявил Эндрю в « Размахивающих пальцах» в макетах CSS :
Чисто CSS макеты являются чистой выдумкой. Все текущие методы макета CSS в некоторой степени зависят от потока документов. В CSS отсутствует способ описания макета, полностью независимого от порядка разметки, хотя он может появиться в ближайшем будущем.
Кроме того, в Рекомендациях по доступности веб-контента рекомендуется, чтобы ваш порядок DOM соответствовал визуальному порядку . Основные причины:
- Если слепой человек, использующий программу чтения с экрана, которая следует порядку источника, работает со зрячим пользователем, который читает страницу в визуальном порядке, они могут быть сбиты с толку, когда сталкиваются с информацией в другой последовательности.
- У пользователя с ослабленным зрением клавиатура может испытывать затруднения при предсказании фокуса клавиши табуляции, если исходный порядок не соответствует визуальному расположению. Кроме того, установка атрибутов tabindex, которые приводят к порядку, отличному от порядка в DOM, может вызвать проблемы с некоторыми вспомогательными технологиями.
- Также могут быть ситуации, когда визуально представленный порядок необходим для общего понимания страницы.
Эндрю также указывает на то, что семантические элементы HTML5 эффективно делают порядок источника неактуальным. Элемент article содержит основной article , nav содержит навигацию, а aside содержит дополнительный контент. Следовательно, приложение для синтаксического анализа может находить контент в семантических тегах, а не принимать произвольное решение на основе его местоположения в источнике.
Все это звучит достаточно разумно. Так почему я чувствую себя немного неловко?
Давайте забудем о веб-технологиях на данный момент. Когда вы создаете документ, имеет смысл упорядочить элементы по их относительной важности. За основным заголовком следует основной текст, вторичный контент, ссылки на связанные ресурсы (навигация) и нижний колонтитул. Окончательный макет редко имеет значение — он должен быть в глубине души, но нет необходимости осознанно его рассматривать.
Вот так я подхожу к HTML.
Я должен отметить, что я не обязательно буду применять строгие ограничения. Например, я рад разместить навигацию в шапке, особенно если там всего несколько ссылок. Но в целом мне нравится, что мой HTML-код логически упорядочен.
Важно рассмотреть слепого пользователя, сидящего рядом со зрячим помощником, но, на самом деле, как часто возникает такая ситуация? Когда это произойдет, сколько путаницы будет вызвано, если программа чтения с экрана прочитает основное содержание перед левым меню навигации? Является ли ссылка «перейти к содержанию» более предпочтительной?
Что касается настроек tabindex, в Руководстве WCA подчеркивается основная проблема: tabindexes указываются в HTML, тогда как визуальный порядок определяется в CSS. Если пользователь применяет альтернативную таблицу стилей, порядок табуляции не обязательно будет правильным.
Но есть ли причина определять табличные индексы, если ваш HTML логически упорядочен. На мой взгляд, было бы лучше, если бы пользователь мог переходить по ссылкам основного контента, прежде чем встретить несколько десятков элементов навигации. Возможно, это вызывает некоторое первоначальное замешательство, но, опять же, дезориентация больше, чем на несколько секунд?
Тогда мы переходим к HTML5. Хотя я предвижу светлое будущее для технологий, мы еще не там. Немногие системы различают контент, размещенный в теге article контент, размещенный в header — даже браузеры не заботятся об этом.
Следует также отметить, что на одной странице может быть несколько тегов article , header и footer . Например, давайте рассмотрим страницу с полным постом в блоге и выдержками / ссылками на пару связанных постов. Все эти элементы могут отображаться в собственном <article> . Если визуальный макет размещает фрагменты слева от основного контента, логично ли их упорядочивать над основным контентом в источнике HTML5?
HTML5 предлагает семантические теги, но это не причина для создания нелогично упорядоченных документов.
Мы также должны учитывать последствия технического обслуживания. Дизайн и макеты развиваются. Предполагая, что изменение может быть обработано только с помощью CSS, должен ли веб-разработчик изменить исходный код HTML, чтобы отразить визуальное обновление? Это дополнительная разработка и тестирование за небольшую реальную выгоду.
Наконец, есть одна главная причина, по которой авторам контента не обязательно нужен порядок HTML в соответствии с визуальным макетом: поисковая оптимизация. Google, Bing и другие движки придают больший вес содержимому в верхней части документа. Я не вижу, чтобы это изменилось, даже когда они полностью осознают HTML5.
У меня нет ответов на все вопросы, и я бы не сказал, что вы никогда не должны этого делать, но для меня упорядочение исходного HTML-кода в соответствии с визуальным макетом выглядит как шаг назад. Потенциальные недостатки перевешивают относительно незначительные и довольно неясные преимущества доступности.
Возможно, здравый смысл — лучшее всестороннее решение. На дизайн должен влиять контент, а не наоборот. Держите ваш HTML логически упорядоченным и, когда есть выбор, откладывайте до физического макета.
Буду благодарен услышать ваше мнение.