Если вы тот, кто использует div теги для всего что есть на сайте, эта статья для вас. Мы сфокусируемся на том, как писать чистый семантический HTML код, используя валидную разметку. Вы увидите на практике, как можно минимизировать количество div тегов в вашем HTML коде. Вы научитесь семантической верстке не только в теории, но и на примерах. Написание правильных семантических шаблонов упрощает жизнь не только себе, но и команде в целом. Ну и проще для браузеров, которые интерпретируют код. Чем меньше кода, тем быстрее грузиться страница. Это также позволяет сохранить время и простоту понимания кода, при создании больших проектов. Другими словами, семантическая верстка - это необходимое условие создания качественного сайта.

Понятие семантической верстки

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

Как достигнуть семантики кода?

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

• Заголовки должны выделяться тегами H1, H2, H3, H4, но никак не B и STRONG.
• При создании меню лучше всего использовать UL список, внутри которого будут лежать LI элементы меню. Этим мы показываем, что ссылки равносильные. Если имеются пункты второй вложенности, соответственно создаем внутри первичного LI элемента еще один UL список.
• Все служебные картинки (иконки, стрелки, пульки…) должны быть прописаны в CSS коде. В HTML, тег IMG должен использоваться только для больших картинок. Большие, понятие растяжимое, скажем так, начиная с превьюшек 100 x 100 и выше.
• Параграф блока текста создается с помощью P тега, но никак не DIV.
• Не использовать атрибуты STYLE внутри HTML тега. Все стили выносить в отдельный CSS файл.
• То же самое по поводу JavaScript.
• Соблюдать иерархию и логику документа. Более важные элементы страницы должны стоять в начале HTML кода, менее в конце. С помощью CSS стилей и DIV блоков, этого достичь не сложно, при любой схеме шаблона.
• Может быть, еще что-то забыл… если да, поправьте меня в комментариях к статье.

Для большей ясности сути вопроса, смотрите схему семантической разметки текста:

Семантическая верстка на практике - примеры HTML + CSS кода

Теперь закрепим все эти принципы семантической верстки на практике. Будем разбирать конкретные ситуации.

Удаляем ненужные div теги

Я видел, что многие люди создают div тег около form или ul. Зачем создавать дополнительный div, который вам не нужен? Вы можете достичь такого же результата, дописав несколько указаний в CSS файле.

Пример 1:

Пример ниже показывает, как вы можете убрать div тег и дописать тот же стиль к form селектору.

Пример 2:

Иногда мы обвертываем контент в div блок, чтобы создать отступы, как показано на примере слева. Но если каждый из блоков имеет заголовок h4, мы можем просто применить margin отступ к h4 селектору и убрать лишний div тег.

Используем семантическую разметку кода

Как упоминалось ранее, вы всегда должны использовать семантическую разметку для HTML кода. Но этого нельзя достичь без CSS файла стилей.

Пример:

Картинка ниже показывает разницу между div разметкой и семантической разметкой без css стилей.

Минимизируем использование div тегов

Может быть, вы видели шаблоны, где div теги везде… они меня бесят. Имели ли вы лишний закрывающий тег /div, или не закрытый div? Я уверен, каждый верстальщик сталкивался с подобной проблемой, когда рядом стоит 3-4 div тега. Чтобы не путаться, нужно минимизировать использование div, так будет проще отслеживать ошибки.

Пример 1:

Вместо использования div для создания навигационного пути, можно использовать p тег.

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

Момент этот заключается в понимании такого важного понятия, как семантика кода . Давайте в этой заметке попытаемся разобраться с этим вопросом и зачем это все нужно.

Что такое семантика кода ?

Семантика (с лингвистической точки зрения) – это смысл, информационное содержание языка или отдельной его единицы.

Как мы знаем, структурными единицами языка HTML являются теги, они и являются теми самими отдельными единицами, которые несут смысл, информационное содержание.

Когда перед нами есть какая-то информация, которую нужно представить на веб-странице в Интернете, в первую очередь, мы должны объяснить компьютеру, какая часть этой информации, чем является. Не зная об этом, он просто не сможет правильно отобразить все содержимое.

Таким образом, когда мы создаем веб-страницу, с помощью языка HTML , мы объясняем компьютеру, какой элемент, какую роль должен играть на странице.

Мы должны понимать, что содержание каждого элемента веб-страницы должно быть заключено в теги, которые бы соответствовали их логическому и смысловому назначению.

