Что такое семантика и как это относится к HTML? Зачем и кому вообще нужна семантическая верстка? Распространенные теги HTML5 для семантической верстки.
Я хочу сделать смелый прогноз. После того как вы и я исчезнем, HTML по-прежнему будет вокруг. Не только в миллиардах архивных страницах нашей эры, но, как живой, дышащий организм. Слишком много сил, энергии и инвестиций пошли в разработку инструментов Интернета, протоколов и платформ для того, чтобы от этого так легко отказаться.
Давайте остановимся на нашей ответственности. К сожалению, в истории мы связаны с развитием важного инструмента нашей цивилизации, который будет использоваться для коммуникации на десятилетия вперед. Таким образом, когда мы направляем наш разум, праздно или всерьез, на улучшение HTML, мы должны понимать уже сегодня последствия далеко идущих решений.
HTML5, над которым W3C недавно удвоил свои усилия по формированию следующего поколения HTML, развил значительный импульс. Это огромный проект, охватывающий не только структуру HTML, но и модель парсинга, обработку ошибок, DOM, алгоритмы извлечения ресурсов, медиа-контент, двумерную графику, шаблоны данных, безопасность, страницы загрузки, хранение данных на стороне клиента и многое другое.
Есть также изменения в структуре, синтаксисе и семантике HTML, которые частично описал Лаклан Хант в статье .
Но в этой статье давайте обратимся исключительно к семантике HTML. Она интересует меня уже много лет и считаю, что семантика принципиально важна для будущего HTML.
Би-би-си недавно объявила, что отказывается от микроформата hCalendar используемого в их списках передач в пользу удобного и доступного шаблона сокращений . Это свидетельствует о том, что мы, вне всякого сомнения, вышли за пределы семантических возможностей HTML, которые были предназначены для этого языка. У нас просто закончились элементы и атрибуты HTML, которые обогащают семантическую разметку документов. Если мы продолжим хитрить с существующими конструкциями HTML, возникнет много проблем, потому что HTML как семантический язык разметки страдает от фундаментального дефекта - его семантика фиксирована и не расширяема.
Это не просто теоретическая проблема. Сотни тысяч разработчиков используют атрибуты class
и id
для создания расширенной семантической разметки. При этом практически неизменно разработчики используют специальные словари, которые они сами же составляют, а не значения, взятые из существующих схем. В лучшем случае это псевдосемантика.
Многие страницы в Интернете используют микроформаты, чтобы добавить больше структурированной семантики, чем имеющийся бедный набор HTML-элементов и атрибутов. В этом случае, значения, используемые для атрибута class
, устанавливаются из согласованных словарей, иногда взятых из других стандартов, таких как vCard, а иногда из новоиспеченных словарей, где нет твердого стандарта (как в hReview).
Расширяемая семантика
Существует реальная проблема, которая должна быть решена. Нам нужны механизмы в HTML, которые чётко и однозначно позволят разработчикам добавлять в разметку более существенную семантику, а не псевдосемантику. Это, пожалуй, одна из важных целей проекта HTML5.
Но придумать такой механизм не так просто, потому что в любом решении имеются ограничения. Есть существенные ограничения, возможно, самым большим из них является обратная совместимость. Решение не должно ломать сотни миллионов используемых сегодня устройств, и которые будут использоваться ещё долгие годы. Любое решение без обратной совместимости не будет широко принято разработчиками из страха потерять читателей. Такие решения быстро вянут на корню.
Решение также должно быть совместимо и с будущими версиями. Не в том смысле, что оно должно работать в будущих браузерах - это ответственность разработчиков браузеров, но оно должно быть расширяемым. Мы не можем ожидать какого-либо единого решения, которое разрабатывается прямо сейчас, чтобы решить все мыслимые и немыслимые будущие семантические потребности. Мы можем разработать решение, которое удовлетворит расширяющиеся потребности по мере их возникновения.
Этот тандем двух ограничений является настоящей огромной проблемой. Но в контексте языка, основные итерации которого повторяются десятилетиями и важность которого в качестве глобальной платформы для коммуникации имеет первостепенное значение, эта задача должна быть решена.
Итак, как HTML5 решет этот вопрос? HTML5 вводит ряд новых элементов, некоторые из них я назвал «структурными» -
,
Хотя эти элементы могут быть полезными и, похоже, вызвали некоторый интерес, решают ли они действительно проблему, в частности обратной совместимости и совместимостью с будущими версиями?
Давайте рассмотрим каждое ограничение.
Обратная совместимость
Как современные браузеры обрабатывают новые элементы вроде
? Ну, самые последние версии Safari, Opera, Mozilla и даже IE7 будут отображать все страницы так.
Заголовок верхнего уровня
Заголовок второго уровня
это текст внутри section
Заголовок третьего уровня
Похоже, отличное начало. Но когда мы пытаемся установить, к примеру, такой стиль для элемента
:
Section {color: red}
Большинство упомянутых браузеров изменило стиль элемента, но IE8 (а также IE6–7) нет.
Итак, мы имеем серьёзную проблему обратной совместимости с 75% используемых в настоящее время браузеров. Учитывая период полураспада Internet Explorer, мы можем предсказать, что большинство пользователей будут использовать IE6 и IE7 даже спустя несколько лет.
Если HTML5 вводит новые элементы, какова вероятность того, что они будут применяться большинством разработчиков с учетом того, что они по существу несовместимы с большинством браузеров?
К сожалению, если вы увидите альтернативное решение проблемы CSS в том, чтобы включить атрибут class
в элемент
, а затем попробовать изменить стиль с помощью класса, то это не будет работать в IE. Возможно, есть обходной путь, но если нет, на этом все дела заканчиваются.
Давайте обратимся ко второму ограничению - совместимость с будущими версиями.
Совместимость с будущими версиями
Начнём с постановки вопроса: «Зачем изобретать новые элементы?». Разумным ответ на него будет: «Потому что в HTML не хватает семантического богатства, а добавив эти элементы, мы увеличиваем семантическое богатство HTML - что не плохо, не так ли?».
При добавлении этих элементов мы стремимся, чтобы в HTML было больше семантических возможностей, но только в узкой области. Независимо от того, сколько элементов введено, мы всегда будем думать о добавлении в HTML больше семантики. Добавив столько новых элементов, сколько нам хочется, мы по-прежнему не решим проблему. Нам не нужно добавлять определенные термины
в словарь HTML, нам необходимо добавить механизм, который позволит обогащать документ семантикой по мере необходимости. С технической точки зрения мы должны сделать HTML расширяемым. В HTML5 никакого механизма для расширения нет. Именно поэтому HTML5 угробит значительный процент современных браузеров и в реальности не добавляет семантику вообще.
Почему бы не принять существующий словарь, тот же Docbook ? Его словарь структуры документа гораздо богаче и он разрабатывался рядом экспертов в течение многих лет. Однако это не является аргументом в пользу Docbook, дело в том, что задача обеспечения механизма семантического богатства в HTML идёт своим путём, уделяя мало внимания передовой практике в отношении работ тридцатилетней давности (исходная работа началась в начале 70-х годов).
Некоторые соображения по поводу решения
Критикуя нынешние усилия, есть ли у меня какие-то практические советы о том, как решить эту проблему? Ну, начну с одного.
Если добавление элементов в HTML находится за рамками темы, по крайней мере, в этой дискуссии, атрибуты это другая логическая область HTML, на которой мы сосредоточимся. В конце концов, в течение почти десятилетия мы использовали атрибуты class
и id
в качестве механизмов расширения семантики HTML. Множество разработчиков знакомы с этим подходом, и он их устраивает. Проект микроформатов показал, что существующих атрибутов HTML недостаточно для универсального механизма по расширению семантики HTML. Таким образом, если мы хотим использовать атрибуты чтобы помочь решить эту проблему, мы должны включить один или несколько новых атрибутов. Прежде чем перейти к механизму о том, как это работает, проверим это решение на те же требования, что и для новых элементов HTML5. Самое главное, поддерживают ли новые атрибуты HTML обратную совместимость? И если да, обеспечит ли это реальный механизм для семантического расширения HTML?
Давайте внедрим новый атрибут. Я назову его «structure», но конкретное имя не имеет значения. Мы можем использовать его так:
Посмотрим, как наши браузеры справятся с ним. И конечно все браузеры должны изменить его стиль через CSS.
Div {color: red}
Но как это сделать?
Div {font-weight: bold}
В действительности, почти все браузеры, включая IE7, стилизуют
с атрибутом structure
, даже если такого атрибута не существует! К сожалению, наше счастье на этом заканчивается, т.к. IE6 этого не делает. Но мы можем использовать атрибут в HTML, и все существующие браузеры признают его. Мы даже можем использовать CSS для стилизации нашего HTML с помощью атрибута во всех современных браузерах. И если мы хотим обойти старые браузеры, мы можем добавить к элементу значение класса для управления его стилем. Сравните это с решением в HTML5, который добавляет новые элементы, и которые не могут быть стилизованы в Internet Explorer 6 или 7 и вы увидите, что это решение, определенно, обратно совместимо лучше.
Расширяемость с помощью атрибутов
Вместо новых элементов, HTML5 должен принять ряд новых атрибутов. Каждый из этих атрибутов будет входить в категорию или тип семантики. Например, как я , HTML включает структурную семантику, риторическую семантику, ролевую семантику (взята из XHTML) и другие классы или категории семантики.
Эти новые атрибуты могут быть использованы так же, как атрибут class
: для подключения к элементу семантики, которая описывает характер элемента, а также для добавления метаданных об элементе.
Это не отличается от атрибута role в XHTML , но вместо того, чтобы один атрибут «отдувался» за все семантические элементы, мы должны определить различные типы семантики элемента и разделить их.
Например, атрибут role в XHTML работает следующим образом:
Скачать
Документация
Новости
Значения атрибута role
это разделенный пробелами список слов из словаря по умолчанию или из определенного словаря.
Почему бы просто не взять атрибут role
как есть? Ну, есть другие виды семантики, для которых словарь ролей неприменим. Например:
Он фантастический человек.
Здесь показан теоретический тип семантики - «rhetoric», который может быть использован для разметки риторического характера документа. Этот элемент, очевидно, не играет роли иронии в документе. Скорее, содержит элемент иронии.
Вот еще один пример. Очевидно, что в HTML не хватает способа прикрепить версии для машинного чтения к версии для чтения человеком, например, дате. Это лежит в основе проблемы Би-би-си с микроформатом hCalendar, о которой мы говорили ранее. Хотя Первого мая следующего года действительно не несёт смысла, нечто вроде строки Первого мая следующего года появится.
Опять же, будем ли мы использовать определенный термин «equivalent» или какой-либо другой термин для этого семантического атрибута не важно. Главное отметить, что это не так просто, как использование одного атрибута class
или role на все случаи. Для правильного расширяемого решения, которое обеспечивает обратную совместимость и достаточную гибкость, решения в этом направлении заслуживают изучения.
Я назвал этот раздел «Некоторые соображения по поводу решения», поскольку нужно сделать значительный объем работы, чтобы действительно добиться приемлемого решения. Открытые вопросы включают следующее.
Сколько разных семантических атрибутов должно быть? Расширяются ли категории и если да, то как?
Как определяются словари?
Мы просто изобретаем желаемые термины подобно тому, как используется атрибут class
или возможные значения должны определяться стандартной спецификацией? Или должен быть механизм для внедрения (и надеюсь обмена) словарями с помощью какого-то профиля?
Если возникает конфликт между двумя словарями вроде двух одинаковых терминов в разных словарях, как он разрешается?
Требуется ли пространство имён или другой подобный механизм?
Вместо того чтобы спешить ответить на эти вопросы, я выделю проблемы, которые необходимо решить и начну диалог. Последствия и влияние решений сделанных в HTML5 слишком велики для решений, которые будут сделаны без хорошей осведомлённости о лингвистике, семантике, семиотики и смежных областях.
Надеюсь понятно, что просто «создание новых элементов» не является решением для роста семантической мощи HTML.
Давайте несколько не будем спешить с этими решениями, в конце концов, изменением климата мы озаботили наших внуков достаточными проблемами. Пусть, по крайней мере, мы оставим им наилучший HTML какой сможем.
Что такое семантика в HTML
Слово «семантики» пришло в HTML из обычных лингвистических (языковедческих) дисциплин. Там, под понятием «семантика» понимаются разделы, изучающие значение и назначение человеческих языковых единиц. В отличие от реальных человеческих языков, в HTML языковые единицы изучать не нужно. В HTML, языковые единицы называются «тегами» и их назначение уже прописано в спецификации HTML - едином для всех веб-разработчиков документе. На данный момент, существует несколько вариаций на тему спецификации HTML (в зависимости от версии языка), но суть не в этом. Сейчас, нас и этой статьи - важно другое. Это наличие чёткого и внятного объяснения для каждой языковой единицы - тега HTML, в соответствующей спецификации HTML. Таким образом, если в реальной лингвистике человеческих языком, семантика - это изучение назначения непонятных слов и понятий, то в HTML наоборот, семантика - это правильное применение и использование уже готовых и объяснённых тегов.
Семантическая вёрстка веб-документа
Семантическая вёрстка веб-страницы или семантический код HTML-документа - это вёрстка с правильным использования HTML-тегов в соответствии с их предназначением (семантикой). Кроме этого, семантическая вёрстка предполагает логичную и последовательную иерархию для построения всей веб-страницы, в соответствии с законами HTML-документа.
Чем отличается семантическая вёрстка от обычной Семантическая вёрстка веб-документа противопоставляется обычной, при котором написание HTML-кода определяется только внешним видом веб-страницы. При семантической вёрстке, ряд элементов страницы имеют свои собственные теги, которые прямо отображают их назначение. Это и есть «семантика» в HTML. Так, например, структура простейшей веб-страницы при обычной вёрстке может выглядеть так:
Тогда, как при семантической вёрстке, структура той же самой веб-страницы будет иметь вид: Шапка сайта
Содержимое веб-страницы
Как видно из примера, для обозначения и задания соответствующих стандартных элементов веб-страницы использованы соответствующие теги. Кроме этого, код гораздо проще. При этом, внешний вид такой страницы для человеческого глаза - останется абсолютно неизменным. Возникает резонный вопрос - а зачем тогда нужна семантическая вёрстка и разметка веб-страницы, если людям она не видна?
Зачем нужна семантическая вёрстка
Семантическая вёрстка и разметка веб-страницы видна браузеру и роботам. Семантическая вёрстка и разметка позволяет более точно определять значимость отдельных элементов веб-страницы и всего текста в целом Поэтому, прежде всего - семантическая вёрстка нужна для улучшения робото-функционала сайта и, как следствие - лучшей его поисковой индексации. А, не об этом-ли, мы все мечтаем?
Семантическая вёрстка в HTML5
Полный фурор и переворот понятия веб-семантики произошёл с появлением HTML5.
В HTML4 всё было довольно просто. Для оформления веб-страниц, написанных в соответствии с семантикой, достаточно было использовать внешние каскадные таблицы стилей (CSS) да пару нехитрых нововведений, вида замены тегов и на и . HTML5 - не в пример «семантичней» и это видно из приведённого примера.
Новые популярные семантические теги HTML5
Прежде всего, - простой и понятный всем доктайп.
Проблемы совместимости HTML5 и XHTML
Принципиально, в совместимости HTML5 и XHTML - проблем нет никаких. Все новые браузеры прекрасно поддерживают теги HTML5 и выполняют их. Единственное огорчение ждёт любителей валидного кода. Потому что, большинство сайтов свёрстано не HTML, а в XHTML. И теперь, получается странная ситуация - доктайп от XHTML, а теги из HTML5. Валидатор «вешается и пишет красным». В настоящий момент, на такую «нестыковку» все закрыли глаза. А что делать? Ведь XHTML всегда был только производным языком от HTML.
Так что основной веб-язык, это всё-таки HTML5. В ближайшее время, проблемы совместимости HTML5 и XHTML, скорей всего будут решаться, либо простым игнорированием вопроса в пользу HTML5, либо простым добавлением тегов HTML5 в спецификацию XHTML. В любом случае, это будет простое решение, без фундаментальной перестройки положения вещей. Уж слишком он выстрадан, этот HTML5, чтобы теперь ещё всерьёз начинать возиться с XHTML5.
Плавный переход шаблона с XHTML на HTML5
Как утверждают специалисты, HTML5 - это не одна большая вещь, это набор разных возможностей. Поэтому, начинать переходить с XHTML на HTML5 можно постепенно, по частям добавляя нужный код в свой шаблон. Валидатор XHTML ругнётся и всё вскорости образуется. Ведь всем остальным - «по барабану», теги HTML5 работают везде и вся. Для начала, можно изменить общую структуру своего шаблона, простой заменой классов CSS на семантические теги из примера «Чем отличается семантическая вёрстка от обычной».
HTML5 | Семантическая разметка сайта
(Главное - начать) Опять-же таки, как утверждают известные специалисты - «обновление» до HTML5 можно сделать простым изменением доктайпа. Элемент в HTML5 имеет предельно простой вид: . После такого «обновления», ровным счётом ничего не произойдёт, потому что все теги, определённые в HTML4, также поддерживаются и в HTML5. Что касаемо перехода с XHTML на HTML5, то тут я не рискнул на своём сайте так резко менять , решился только на постепенную замену части тегов да изменение структуры страницы.
Семантика и доступность - это естественные части HTML по замыслу, однако они не используется в полной мере, если не применяются правильно. Знание, как писать семантический и доступный код правильно начинается с понимания того, как семантика и доступность работают и как пользователи и машины их интерпретируют. Писать семантический и доступный код невероятно сложно и это может занять много времени. Однако в долгосрочной перспективе преимущества побеждают.
Одна из наиболее важных частей, о которой следует помнить при написании семантического и доступного кода - это сделать всё возможное, чтобы использовать стандартный язык разметки. Приложите усилия, чтобы по возможности писать чистый код и гордитесь своей работой. Вообще говоря, не используйте бессмысленный элемент там, где другой элемент может придать более семантический смысл, к примеру, использование
там, где
подходит лучше. Используйте семантические элементы и атрибуты, а также микроданные и WAI-ARIA, чтобы расширить значение вашего кода.
Кроме того, будьте адвокатом семантики и доступности
. Расскажите, почему вы написали определённый код и дайте обоснование, почему некоторые модули содержимого размечены таким образом. Обозначьте цели и задачи в вашем коде и объясните, как эти цели и задачи выполняются. Практика написания семантического и доступного кода растёт, однако внедрение в целом ещё не завершено. Будьте адвокатом для кода, который вы пишете.
Мотивация для семантики
Иногда можно спросить, реально ли семантика изменит ситуацию. Вы можете услышать, что она замедляет разработку, плохо поддерживается или даже что она своевольна. Хотя это иногда и так, вам по-прежнему необходимо сохранить целостность и продолжить писать по возможности лучший код, потому что семантика вкладывает больший смысл в написании кода.
Важным фактом является то, что семантика в значительной степени полезна всем . Для начинающих семантика наделяет содержимое однозначным смыслом. Семантика придаёт содержимому устойчивую структуру и значение, а также в угоду доступности предоставляет более качественный пользовательский интерфейс и дополнительную информацию для вспомогательных технологий. Поиск и глобализация в большей степени связаны с семантикой, что позволяет проще обслуживать контент на международном уровне и делает его более дружественным поисковой системе. Если это недостаточно, семантика также способствует совместимости операционных систем, что позволяет обмениваться и пользоваться информацией на различных платформах и устройствах.
Можно с уверенностью сказать, что семантика важна и она здесь надолго. Если кратко подытожить, семантика обеспечивает:
однозначный смысл для содержимого;
доступность;
поиск и глобализацию;
совместимость.
Структурная семантика
В руководстве для начинающих мы обсудили использование структурной семантики , в частности, применение элементов
,