HTML: Семантическая верстка. Что такое семантика и как это относится к HTML
Иллюстрации: Кевин Корнелл
Перевод: Влад Мержевич
Я хочу сделать смелый прогноз. После того как вы и я исчезнем, 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 вводит ряд новых элементов, некоторые из них я назвал «структурными» -
Хотя эти элементы могут быть полезными и, похоже, вызвали некоторый интерес, решают ли они действительно проблему, в частности обратной совместимости и совместимостью с будущими версиями?
Давайте рассмотрим каждое ограничение.
Обратная совместимость
Как современные браузеры обрабатывают новые элементы вроде
Заголовок верхнего уровня
Заголовок второго уровня
это текст внутри section
Заголовок третьего уровня
Похоже, отличное начало. Но когда мы пытаемся установить, к примеру, такой стиль для элемента
Section {color: red}
Большинство упомянутых браузеров изменило стиль элемента, но IE8 (а также IE6–7) нет.
Итак, мы имеем серьёзную проблему обратной совместимости с 75% используемых в настоящее время браузеров. Учитывая период полураспада Internet Explorer, мы можем предсказать, что большинство пользователей будут использовать IE6 и IE7 даже спустя несколько лет.
Если HTML5 вводит новые элементы, какова вероятность того, что они будут применяться большинством разработчиков с учетом того, что они по существу несовместимы с большинством браузеров?
К сожалению, если вы увидите альтернативное решение проблемы CSS в том, чтобы включить атрибут class
в элемент
Давайте обратимся ко второму ограничению - совместимость с будущими версиями.
Совместимость с будущими версиями
Начнём с постановки вопроса: «Зачем изобретать новые элементы?». Разумным ответ на него будет: «Потому что в 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, стилизуют
Расширяемость с помощью атрибутов
Вместо новых элементов, HTML5 должен принять ряд новых атрибутов. Каждый из этих атрибутов будет входить в категорию или тип семантики. Например, как я , HTML включает структурную семантику, риторическую семантику, ролевую семантику (взята из XHTML) и другие классы или категории семантики. Эти новые атрибуты могут быть использованы так же, как атрибут class : для подключения к элементу семантики, которая описывает характер элемента, а также для добавления метаданных об элементе.
Это не отличается от атрибута role в XHTML , но вместо того, чтобы один атрибут «отдувался» за все семантические элементы, мы должны определить различные типы семантики элемента и разделить их. Например, атрибут role в XHTML работает следующим образом:
Значения атрибута role это разделенный пробелами список слов из словаря по умолчанию или из определенного словаря.
Почему бы просто не взять атрибут role как есть? Ну, есть другие виды семантики, для которых словарь ролей неприменим. Например:
Он фантастический человек.
Здесь показан теоретический тип семантики - «rhetoric», который может быть использован для разметки риторического характера документа. Этот элемент, очевидно, не играет роли иронии в документе. Скорее, содержит элемент иронии.
Вот еще один пример. Очевидно, что в HTML не хватает способа прикрепить версии для машинного чтения к версии для чтения человеком, например, дате. Это лежит в основе проблемы Би-би-си с микроформатом hCalendar, о которой мы говорили ранее. Хотя Первого мая следующего года действительно не несёт смысла, нечто вроде строки Первого мая следующего года появится.
Опять же, будем ли мы использовать определенный термин «equivalent» или какой-либо другой термин для этого семантического атрибута не важно. Главное отметить, что это не так просто, как использование одного атрибута class или role на все случаи. Для правильного расширяемого решения, которое обеспечивает обратную совместимость и достаточную гибкость, решения в этом направлении заслуживают изучения. Я назвал этот раздел «Некоторые соображения по поводу решения», поскольку нужно сделать значительный объем работы, чтобы действительно добиться приемлемого решения. Открытые вопросы включают следующее.
- Сколько разных семантических атрибутов должно быть? Расширяются ли категории и если да, то как?
- Как определяются словари?
- Мы просто изобретаем желаемые термины подобно тому, как используется атрибут class или возможные значения должны определяться стандартной спецификацией? Или должен быть механизм для внедрения (и надеюсь обмена) словарями с помощью какого-то профиля?
- Если возникает конфликт между двумя словарями вроде двух одинаковых терминов в разных словарях, как он разрешается?
- Требуется ли пространство имён или другой подобный механизм?
Вместо того чтобы спешить ответить на эти вопросы, я выделю проблемы, которые необходимо решить и начну диалог. Последствия и влияние решений сделанных в HTML5 слишком велики для решений, которые будут сделаны без хорошей осведомлённости о лингвистике, семантике, семиотики и смежных областях. Надеюсь понятно, что просто «создание новых элементов» не является решением для роста семантической мощи HTML. Давайте несколько не будем спешить с этими решениями, в конце концов, изменением климата мы озаботили наших внуков достаточными проблемами. Пусть, по крайней мере, мы оставим им наилучший HTML какой сможем.
И судя по тем рассуждениям, которые были в комментариях, мне бы хотелось прояснить один важный момент, который нужно понимать, прежде чем говорить о языке 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 выделять и прописывать это правило к каждой отдельно взятой аббревиатуре.
Это всего лишь один пример, которых можно привести массу.
По этим причинам нужно понимать, что семантический код просто дает нашему документу больше возможностей. Мы можем применять какие-то теги для улучшения семантики сайта и получать при этом большую функциональность, либо их не применять и не получать эти выгоды.
Дело ваше!
Вы должны сами для себя принять это решение.
В этой статье вы узнаете как пользоваться семантической разметкой в HTML5 и как это делать правильно.
Что такое семантический HTML5?
Если вы более менее знакомы с HTML, то вы должны знать про HTML теги, которые в большинстве своём используются для форматирования контента - они говорят браузеру как показывать контент на странице. Они не дают определение типу содержащегося контента или какую роль играет контент на странице.
Семантический HTML5 устраняет этот недостаток, определяя точные теги для пояснения четкой роли контента на странице. Эта дополнительная информация помогает роботам/индексаторам, таким как Google и Bing лучше понять какой контент важен, какой является второстепенным, какой используется для навигации и так далее. Добавляя семантические HTML теги на ваши страницы, вы даете дополнительную информацию, которая помогает поисковикам понимать роли и относительную важность разных частей ваших страниц.
Примеры
Это примеры не семантических HTML элементов. Они служат как хранители для передачи браузеру того, как контент должен отображаться. Они не дают информации о роли содержимого контента на странице.
А это семантические элементы. Они ясно определяют роль содержимого контента.
Почему надо это использовать?
Для внимательного пользователя обычно легко определить различные части веб-страницы с первого взгляда. Заголовки, меню и основной контент - все мгновенно, визуально очевидно. А теперь представьте, что вы слепы.
Google и Bing боты, если и не слепы, то имеют серьёзное ослабление со зрением. Для них визуальные пояснения феноменально сложно увидеть и понять.
Им нужна ваша помощь. Если вы можете успешно передавать поисковикам, какая часть страницы является хедером, какая подвалом и какая навигацией, то они поблагодарят вас. Самое важное, говорить им какая часть контента самая важная, делая это вы даете им расширенные инструкции по приоритезации вашего же контента.
Most important content - самый важный контент
Само по себе, использование HTML5 не произведет революции в работе вашего SEO. Как вы знаете, успешное SEO это совокупность многих и многих мелких деталей. И это одна из таких малых деталей, которая улучшит понимание контента вашего сайта со стороны любого поисковика, что заметно внесет вклад в ваши SEO усилия.
Смотря наперед, учитывая как будет развиваться поисковая оптимизация в предстоящие года, расширенный и связная коммуникация с этими системами будет одним из двух краеугольных камней вашей SEO/AEO стратегии.
Как всё это выглядит?
Примеры семантических HTML тегов включают в себя
Следующие HTML5 теги могут использоваться вместо
Ясная установка границ и подробная расстановка атрибутов ролей для каждой части контента, делает страницу горазду понятнее и легче для правильно индексации для Google и Bing.
Обратите внимание, что эти теги ведут себя как
Примеры семантического HTML5
Супер простой семантический HTML5 пример:
Тут мы довольно просто определяем, какую роль играет каждая часть страницы. Когда вы начинаете разметку HTML5, то вот как безопаснее всего это начать - header, nav, main, footer.
Лучше иметь супер простое исполнение, которое на 100% верное, чем сложное, но неверное.
При неверном исполнении, вы посылаете противоречащие и сбивающие с толку с толку сигналы, которые сделают только хуже, а не лучше.
Правильное и простое выполнение это уже большой шаг вперед в ваших коммуникациях с поисковиками. Не будьте чрезмерно амбициозными. Сделаете неправильно и вы можете получить больше проблем, чем решите.
Более сложные примеры
Использование секций и
Тут мы сделали иерархическую систему в нашем главном контенте. Тут есть охватывающая всё
Примите к сведению, что дизайн (оранжевые блоки) не используется для определения семантических зон страницы. Выглядит немного сбивающим с толку, но показывает довольно четко, что шаблон HTML и семантический HTML имеют разные роли.
В реальном же мире, семантическая разметка часто следует за основной разметкой более явно, чем в этом примере. Запомните главное правило: Секция формирует часть чего-то ещё, а
Связанный Aside
Тут мы добавили две части связанного контента к главной
Косвенно связанный aside
Обратите внимание, что aside не обязательно быть сайдбаром рядом с основным контентом. Он также может быть применен для блоков под основным контентом, включая в себя заголовок, текст и ссылку на другую страницу.
Тут мы определили несколько косвенно связанного контента на странице, за пределами основного
Наша финальная версия
Это очень обсуждаемая тема. И нет четких правил о и
Личный совет. Я заметил, что вложенные секции внутри
Вложенные элементы
Элементы могут вкладывать в себя другие элементы. Для примера,
Как упоминалось выше, для SEO целей, вам нужно сконцентрироваться на создании четкого и простой структуры.
Чего НЕ ДЕЛАТЬ
Просто предупреждаю. Я видел много сайтов, использующих визуальный дизайн как руководство для применения HTML5. Как показано ниже, это не то для чего разработан семантический HTML5.
Этот необычайно простой пример просто дублирует визуализацию шаблона. Более чем бессмысленно, он определяет то, что страница состоит из 4 разных тем, вместо одной главной темы и 3-х подтем. Явно давая вводящую в заблуждение информацию для поисковиков, такая схема будет иметь негативное влияния для своего понимания в целом.
Следующие шаги?
Применение семантического HTML5 на ваших страницах значительно улучшит передачу информации для поисковиков. Так как они хотят то, о чем вообще ваш сайт. Они хотят чтобы вы ясно говорили им на понятном им языке и они хотят, чтобы вы обучали их. По-этому делайте это.
Общение
Общение с поисковиками (HTML5 имеет важную роль) это одна из двух колон долгосрочной SEO стратегии, которая приведет к успеху в мире где нам нужно будет оптимизироваться для поисковых систем. Есть много отличных вещей, которые вы можете сделать для улучшения подобного общения. И семантический HTML5 тому пример. Schema разметка это ещё один пример.
Надежность
Вторая колонна это надежность. Есть также клевые вещи, делая которые вы усилите доверие к себе. Все SEO и AEO сходятся к общению и надежности.
В завершение: памятка для хорошей HTML5 SEO разметки
Структура, важность, роли и иерархичность это вещи, которые люди часто понимают инстинктивно в дизайне шаблона. Правильное использование семантического HTML5 вместо
Если вы тот, кто использует 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 в тегах, классах, ID, и атрибутах, которые описывают назначение, но не задают точно содержание, которое в них заключено. То есть речь идет о разделении содержания и его формата.
Начнем с очевидного примера.
Плохая семантика кода
Хорошая семантика кода
Текст статьи, который кем-то написан.
Инко Гнито - ее автор.Заголовок статьи
Вне зависимости от того, считаете ли вы, что HTML5 готов к использованию или нет, наверняка использование тега Но не все так четко представляется тегами HTML5. Давайте рассмотрим набор имен классов и разберемся с тем, отвечают ли они требованиям семантики. Не семантический код.
Это классический пример. Каждая рабочая среда CSS для модульной сетки использует такого типа имена классов для определения элементов сетки. Будет ли это "yui-b", "grid-4", или "spanHalf" - такие имена ближе к заданию разметки, чем к описанию содержания. Однако их использование в большинстве случаев неизбежно при работе с шаблонами модульных сеток. Семантический код.
Нижний колонтитул (footer
) приобрел устойчивое значение в веб дизайне. Это нижняя часть страницы, которая содержит такие элементы как повторяющаяся навигация, права использования, информацию об авторе и так далее. Данный класс определяет группу для всех этих элементов без их описания. Если вы перешли к использованию HTML5, то лучше применять элемент Не семантический код.
Он точно определяет содержание. Но почему текст должен быть большим? Чтобы выделяться среди другого более мелкого текста? "standOut
" (выделение) больше подходит в данном случае. Вы можете решить изменить стиль для выделяющего текста, но ничего не делать с его размером, и в таком случаем название класса может привести вас в замешательство. Семантический код.
В данном случае речь идет об определении уровня важности элемента в интерфейсе приложения (например, параграфа или кнопки). Элемент с более высоким уровнем может иметь яркие цвета и больший размер, а элементы с низким уровнем могут содержать больше содержания. Но точного определения стилей в данном случае нет, поэтому код является семантическим. Данная ситуация очень похожа на использование тегов Семантический код.
Если бы каждое имя класса можно было так четко определить! В данном случае мы имеем описание раздела, который имеет содержание, назначение которого легко описать, также как и "tweets", "pagination" или "admin-nav". Не семантический код.
В данном случае речь идет о задании стиля для первого параграфа на странице. Такой прием используется для привлечения внимания читателей к материалу. Лучше использовать имя "intro", в котором отсутствует упоминание элемента. Но еще лучше использовать селектор для таких параграфов, например article p:first-of-type или h1 + p . Не семантический код.
Это очень обобщенное имя класса, которое используется для организации форматирования элементов. Но в нем нет ничего, чтобы касалось описания содержания. Различные теоретики семантики рекомендуют в таких случаях использовать имя класса наподобие "group". Вполне вероятно, что они правы. Так как данный элемент, несомненно, служит для группирования нескольких других элементов, и рекомендуемое название будет лучше описывать его назначение без погружения в детали. Не семантический код.
Слишком детальное описание формата содержания. Лучше подобрать другое имя, которое будет описывать содержание, а не его формат. Семантический код.
Класс очень хорошо описывает статус содержания. Например, сообщение об успешном завершении операции может иметь совершенно другой стиль от сообщения об ошибке. Не семантический код.
В данном примере имеется попытка задать определение формата содержания, а не его назначения. "plain-jane" очень похоже на "normal" или "regular". Идеальный код CSS должен быть написан так, чтобы не возникало необходимости в именах класса наподобие "regular", которые описывают формат содержания. Не семантический код.
Такого типа классы обычно используются для определения элементов сайта, которые не должны включаться в цепочку ссылок. В данном случае лучше использовать что-то наподобие rel=nofollow для ссылок, но не класс для всего содержания. Не семантический код.
Здесь имеется попытка описать формат содержания, а не его назначение. Допустим, что у вас на сайте есть две статьи. И вы желаете задать им разные стили. "Обзоры фильмов" будут иметь голубой фон, а "Горячие новости" - красный фон и шрифт большего размера. Один из способов решить задачу такой: Другой способ такой: Наверняка, если опросить нескольких разработчиков о том, какой код более соответствует требованиям семантики, большинство укажет на первый вариант. Он отлично соответствует материалу данного урока: описание назначение без ссылок на форматирование. А второй вариант указывает на формат ("blueBg" - имя класса, которое сформировано из двух английских слов, означающих "голубой фон"). Если вдруг будет принято решение поменять дизайн обзоров фильмов - например, сделать зеленый фон, то имя класса "blueBg" превратится в кошмар разработчика. А имя "movie-review" позволит абсолютно спокойно изменять стили оформления с сохранением отличного уровня поддержки кода. Но никто не утверждает, что первый пример лучше во всех без исключения случаях. Допустим, что определённый оттенок синего используется во многих местах на сайте. Например, он является фоном для некоторой части нижнего колонтитула и областей в боковой панели. Вы можете воспользоваться следующим селектором: Movie-review,
footer > div:nth-of-type(2),
aside > div:nth-of-type(4) {
background: #c2fbff;
} Эффективное решение, так как цвет определяется только в одном месте. Но такой код становится сложным для поддержки, так как имеет длинный селектор, сложный для визуального восприятия. Также потребуются другие селекторы для определения уникальных стилей, что приведет к повторению кода. Или вы можете использовать другой подход и оставить их разделёнными: Movie-review {
background: #c2fbff;
/* Определение цвета */
}
footer > div:nth-of-type(2) {
background: #c2fbff;
/* И еще одно */
}
aside > div:nth-of-type(4) {
background: #c2fbff;
/* И еще одно */
} Такой стиль помогает сохранять CSS файл более организованным (разные области определяются в разных разделах). Но платой является повторение определений. Для больших сайтов определение одного и того же цвета может доходить до нескольких тысяч раз. Ужасно! Вариантом решения может быть использование класса по типу "blueBg" для определения цвета один раз и вставки его в HTML коде, когда требуется использовать данный дизайн. Конечно, его лучше назвать "mainBrandColor" или "secondaryFont", чтобы отвязаться от описания форматирования. Можно пожертвовать семантикой кода в пользу сохранения ресурсов. ,
,
, и так далее, но к другим элементам интерфейса.
Но...