Т.е. заголовки в тексте заключались бы в теги h 1-h 6, абзацы в теги p , списки в теги ul /ol (li ) и.т.д.

Код, который соответствует этим условиям, называют семантическим т.е. каждому элементу на веб-странице, соответствует правильное смысловое значение.

А теперь вопрос, можем ли мы заголовок на веб-странице, заключить в тег абзаца?
А почем нет? Конечно, можем. Многие скажут, но ведь при этом мы теряем оформление, которое имеют заголовки h 1-h 6. Но, на самом деле, оформление здесь никакой роли не играет. С помощью стилей CSS , мы можем присвоить любому абзацу точно такое же оформление, которое было у элемента h 1-h 6.

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

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

Поэтому, прежде чем заключать элемент в какой-либо тег, желательно подумать, а какую функцию, смысл он несет на странице?

Возникает логичный вопрос, а зачем в таком случае вообще нужна семантика кода?

Зачем заголовки делать заголовками, абзацы делать абзацами, аббревиатуры делать аббревиатурами и.т.д.?

По моему мнению, есть несколько причин, которые помогут вам склониться в сторону семантического кода. Что нам дает семантическая разметка?

1) Информацию о том, как браузеру по умолчанию отображать тот или иной элемент на странице;

Например, мы знаем, что заголовок h 1, если не задавать ему никаких специальных стилей, отображается на странице размером 2em и жирным шрифтом. Но, по моему мнению это самая не существенная причина.

2) Семантический код лучше читается и воспринимается поисковыми системами;

Считается, что страница, которая имеет семантическую разметку, при прочих равных условиях, будет выдаваться выше в результатах выдачи поисковых систем, чем страница с несемантическим кодом.

2) Код более понятный для человека;

Согласитесь, что разобраться с кодом, где все четко прописано, что эта часть текста является абзацем, эта аббревиатурой, и.т.д. намного легче, чем с кодом, где вся информация идет одной сплошной структурой и не понятно, что хотел сказать автор.

3) Проще получить доступ к элементу и как следствие большая гибкость.

Делая код семантическим, вы сможете намного проще обращаться к этим элементам с помощью специальных средств, которые работают с элементами на веб-страницах, например, языки CSS , Javascript и др.

Если вы заключите все аббревиатуры на вашей странице в тег abbr , то в CSS , для того, чтобы все аббревиатуры на вашей странице стали красными достаточно будет просто прописать.

abbr {color :red ;}

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

Это всего лишь один пример, которых можно привести массу.

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

Дело ваше!

Вы должны сами для себя принять это решение.

• Перевод

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

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

HTML 5, W3C недавно удвоило усилия по формированию нового поколения HTML, за прошедший год или около того набрал значительные темпы. Это огромны проект, который охватывает не только структуру HTML, но и разбор моделей, модели обработки ошибок, DOM, алгоритмы для извлечения ресурсов, медиа-котента, 2D графики, шаблоны данных, модели безопасности, модели загрузки страницы, хранение данных на стороне клиента и многое другое.

Так же существуют изменения в структуре, синтаксисе и семантике HTML, некоторые из них описал Lachlan Hunt в статье "Обзор HTML 5 " ().

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

BBC недавно объявила о том, что они будут снижать долю микроформата hCalendar в своей программе телепередач, в пользу доступности и удобства abbr design pattern . Это свидетельствует о том, что мы, вне всяких сомнений, вытолкнули семантические возможности HTML далеко за те пределы, которые когда-либо предназначались, и действительно это возможно для языка. Мы просто исчерпали элементы и атрибуты HTML, которые способны повысить семантику документа. Если мы будем и далее хитрить с существующими конструкциями HTML, то будет возникать все больше таких проблем. Потому что HTML страдает от фундаментального деффекта, как семантический язык разметки - его семантика фиксирована и не расширяема.

Это не просто теоретическая проблема. Сотни тысяч разработчиков используют class и id для создания более семантической разметки (они так же используют их в качестве «крючков» для CSS стилей, но это другой вопрос). Почти всегда эти разработчики используют специальные словари, значения которых они сами составляют, а не значения существующих схем. Это псевдосемантическая разметка - в лучшем случае.

Многие страницы по всему интернету используют микроформаты, что бы добавить более структурированной семантики, чем при помощи обнищавшего набора элементов и атрибутов HTML . В этом случае значения использованные для атрибута class согласованы со словарями, иногда взяты из других стандартов, такие как vCard , иногда из недавно созданных словарей, где нет жесткого существующего стандарта (как в случае с hReview).

