Как бы вы не называли эти секции — блоки, модули, области, разделы — их используют для визуального выделения разделов веб-страниц уже более десяти лет. Вся проблема в том, что мы никогда не имели подходящих инструментальных средств, чтобы делать это. Несмотря на то, что внешний вид веб-сайта доступен всему миру, его структурная организация представляла собой нагромождение из пронумерованных заголовков и бессмысленных элементов помощи. Неуправляемый поток контента выглядел как один сплошной блок.
Существует возможность выделения фрагмента документа с помощью тэга <div>, но данный фрагмент не будет вести себя как раздел. Процесс работы со вспомогательными технологиями (AT) и анализ данных программного обеспечения существенно отличаются от возможности визуально следить за результатами изменений.
Теперь, когда в HTML5 наконец-то реализована возможность секционирования элементов, многие пользователи стали проявлять к ней свое негативное отношение. Почему так происходит? Отчасти потому, что мы находимся в обществе, которое частенько разочаровывается в изменениях. С другой стороны, причина в некоторых ощутимых расхождениях относительно советов в спецификации. Советы представляют собой пояснение и алгоритм секционирования, который на самом деле проще в использовании, чем предыдущие реализации. Некоторые просто очень привыкли к традиционной последовательности выполняемых действий, и они думают, что вы должны поступать также. Они даже не могут привести стоящих аргументов.
Не ошибитесь: секционированные элементы помогут вам улучшить структуру документа и их можно повторно использовать в спецификации. Я хочу рассмотреть основные проблемы, которые можно решить с помощью этих элементов, их возможности и не всем понятную важность для “Семантической паутины”. Если вы не знакомы с понятием “Семантическая паутина”, то этот видеоролик поможет получить необходимую информацию.
Оформление веб-сайтов.
Мое знакомство со сферой веб-дизайна началось в университете, с курса лекций под названием “2.1: Дримвивер”. Я очень хорошо помню свой первый веб-сайт. Я помню, как специально подбирал яркую палитру специализированных цветов. Я помню, как проверял в Навигаторе Netscape правильность отображения только что скорректированных элементов. Лучше всего, я помню часы неудачных попыток создания периметра для визуального выделения шаблона с именем “стол”. Я тогда не имел совершенно никакого понятия, что этот макет представляет собой специфический тип выделения, который называется HTML тегом. Кроме того, никто не сказал мне, что эта HTML команда будет использовать совокупность основных цветов и сжимать файлы в формате JPEG, чтобы провести обработку, на подобии той, что осуществляется в таблице Excel сумасшедший. Другими словами, я понятия не имел насколько правильны или ошибочны были мои действия.
* Bites tongue *
Фундаментальная неудача в создании большинства графических элементов, продуктов, архитектуры и даже городского дизайна заключается в упорном следовании принципу визуальной привлекательности, а не приносимой пользы.
Дримвивер (Dreamweaver) от Macromedia не обладает какими-то выдающимися функциональными возможностями в плане создания документов. Но это один из ряда новых GUI (графический интерфейс пользователя) редакторов, которые ориентируются на наше стремление к визуальному выражению, в ущерб информационной ясности. Суть работы Дримвивер и других редакторов можно охарактеризовать фразой “WYSIWYG” (что видишь, то и имеешь). Они помогают преобразовать стандартизированную информационную систему в хранилище для графического дизайна. Во многом благодаря подобным инструментам появились толпы поклонников, не всегда выносимого, сериала Натан Барли, заполонившего всемирную паутину своей пустой привлекательностью. Я был одним из многих.
Веб-стандарты.
К тому времени, когда я завершил создание своего первого сайта, стремительными темпами развивалось движение веб-стандартов, которое содействовало соблюдению норм проектирования. Об этом я узнал уже гораздо позже. Так не должно быть: система взаимодействий в рамках веб проекта, по прежнему, большей частью оставалась графическим проектом с небольшим влиянием программирования. Если у вас возникают сомнения относительно существовавших на то время тенденций всемирной паутины, советую проанализировать данные до 2010 (! 2010 ). Веб-браузеры действительно сделаны не из бумаги.
Хотя я, наконец, познакомился с основами веб-стандартов и стал «делать вещи правильно», моя деятельность напоминала работу человека, который все еще выступал главным образом в качестве визуального конструктора. Мои первые попытки в освоении основ стандартов дизайна относились к изучению “шаблона CSS,” практики визуальной организации контента, не полагаясь на семантически неправильный <table> элемент. Мы продвигали тэг <div> в качестве основы шаблона в течение ряда лет. Можно даже сказать, что он стал временным обрядом посвящения для графических дизайнеров, которые переходят к “правильному” HTML кодированию.
Я постараюсь продемонстрировать, что тэг <div> является основным инструментом графического дизайна. Оказывая влияние только на внешний вид, он реорганизует примитивную структуру документа и интерфейсов; все, что выходит за рамки документа технически неверно. Проще говоря, данный тэг позволяет выполнить разбиение.
Проблема с тэгом < div>.
Каждый день тысячи веб-разработчиков прибегают к услугам всемогущего тэга <div>, чтобы делить, создавать разделы и ограждать контент на веб-страницах. Мы используем <div> для защиты контента, чтобы предотвратить появление разрозненных кусков информации, способных оказать негативное влияние друг на друга. По правде говоря, тэг <div> не имеет огромных функциональных возможностей.
Рассмотрим следующий пример:
В основную схему, я включил тело текста и смежный “контур”. Чтобы читателю было совсем понятно этот контур находится в правой части панели и не принадлежит к основному содержанию. С помощью свойства border я нарисовал по его периметру жирную линию. Для тех из вас, кто начал возмущаться: “Заголовок на боковой панели должен быть выполнен с помощью тэга < h3>!”, я аргументирую свой выбор в ближайшее время. Все мои дизайнерские решения (соседнее положение, границы и уменьшение размера шрифта для заголовка) не могут быть выполнены только лишь использованием одного CSS . Если я совсем уберу CSS, тогда получится следующий результат:
Отключение функций CSS — это не только самый быстрый способ, чтобы сделать веб-страницу адаптивной. У вас появляется отличная возможность увидеть, как HTML4 документы (в которых отсутствует секционирование элементов) на самом деле обрабатываются. В этом случае, наш так называемый “боковой контур” показан просто другим информационным пунктом в линейном потоке документа.
Почему так происходит?
Основная причина этого в том, что тэг <div> есть и всегда был элементом потокового контента. Независимо от того, какой толщины будут заданы границы тэга <div> или насколько темным будет цвет его фона, он не сможет находиться в стороне от основной структуры документа. Таким образом, он всегда будет частью основного содержимого. Из-за отключения функций CSS, искусственная боковая панель с заголовком «Ресурсы» сейчас кажется частью различных компонентов страницы и относится к основному содержанию. Для синтаксического анализатора или ридера такая структура необходима постоянно.
Для ясности, давайте посмотрим на еще один пример использования фрагмента HTML:
<div class="parent"> <h2>Heading</h2> <p>Some content...</p> <div class="child"> <h2>Another heading</h2> <p>Some other content...</p> </div> </div>
Я сделал кое-что не совсем обычное, введя два тега <div> в дочерне-родительские отношений: div.child тег принадлежит к div.parent. Так или иначе, мы можем сделать все это и с помощью CSS. Тем не менее, <div> ссылка тэгов на спецификацию “не имеет особого смысла”. Они не только ничего не значат семантически, но и не оказывают никакого влияния на обработку структурных частей страницы (иногда называемых “схемами документа“). Хорошо было бы использовать невидимые тэги <div>; поэтому, чтобы получить подходящую структурную организацию, мы должны полностью их убрать. Результатом такого действия станет наличие только четырех элементов и предполагаемой дочерне-родительской связи:
<h2>Heading</h2> <p>Some content...</p> <h2>Another heading</h2> <p>Some other content...</p>
Также как HTML кодировщики заинтересованы в надежной структуре, мы должны быть заинтересованы в сокращении кода, который опускает все бессмысленные элементы. Но результаты наших действий не принесли требуемого эффекта: в документе организация принадлежности к “родительским” элементам “дочерних” имеет другие контекстные значения чем предполагалось.
Уровневая организация структуры не поможет.
Популярным заблуждением относительно решения данной проблемы, является замена второго тэга <h2> на тэг <h3>. Если мы сделаем это, то получим следующий, более динамичный контур:
- Заголовок (
h2)- Другой заголовок (
h3)
- Другой заголовок (
Это решение, естественно, кажется более целенаправленным, но правильное ли это решение? Возникает вопрос: второй заголовок будет подзаголовком в пределах одной и той же темы (<h3>) или станет введением в совершенно новую тему (как <h2> в первом примере)? Одни лишь заголовки могут только показать, где начинается определенная часть контента, а где она заканчивается не понятно. Из-за этого возникает проблема однозначного определения принадлежности одной информации к другой. Имитировать принадлежность можно выбрав правильный уровень заголовка для данного контекста. Просто задумайтесь на секунду: мы определяем структурный статус контента помечая его определенным числом. Это начало совершения ошибочных действий.
Давайте посмотрим на домашнюю страницу экспертов из The Paciello Group. При первом же взгляде становится понятно, что это очень доступный и хорошо организованный сайт. А может ли быть улучшена структура с помощью HTML5 секций? Вы можете заметить, что они используют тэг <div> для общего выделения трех <h2> заголовков: Software Developers (Разработчики программного обеспечения), Website Owners (Владельцы веб-сайта) и Mike Paciello (Майк Пациэлло). Поскольку <div> не влияет на содержание этих трех блоков, то для последнего заголовка <h2> и следующего <h3> допускается попарное разделение:
- Майк Пациэлло (h2)
- Свяжитесь с нами сейчас (h3)
Подождите … получается, что заголовок “Свяжитесь с нами сейчас” является подразделом, относящимся к большой теме “Майк Пациэлло”. Неужели это правда? Естественно, что в визуальном макете получается совсем другое представление. Стоит отметить, что в этом случае тэг <div>, который тематически не группирует эти три <h2> блока, принадлежит классу class="region". Результатом такой принадлежности может стать ситуация, когда некоторые программы-ридеры будут видеть <div>, который был <section>, как “region”. Если <section> был использован вместо <div>, предполагаемых результатов не возникло бы: “region” будет замкнутым. Класс “region” не принимается во внимание и не влияет на структуру.
Как бы странно это не выглядело, но ситуация становится еще более запутанной, когда мы начинаем использовать пункты, для которых заголовки являются самым подходящим вариантом. Рассмотрим это еще на одном примере:
На моей странице, созданной с помощью HTML4, организовано следующее представление: <h1> документ, <h2> место основного контента и <h3> место начала “бокового поля” (которое является невыразительным <div>, как и в предыдущих примерах). На странице, следуя давно принятым нормам, расположена безымянная область div#footer. Она находится в самом низу документа и служит местом для информации об авторских правах и других подобных предупреждений. (В HTML4 она должна быть выполнена с помощью <div>, потому что возможности использования для этих целей тегов <footer> пока не существует). Возникает вопрос, а к какому же из заголовков принадлежит информация нижнего колонтитула?
Чей это колонтитул?
Большинство из нас, основываясь на визуальном восприятии, придет к выводу, что информация в колонтитуле должна принадлежать к телу основного документа. Это то, что мы привыкли ожидать. Давайте рассмотрим все немного подробнее: поскольку нет никаких новых вступительных заголовков между боковой панелью <h3> и содержимым нижнего колонтитула, можно сделать предположение, что эти две составляющие являются частью одного целого (см. фото ниже слева). С другой стороны, можно также утверждать, что мы представили “боковое поле” как обычное “прерывание” основного потока контента, прежде чем переходить к информации колонтитула (см. фото внизу справа). Такое предположение дает основание считать заголовок колонтитула, принадлежащим <h2> .
Единственная возможность прийти к пониманию целевой структуры страницы — прочитать все содержимое. Учитывая, что весь смысл “языка разметки” в создании понятной и легко воспринимаемой информационной структуры, я с таким же успехом мог отказаться от HTML и набросать структуру веб-страницы на обратной стороне салфетки.
Некоторые специалисты по вопросам доступности предлагают подкорректировать раздел <h2>, возглавляющий #footer, и явно обозначить его соответствие, создав маркировку конца боковой панели следующим образом:
h1(страница)h2(основная информация)h3(боковая панель)
h2(нижний колонтитул)
Данные действия позволят получить не слишком качественные показатели. Вы действительно хотите сделать визуальное выделение нижнего колонтитула — представленного большим и жирным шрифтом, который используется для отображения основного контента, не говоря уже о полужирном шрифте боковой панели? Нет. Если нашу веб-страницу представить фильмом, то нижний колонтитул не может быть его названием — он будет титрами. В HTML5 элемент <footer> “содержит информацию о его разделе”. Это семантически выше: мы не используем нижние колонтитулы для ввода тем; мы используем их для завершения. Соответственно, нижние колонтитулы — отличные от своих родителей в разделах HTML5 — не требуют заголовков.
Только лишь тот факт, что уровень вложенности заголовков правильно организован не обязательно делает страницу удобной для чтения.
Самое распространенное средство в «системе» HTML4 для структурирования документов требуемым образом — это пронумерованные заголовки. Частенько такая организация информации не только приводит к неоднозначности, как уже было описано, но на практике мы даже не сможем использовать заголовки для определения структуры. Мы используем тэги <div> для определения структуры, а заголовки служат для упрощения доступа к информации. Чтобы не испортить представление материала, рекомендую ознакомиться с советами по вопросам создания нумерации для заголовков. Хотя мне не понятно, должны ли мы использовать установленный порядок (h1-h6) или нет.
Слабая связь между заголовками и тэгами <div> не совсем корректна. С введением элементов секционирования, мы все еще используем определенные виды блоков, которые самостоятельно могут представить содержащуюся в них информацию. Мы переходим от необходимости подразумевать разделы (проводя их маркировку), к возможности определять их самостоятельно. Если контент имеет понятную организацию и разбит на управляемые части, то как простые читатели, так и специалисты по синтаксическому анализу без усилий смогут изучить содержимое.
Спецификации HTML4 имеют множество неточностей касательно организации разделов и определения их объема. Автоматическая генерация контуров важна, особенно для вспомогательных технологий, которые могут адаптироваться к представлению информацию пользователям в соответствии со структурой документа. HTML5 устраняет необходимость использования < div> элементов из алгоритма создания контуров путем введения нового элемента <section>, HTML Элемент Секционирования.
Секционирование.
Учитывая наше стремление к правильной структурной организации элементов в создании легко обрабатываемых разделов, HTML5 предлагает следующий набор тэгов <section>, <article>, <aside> и <nav>. Я хочу познакомить вас с темой практического секционирования и с особенностями использования этих элементов проведя аналог праздничной викторины. Взгляните на изображение ниже. Сколько разделов вы насчитали?
Далее перечислено несколько вариантов ответов:
- 1
- 2
- 3
- 4
Правильный ответ (а), 2. Мы использовали лишь один из новых элементов HTML5 секционирования — <aside>. Если тэги <footer> и <header> не входят в число элементов секционирования, что же нам с ними делать? Тэг <body> -это внешний элемент, который сам документ делает одним из видов раздела (супер раздел, если быть точным). Итак, что мы имеем: мы использовали “секционирование” с HTML 1.0, но только без подразделов.
Некоторые из вас, возможно, подумали, что невнимательно читали статью, и отнесли тэги <header> и <footer> к элементам секционирования. Не волнуйтесь, это не ваша вина. Всякий раз, когда разработчики пытаются объяснить мне структуру страниц HTML5, они обычно размахивают схемами, наподобие той, которую я использовал выше. На этих схемах, разделы с пометками «заголовок», «в стороне» и «нижний колонтитул» существуют в том же Visual Paradigm и занимают аналогичную область. Вы можете сказать, что они подобны друг другу. Другой виновник этой эндемической путаницы — это способ написания спецификации. Верьте или нет, общая структура некоторых страниц в спецификации, которая должна подтверждать структуру документа, совершенно непонятна! Подобные вещи случаются, когда стандарты постоянно развиваются. Дерево навигации для “4.4 разделов” находится в этом эскизе и выглядит следу …
Если вы хотите прочитать полностью статью, посетите сайт наших спонсоров