Расширяемая семантика

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

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

Решение должно быть так же вперед-совместимым. Не в том смысле, что оно должно работать в будущих броузерах - это задача разработчиков броузеров, но оно должно быть расширяемым . Мы не можем ожидать какого-либо единого решения, которое мы сейчас разработаем, что бы решить все вообразимые и невообразимые потребности семантики в будущем. Мы можем разработать решения, которые могут быть расширены для удовлетворения будущих потребностей, по мере их возникновения.

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

Итак, как HTML 5 решит этот вопрос? HTML 5 вводит ряд новых элементов. Некоторые я назвал «структурные» - section, nav, aside, header и footer. Элемент dialog который по типу и содержанию схож с blockquote. Есть так же целый ряд элементов данных, как например meter , который представляет собой «скалярное измерение в пределах известного диапазона или дробное значение, например использование диска»; и элемент time{http://www.w3.org/html/wg/html5/#the-time}, который представляет собой дату и/или время.

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

Рассмотрим каждое препятствие

Обратная совместимость

Как современные броузеры обрабатывают эти новые элементы, такие как section? Хорошо, последние версии Safari, Opera, Mozilla и даже IE7 все делают на странице следующим образом.

< h1 > Top Level Heading
< section >
< h1 > Second Level Heading
< p > this is text in a section element
< section >
< h1 > Third Level Heading

В начале это выглядит прекрасно. Но когда мы пытаемся задать стили CSS, например, для элемента section, который выглядит следующим образом:

Section {color: red}
… Большинству из упомянутых броузеров это удается, но IE7 (и тем более 6) нет.

Поэтому у нас есть проблема обратной совместимости с 75% броузеров, использующихся в настоящее время. Учитывая, период полураспад Internet Explorer, мы можем прогнозировать, что большинство пользователей будут использовать IE6 и IE7, даже через несколько лет.

Если HTML 5 вводит новые элементы, какова вероятность, что они будут использоваться подавляющим большинством разработчиков - учитывая то, что они не совместимы с большинством используемых броузеров?

Давайте обратимся к совместимости снизу вверх, это следующая проблема.

Совместимость снизу вверх

Сначала мы поставим вопрос: «Зачем мы изобретать эти новые элементы?». Разумным ответом будет: «Потому что не хватает семантики в HTML, а добавление этих элементов мы увеличим семантику HTML, что не может быть плохим, или может?».

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

Таким образом HTML 5 выполняет функцию, которая убьет значительный процент современных броузеров и не позволяет добавить семантики языка вообще.

Остаюнся несколько вопросов о новых элементах. Откуда взяты названия новых элементов? Как было решено, что элемент навигации нужно называть «nav»? Зачем в навигации применяются термины page-level, site-level и meta-site-level?

Почему бы не принять существующий словарь, такой как DocBook ? Его словарь структуры документа более богат, он был разработан путем публикаций экспертов, на протяжении многих лет. Это не является аргументом в пользу DocBook, а дело в том, что чрезвычайно важная задача подготовки механизма обеспечения семантикой HTML проходит путь, уделяя малое внимание практике в работе которая началась более 30 лет назад. (Оригинал работы по GML начался в начале 1970-х годов)

Некоторые идеи решения

И так, имее чрезвычайно важное значение нынешних усилий, у меня есть некоторые практические рекомендации, как решить эту проблему. Ну, я начал с одного.

Если добавление новых элементов не обсуждается, по крайней мере в этой дискуссии, атрибуты - другая логическая область HTML, сконцентрируемся на ней. В конце концов, мы на протяжении, почти, десяти лет использовали атрибуты class и id, как механизмы расширения семантики HTML. Многие разработчики уже знакомы с этим и чувствуют себя комфортно. Проект microformats показал, что существующих атрибутов не достаточно, для использования их как механизм расширения семантики HTML. Так что, если мы хотим использовать атрибуты для решения проблемы, мы должны ввести один или более новых атрибутов. Пред тем, как перейти к механики, того как это может работать, справедливо подвергнуть это предложение тем же требованиям, как и новые элементы в HTML 5. Самое главное во внедрении новых атрибутов - это будет ли обратная совместимость HTML. Если да, то обеспечивает ли это работоспособный механизм расширения семантики в HTML?

Давайте изобретем новый атрибут. Назовем его «structure», но название не важно. Мы можем использовать его так: