Структура css – Таблица стилей CSS. Структура CSS правила. CSS значения и свойства. Комментарии в CSS.

Leave a Comment / Css / By /

Содержание

Структура CSS. Синтаксис и подключение CSS

Синтаксис CSS
Порядок написания свойств стилей довольно прост:
Селектор { свойство: значение; свойство2: значение; и. т. д.}

  • Селектор — определяет элемент HTML, к которому применяется форматирование.
  • Свойство — показывает параметр этого элемента HTML.
  • Значение — показывает какие изменения должен претерпеть данный параметр.

Пример:
Body { margin: 0; padding: 0 }
Селектором в данном примере служит тег body, свойствами — аргументы  margin и padding, а их значения равны нулю. Все элементы после селектора заключаются в фигурные скобки. После «имени» свойства ставится двоеточие, и после пробела следует значение свойства. Значение замыкается точкой с запятой, по завершении описания стилей селектора точку с запятой можно не ставить. Данный пример написания стилей использует строчную запись, но когда свойств много, их удобнее расположить вертикально и разделить. Например:

Body {
margin: 0;
padding: 0;
font-size: 12px;
color: red;
}

При большом количестве значений одного свойства разрешается применение сокращённой записи. А вот и пример:

h3{
font-family: arial, sans-serif;
font-size: 20px;
font-style: italic;
font-weight: bold;
}
Сокращённая запись стилей заголовка h3 будет выглялеть так:

h3{ font: arial,sans-serif 20px italic bold; }

Как видите, после свойства FONT запись его значений идёт через пробелы в одну строчку. Браузер сам определяет подходящие значения и применяет их.

Для того, чтобы таблицы стилей работали с HTML-страницами их необходимо связать друг с другом. Это делается тремя способами:

Таблицы связанных стилей — при данном способе описание стилей выносится в отдельный текстовой файл с расширением css. Сам файл CSS подключают к html-документу с помощью тега <link>, который размещается внутри элемента <head>. На примере Вы видите подключение к веб-странице «документ» файла стилей «site»:

<html>
<head>
<title>Документ</title>
<link rel=»stylesheet» type=»text/css» href=»site.css»>
</head>
<body>
<h3>Заголовок документа</h3>
<p>Текст документа</p>
</body>
</html>

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

Вторым способом соединения стилей с веб-страницей служит таблица глобальных стилей. В этом случае описание стилей заключают в тег <stayle>, и вновь помещают внутри контейнера <head>. Данный способ увеличивает вес веб-страницы, но всё же позволяет разместить все стили в одном месте. Использование этого приёма противоречит принципу разделения содержания документа и его оформления, но применяется довольно часто. Рассмотрим пример:

<html>
<head>
<title>Документ</title>
<style type=»text/css»>
h3{
font-family: arial, sans-serif;
font-size: 20px;
font-style: italic;
font-weight: bold;
}
p { font: verdana 12px grey; }
</style>
</head>
<body>
<h2>Заголовок документа</h2>
<p>Текст документа</p>
</body>
</html>

На примере заданы свойства селекторов тегов <p> и <h3>.

Третьим и последним приёмом использования таблиц стилей является применение так называемых внутренних стилей. При таком способе применения CSS параметры тега <style> помещают внутри тегов, оформление которых необходимо определить, или изменить. Пример:

<html>
<head>
<title>Документ</title>
</head>
<body>
<h3>Заголовок документа</h3>

<p>Текст документа</p>
</body>
</html>

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

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

Таблица стилей CSS. Структура CSS правила. CSS значения и свойства. Комментарии в CSS.

Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. И первая публикация в этой рубрики будет посвящена CSS правилам,

синтаксису CSS, CSS свойствам и их значениям, а также комментариям в CSS. На моем блоге вы можете найти две публикации, в которых я использовал для оформления каскадные таблицы стилей, но ничего практически не объяснял: Меню для сайта. Горизонтальное CSS меню и Вертикальное выпадающее CSS меню. Горизонтальное выпадающее CSS меню.

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

Таблица стилей CSS. Структура CSS правила. CSS значения и свойства. Комментарии в CSS.

Хотелось бы как-нибудь объединить однотипные HTML элементы в одну группу и изменять их оформления не по отдельности, а сразу все вместе, например стили HTML заголовков или стили для HTML списков. Выход из этой ситуации есть – нужно просто использовать таблицу стилей CSS.

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

Основные правила CSS.

Содержание статьи:

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

Основной особенность CSS является то, что каскадная таблица стилей позволяет вносить изменение и применять определенные правила для каждого элемента сформированного браузером. Допустим, у нас есть HTML список, маркированный HTML список, который формируется при помощи тегов <ul> и <li>:

<ul> <li>Первый пункт</li> <li> Второй пункт </li> <li> Третий пункт </li> <li> Четвертый пункт </li> </ul>

<ul>

 

<li>Первый пункт</li>

 

<li> Второй пункт </li>

 

<li> Третий пункт </li>

 

<li> Четвертый пункт </li>

 

</ul>

Выглядит созданный HTML список примерно так:

HTML список

Предположим, что мы хотим сделать оранжевым цвет текста каждого пункта HTML списка, в HTML для этих целей есть тег <font>, у которого есть атрибут color (цвета в HTML, таблица RGB):

<ul> <li<font color=»orange»> Первый пункт</font></li> <li><font color=»orange»> Второй пункт</font> </li> <li><font color=»orange»> Третий пункт</font> </li> <li><font color=»orange»> Четвертый пункт</font> </li> </ul>

<ul>

 

<li<font color=»orange»> Первый пункт</font></li>

 

<li><font color=»orange»> Второй пункт</font> </li>

 

<li><font color=»orange»> Третий пункт</font> </li>

 

<li><font color=»orange»> Четвертый пункт</font> </li>

 

</ul>

Так будет выглядеть HTML список после внесенных изменений:

html список и тег <font>

Согласитесь, довольно нудно и долго писать для каждого пункта списка тег font и задавать атрибут color, хорошо, что в примере четыре пункта, а если их будет больше, а если через какое-то время мы захотим поменять цвет?

Для этого и существует таблица стилей CSS, но чтобы ваш код был эффективен, нужно знать нехитрые CSS правила. CSS – это технология, которая позволяет вам создавать собственные правила отображения элементов на странице, эти правила легко и быстро можно изменять и применять их к любым элементам страницы. Теперь давайте вернемся к примеру и посмотрим, на сколько быстрее и проще можно изменить правила отображения элементов <li>. HTML страница будет выглядеть точно так же, как и в первом случае.

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

Это CSS правило позволяет сделать текст всех элементов <li> на странице оранжевым. Более того, мы можем поменять цвет пунктов HTML списка, просто изменив одну строку и теперь нам не нужен тег <font> и его атрибуты. Чтобы изменить цвет пунктов HTML списка, мы просто меняем правила CSS и все. Неплохо, да?

Структура CSS правила. Синтаксис CSS. CSS значение и CSS свойство.

Для представления, что такое CSS, нужно понять структуру CSS правила и знать CSS синтаксис. Любое CSS правило состоит из двух частей: CSS селектор, при помощи CSS селекторов мы задаем элементы, к которым хотим применить CSS правила и блок объявлений CSS, блок объявлений может состоят из одного или нескольких CSS объявлений. В свою очередь, каждое объявление состоит из двух частей: CSS свойство и значение CSS.  Таким образом, мы приходим к выводу, что каскадная таблица стилей CSS состоит из набора CSS правил.

Пример CSS правила:

Структура CSS правила

На рисунке вы можете видеть, что все стили, которые мы хотим задать для нужного HTML элемента или группы элементов заключаются в фигурные скобки, перед которыми пишется CSS селектор. Внутри фигурных скобок размещаются CSS объявления: пара CSS свойство и CSS значение, между собой они разделяются двоеточием, после каждого объявления ставится точка с запятой. Обратите внимание: у каждого CSS свойства имеется свой набор значений. Понятно, что цвет фона, заданный при помощи CSS свойства background-color, и цвет текста внутри элемента <li> будут применены к каждому элементу <li> HTML документа.

Теперь давайте поговорим о синтаксисе CSS.  CSS нечувствителен к регистру символов, CSS нечувствителен к пробельным символам: переносам строк, табуляциям и пробелам; из всего вышесказанного следует, –  форма записи CSS правил зависит только от желания разработчика, например:

LI{Color: red; list-Style:NONE;} p{ background:gray; botton-border: 1px; }

LI{Color: red; list-Style:NONE;}

 

p{

 

background:gray;

 

botton-border: 1px;

 

}

То есть, вы можете писать все CSS свойства, CSS значения и правила в одну строку, так, как это записано для элемента <li>, а можете записывать каждое CSS объявление на новой строке. Второй вариант мне нравится больше просто потому, что такой код проще редактировать, с другой стороны лишние пробельные символы увеличивают объем файла, в котором хранятся CSS правила.

CSS стили, правила. Синтаксис CSS, комментарии CSS. Приоритет CSS.

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

menu{ color: #545ff3 list-style: none; display:inline; }

menu{

 

color: #545ff3

 

list-style: none;

 

display:inline;

 

}

В данном случае мы задали CSS стили для тега <menu> внутри одного CSS правила.

table{color: orange;} table{border: 1px;} table{background: pink;}

table{color: orange;}

 

table{border: 1px;}

 

table{background: pink;}

В данном случае мы создали несколько CSS правил для тега <table>, каждая пара CSS свойство и значение записана в отдельное CSS правило. Конечно, такая форма записи неудобна, приходится повторять CSS селектор и легко можно запутаться.

Теперь давайте поговорим о приоритете CSS правил и объявлений, допустим у нас на странице есть элемент <a>, ссылка. И для этого элемента существует следующее CSS правило:

a{ color: red; color:blue; }

a{

 

color: red;

 

color:blue;

 

}

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

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

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

CSS комментарии бывают только блочными и могут располагаться в любом месте документа с расширением .css:

/* CSS комментарий может располагаться и занимать несколько строк */ /* Стили для тега <menu> */ &nbsp; menu{ color: #545ff3; /* цвет текста  */ list-style: none; /* убираем мерзкие маркеры  */ display:inline; /* отображать элемент <menu>, как строчный  */ } &nbsp;

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

/* CSS комментарий может

 

располагаться и занимать несколько

 

строк */

 

/* Стили для тега <menu> */

 

&nbsp;

 

menu{

 

color: #545ff3; /* цвет текста  */

 

list-style: none; /* убираем мерзкие маркеры  */

 

display:inline; /* отображать элемент <menu>, как строчный  */

 

}

 

&nbsp;

На этом всё, спасибо за внимание, надеюсь, что был хоть чем-то полезен и до скорых встреч на страницах блога для начинающих вебразработчиков и вебмастеров ZametkiNaPolyah.ru. Не забываем комментировать и делиться с друзьями;)

создание структуры файлов и папок

Архитектура CSS - структура папок и файлов

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

Прежде чем мы начнем, несколько слов о том, кто я. Меня зовут Элад Шехтер, и я работаю разработчиком 13 лет. Последние девять лет я работаю над архитектурой CSS / HTML. В этой статье я покажу мои рекомендации по определению архитектуры CSS, основанные на моем многолетнем опыте.

Примечание: в настоящее время, как правило, в проектах используется CSS-препроцессор. В этом посте я буду использовать препроцессор SASS.

Я разделил этот пост на разделы, соответствующие основным элементам моей архитектуры. Основная структура моих проектов состоит из уровня конфигурации и уровня содержимого; уровень содержимого состоит из других уровней, главные из которых является слой партиалов. Этот слой содержит элементы, компоненты, последовательности, а иногда объекты.

Базовая структура

Я строю свои проекты, используя два основных файла: файл конфигурации и файл стилей содержимого. Файл конфигурации с именем _config.scss ссылается на все файлы конфигурации, а файл стилей содержимого, который называется, _local.scss ссылается на все папки и файлы в локальной папке.

Архитектура CSS - структура папок и файлов

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

Помимо того, что это полезно для разделения задач, этот раздел поможет вам создать архитектуру CSS, даже если у вас более одного веб-сайта. Архитектура для нескольких сайтов — это то, о чем я расскажу в следующем посте!

В main.scss подключаются оба этих файла.

Основная папка SASS:

sass/ | |- framework/ |- _config.scss |- _local.scss |- main.scss

sass/

|

|- framework/

     |- _config.scss

     |- _local.scss

     |- main.scss

Файл main.scss:

@import «config»; @import «local»;

@import «config»;

@import «local»;

Уровень конфигурации (_config.scss)

На уровне конфигурации я определяю все переменные SASS / CSS и некоторые основные определения для root. Чтобы добиться оптимальной структуры проекта, я делю конфигурацию на более мелкие файлы в соответствии с их логической функцией. Пример:

Переменные CDN

Переменные цвета

Переменные контрольных точек адаптивного дизайна

Переменные языковой поддержки

Основные слои Z-Index

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

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

framework/ | |- config/ | |- _common.scss | |- _cdn.scss | |- _colors.scss | |- _directions.scss | |- _breakpoints.scss | |- _layers.scss | |- local/ | |- Folders and Files | |- _config.scss |- _local.scss |- main.scss

framework/

|

|- config/

|   |- _common.scss

|   |- _cdn.scss

|   |- _colors.scss

|   |- _directions.scss

|   |- _breakpoints.scss

|   |- _layers.scss

|

|- local/

|   |- Folders and Files

|

|- _config.scss

|- _local.scss

|- main.scss

Уровень содержимого (_local.scss)

Уровень содержимого, расположенный внутри _local.scss, представляет основные стили содержимого, т. е. именно здесь вы должны разместить все свои стили.

Этот слой должен включать миксины SASS, CSS Normalize и CSS Reset, шрифты, иконки, служебные классы CSS, общие сетки и партиалы.

framework/ | |- config/ | |- config files | |- local/ | |- _mixins.scss | |- _resets.scss // normalize + resets + typography | |- _fonts.scss | |- _icons.scss // font icons/SVG icons | |- _utilities.scss | |- _grids.scss // common layouts | |- _partials.scss // elements/components/entities/pages | |- _config.scss |- _local.scss |- main.scss

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

framework/

|

|- config/

|   |- config files

|

|- local/

|   |- _mixins.scss        

|   |- _resets.scss     // normalize + resets + typography

|   |- _fonts.scss      

|   |- _icons.scss      // font icons/SVG icons

|   |- _utilities.scss

|   |- _grids.scss      // common layouts

|   |- _partials.scss      // elements/components/entities/pages

|

|- _config.scss

|- _local.scss

|- main.scss

На уровне содержимого размещаются стили, принадлежащие множеству различных логических частей, таких как сброс, шрифты, иконки и т. д. Даже если мы разделим его на минимальное количество файлов, мы можем получить до 7 или 8 файлов. В некоторых случаях лучше разделить их на еще более мелкие части, чтобы файлы .sass не становились слишком большими, т. е. не более 50 строк, если вы пишете определения стилей по одной строке для каждого селектора, и не более 200 строк, если каждое определение занимает целый ряд.

Вот некоторые примеры:

Уровень миксинов

Просмотр папки:

framework/ | |- local/ |- |- mixins/ | | |- _trim.scss | | |- _rotation.scss | | |- _prevent-select.scss | | |- _break-word.scss | | |- _scrollbar.scss | | |- _screen-reader.scss | |- _mixins.scss

framework/

|

|- local/

|-  |- mixins/

|   |  |- _trim.scss

|   |  |- _rotation.scss

|   |  |- _prevent-select.scss

|   |  |- _break-word.scss

|   |  |- _scrollbar.scss

|   |  |- _screen-reader.scss

|   |- _mixins.scss

_mixins.scss:

@import «mixins/trim»; @import «mixins/rotation»; @import «mixins/prevent-select»; @import «mixins/break-word»; @import «mixins/scrollbar»; @import «mixins/screen-reader»;

@import «mixins/trim»;

@import «mixins/rotation»;

@import «mixins/prevent-select»;

@import «mixins/break-word»;

@import «mixins/scrollbar»;

@import «mixins/screen-reader»;

Уровень сброса

Просмотр папки:

framework/ | |- local/ |- |- resets/ | | |- _normalize.scss | | |- _reset.local.scss | | |- _typography.scss | |- _resets.scss

framework/

|

|- local/

|-  |- resets/

|   |  |- _normalize.scss

|   |  |- _reset.local.scss

|   |  |- _typography.scss

|   |- _resets.scss

_resets.scss

Архитектура CSS - структура папок и файлов

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

/*resets*/ @import «resets/normalize»; @import «resets/reset.local»; @import «resets/typography»;

/*resets*/

@import «resets/normalize»;

@import «resets/reset.local»;

@import «resets/typography»;

Уровень партиалов (_partials.scss)

_Partials.scss является одним из основных файлов в уровне _local.scss. Именно здесь я помещаю все компоненты, будь то маленькие, средние или большие.

framework/ | |- config/ | |- config files | |- local/ | … | |- _partials.scss // elements/components/entities/pages | |- _config.scss |- _local.scss |- main.scss

framework/

|

|- config/

|   |- config files

|

|- local/

|   …

|   |- _partials.scss      // elements/components/entities/pages

|

|- _config.scss

|- _local.scss

|- main.scss

Поскольку уровень partials такой большой, я делю его на меньшие логические внутренние уровни, где-то от 3 до 5 файлов. Количество файлов может меняться в зависимости от проекта или ваших предпочтений.

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

framework/ | |- local/ | |- partials/ | |- 1-elements/ | |- 2-components/ | |- 3-sequences/ | |- 4-entities/ | |- 5-pages/ | |- _1-elements.scss | |- _2-components.scss | |- _3-sequences.scss | |- _4-entities.scss | |- _5-pages.scss | |- _partials.scss // elements/components/entities/pages

framework/

|

|- local/

|   |- partials/    

|       |- 1-elements/  

|       |- 2-components/

|       |- 3-sequences/

|       |- 4-entities/

|       |- 5-pages/

|       |- _1-elements.scss  

|       |- _2-components.scss

|       |- _3-sequences.scss  

|       |- _4-entities.scss

|       |- _5-pages.scss

|   |- _partials.scss      // elements/components/entities/pages

_partials.scss:

// from most generic to specific @import «partials/1-elements»; @import «partials/2-components»; @import «partials/3-sequences»; @import «partials/4-entities»; @import «partials/5-pages»;

// from most generic to specific

@import «partials/1-elements»;

@import «partials/2-components»;

@import «partials/3-sequences»;

@import «partials/4-entities»;

@import «partials/5-pages»;

Как определить, где на уровне _partials.scss разместить стиль

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

Определения на этом уровне делятся на несколько типов:

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

Важно поместить каждую часть в отдельный файл. Таким образом, вы можете легко управлять этими базовыми стилями, не беспокоясь о том, что они могут повлиять на другие части CSS, когда вы захотите изменить эти стили. Пример для файла _1-elements.scss (часть _partials.scss)

/*общие*/ @import «1-elements/common-links»; @import «1-elements/titles»; @import «1-elements/common-popup»; /*Кнопки*/ @import «1-elements/common-button»; @import «1-elements/button-icon»; @import «1-elements/button-tabs»; @import «1-elements/tooltip-button»; /*формы*/ @import «1-elements/select-row»; @import «1-elements/forms»; @import «1-elements/search»; @import «1-elements/search-result»; /*таблицы*/ @import «1-elements/common-table»; @import «1-elements/table-summary»; @import «1-elements/table-links»; @import «1-elements/table-filtering»; /*другое*/ @import «1-elements/system-alerts»; ……… и многое другое…

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

/*общие*/

@import «1-elements/common-links»;

@import «1-elements/titles»;

@import «1-elements/common-popup»;

/*Кнопки*/

@import «1-elements/common-button»;

@import «1-elements/button-icon»;

@import «1-elements/button-tabs»;

@import «1-elements/tooltip-button»;

/*формы*/

@import «1-elements/select-row»;

@import «1-elements/forms»;

@import «1-elements/search»;

@import «1-elements/search-result»;

/*таблицы*/

@import «1-elements/common-table»;

@import «1-elements/table-summary»;

@import «1-elements/table-links»;

@import «1-elements/table-filtering»;

/*другое*/

@import «1-elements/system-alerts»;

……… и многое другое…

(Разбейте все (!) на мелкие части)

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

В HTML Компонентов могут содержаться партиалы Элементов. Иногда компонент не будет влиять на эти Элементы, а иногда это будет зависеть от ваших потребностей: если вы хотите, чтобы существующий элемент вел себя по-другому в компоненте, вы должны включить компонент после определения элемента, чтобы в этом компоненте элемент получил его новые конкретные определения. Как я уже писал ранее, когда я делю уровень _partials.scss на эти основные уровни, я добавляю номера префиксов в начале каждого уровня, чтобы указать, что между этими уровнями есть зависимости. Таким образом, мы гарантируем, что каскадные стили будут работать правильно.

// от наиболее общих до специфичных @import «partials/1-elements»; @import «partials/2-components»; @import «partials/3-sequences»; @import «partials/4-entities»; @import «partials/5-pages»;

// от наиболее общих до специфичных

@import «partials/1-elements»;

@import «partials/2-components»;

@import «partials/3-sequences»;

@import «partials/4-entities»;

@import «partials/5-pages»;

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

Партиалы объектов и страниц

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

Объекты — я применяю их при использовании элементов, компонентов или последовательностей, чьи стили не на 100% одинаковы. Я добавляю другое имя класса к элементу, компоненту или последовательности — в дополнение к его элементу, компоненту или классу последовательности — и это позволяет мне применять к нему различные стили. Имя класса начинается с ‘e-’ для представления объекта.

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

<section> </section>

<section> </section>

Кроме этого, вы можете добавить столько классов CSS-утилит, сколько захотите.

<section> </section>

<section> </section>

Страницы — каждая страница на вашем сайте может быть объектом. В этом случае класс должен быть добавлен к элементу body или к элементу main, который охватывает все. Имя класса должно начинаться с «p-», например: «p-homepage» или « p-news» и т. д…

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

<body></body>

<body></body>

Заключение

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

Автор: Elad Shechter

Источник: https://medium.com

Редакция: Команда webformyself.

Архитектура CSS - структура папок и файлов

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее Архитектура CSS - структура папок и файлов

PSD to HTML

Верстка сайта на HTML5 и CSS3 с нуля

Смотреть

Архитектура CSS — Веб-стандарты

Мерой хорошего знания CSS для многих веб-разработчиков является то, насколько идеально ты можешь воссоздать в коде данный тебе макет. Ты не используешь таблицы и гордишься собой, когда сводишь к минимуму графику. Если ты действительно хорош, то работаешь с самыми новыми и лучшими техниками — вроде медиавыражений, переходов и трансформаций. Это правда, хорошие CSS-разработчики действительно всё это умеют. Однако существует совсем другая сторона CSS, которая редко упоминается, когда речь заходит об оценке чьих-то способностей.

Что интересно, обычно мы не упускаем из вида эту сторону, когда дело касается других языков. Разработчик на Rails не считается хорошим только потому, что его код работает по спецификации. Это считается базовым уровнем. Конечно, он должен работать по спецификации, но его качество измеряется другим: насколько код читаемый, легко ли его изменить или расширить, достаточно ли он отделён от других частей приложения, будет ли он масштабироваться?

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

Принципы хорошей архитектуры CSS

CSS-сообществу редко удаётся прийти к договорённости, что и как нужно делать. Даже если взглянуть только на комментарии с Hacker News или на реакцию разработчиков на выход CSS Lint, станет ясно, что многие не согласны друг с другом даже по поводу самых базовых вещей, которые стоит или не стоит делать при разработке.

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

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

Предсказуемость

Предсказуемость для CSS означает, что ваши правила ведут себя ожидаемо. Когда вы добавляете или изменяете какое-то правило, оно не должно влиять на части сайта, которые вы не собирались менять.

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

Повторное использование

CSS-правила должны быть достаточно абстрактны и независимы, чтобы можно было быстро создать новые компоненты из существующих частей без необходимости что-то переписывать или снова бороться с уже решёнными проблемами.

Поддержка

Когда нужно добавить или изменить новые компоненты или возможности, это не должно приводить к рефакторингу существующего CSS. Добавление компонента А на страницу не должно своим появлением ломать компонент Б.

Масштабируемость

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

Распространённые ошибки

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

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

Изменение компонентов в зависимости от родителя

Почти на каждом сайте в сети найдётся определённый визуальный элемент, который выглядит одинаково во всех случаях, кроме одного. Встречаясь с такой исключительной ситуацией, почти каждый новичок в CSS (и даже опытные разработчики) поступают одинаково. Они выясняют некоторого уникального родителя исключительно для этого случая (или создают такого) и пишут нужный селектор.

.widget {
    background:yellow;
    border:1px solid black;
    color:black;
    width:50%;
    }
#sidebar .widget {
    width:200px;
    }
body.homepage .widget {
    background:white;
    }

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

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

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

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

Представьте, если бы такой код был написан на любом другом языке. Вы создаёте обычное определение класса и потом, в другой части кода, берёте это определение класса и меняете его для определённого случая. Это прямо противоречит принципу открытости и закрытости для разработки ПО:

Части ПО (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения.

Далее в статье мы рассмотрим, как изменять компоненты, не опираясь на родительский селектор.

Слишком сложные селекторы

Удивительно, но эта статья обойдёт стороной демонстрацию всей мощи CSS-селекторов и не расскажет о том, как оформить целый сайт, не используя ни единого класса или ID.

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

#main-nav ul li ul li div { }
#content article h2:first-child { }
#sidebar > div > h4 + p { }

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

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

Упомянутые примеры совсем не готовы для повторного использования. Поскольку селектор указывает на очень конкретную часть разметки, то как может другой компонент с иной структурой HTML использовать эти стили? Возьмём для примера первый селектор (выпадающее меню) — что, если похожее меню понадобится на другой странице, на которой не будет элемента #main-nav? Тогда вам придётся повторить все стили.

Эти селекторы также очень непредсказуемы в случае, когда меняется оригинальный HTML. Представим, что разработчик решил поменять тег <div> в третьем примере на <section> — в результате весь селектор развалится.

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

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

Слишком общие имена классов

При создании повторно используемых компонентов зачастую принято ограничивать область действия (ага, если бы) вложенных элементов в рамках имени класса компонента. Например:

<div>
    <h4>…</h4>
    <div>
        Лорем ипсум…
        <button>Жми сюда!</button>
    </div>
</div>

.widget {}
.widget .title {}
.widget .contents {}
.widget .action {}

Идея состоит в том, что классы вложенных элементов .title, .contents и .action можно безопасно оформить, не боясь, что стили повлияют на элементы с такими же классами. Это, конечно, так, но совсем не значит, что эти стили не повлияют на элементы с таким же классом, которые могут оказаться внутри.

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

Слишком общие имена классов приводят к непредсказуемому CSS.

Когда правило делает слишком много

Однажды вы создаёте визуальный компонент, который должен отстоять на 20 пикселей от верхнего левого угла блока на вашем сайте:

.widget {
    position:absolute;
    top:20px;
    left:20px;
    background-color:red;
    font-size:1.5em;
    text-transform:uppercase;
    }

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

Проблема в том, что вы делаете с помощью одного селектора сразу слишком многое. Вы описываете внешний вид блока вместе с раскладкой и позиционированием в одном правиле. Внешний вид можно использовать повторно, раскладку и позиционирование — нет. И поскольку они описаны вместе, всё правило скомпрометировано.

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

Причина

Упомянутые выше проблемные примеры объединяет одна особенность: все они слишком полагаются на оформление CSS.

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

Простой ответ на этот вопрос «да», но, как обычно, всё не так просто. Разделять содержимое и представление хорошо, но содержимое не отделяется от представления только потому, что ваш CSS отделён от HTML. Скажем иначе: вы не достигнете цели, если просто уберёте всё представление из HTML, но при этом для работы вашего CSS потребуется подробнейшее знание структуры HTML.

Более того, HTML редко состоит только из содержимого, почти всегда в нём есть и структура. И часто эта структура состоит из контейнеров, единственной задачей которых является объединение некоторой группы элементов для работы CSS. Даже без презентационных классов такие структуры добавляют представление в HTML-код. Но действительно ли это смешивает содержимое с представлением?

Я уверен, что на текущем уровне развития HTML и CSS необходимо и зачастую разумно использовать HTML и CSS в качестве единого слоя представления. Слой содержимого в таком случае может быть отделён с помощью шаблонизаторов или подключаемых фрагментов (как partials в Ruby).

Решение

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

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

Например, в CSS с помощью класса .button описан компонент кнопки. Если в HTML понадобится конкретный элемент, который выглядит как кнопка, то нужно использовать этот класс. Если в другой ситуации этой кнопке понадобится выглядеть иначе (скажем, больше и в полную ширину), в CSS нужно определить этот новый вид, также с помощью класса, и тогда его можно будет добавить в HTML для достижения нужного вида.

CSS определяет, как выглядит ваш компонент, а HTML применяет этот вид к элементам на странице. Чем меньше CSS «знает» про структуру HTML, тем лучше.

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

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

Несмотря на то, что эти сомнения справедливы, они могут привести к ошибочным выводам. Вывод такой: либо вы используете родительский селектор в CSS, либо вам придётся написать этот HTML-класс тысячу раз руками. Но, очевидно, есть и другие варианты. Уровень абстракции компонентов в Rails и других фреймворках легко позволяет явно описывать внешний вид прямо в HTML без необходимости снова и снова писать один и тот же класс.

Правильный подход

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

Будьте точнее

Лучший способ добиться того, чтобы ваши селекторы не влияли на ненужные элементы — это не дать им такой возможности. Со временем вы можете обнаружить, что селектор вроде #main-nav ul li ul li div применяется уже совсем не к тому элементу из-за изменившейся разметки. Класс .subnav, напротив, имеет очень мало шансов быть случайно применённым не к тому элементу. Назначать классы прямо элементам, которые вы хотите оформить — лучший способ сохранить ваш CSS предсказуемым.

/* Граната */
#main-nav ul li ul { }

/* Снайперская винтовка */
.subnav { }

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

Разделяйте ответственность

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

В общем случае компоненты должны определять свой внешний вид, а не раскладку и позиционирование. Будьте осторожны, когда видите свойства вроде background, color и font в одном правиле с position, width, height и margin.

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

Задайте пространство имён

Мы уже выяснили, почему родительские селекторы не всегда на 100% эффективны для ограничения действия и пересечения стилей. Гораздо лучший подход — добавить пространство имён к самим классам. Если элемент является частью визуального компонента, то каждый из классов его вложенных элементов должен использовать имя класса базового компонента в качестве пространства имён.

/* Высокий риск пересечения имён классов */
.widget { }
.widget .title { }

/* Низкий риск пересечения имён классов */
.widget { }
.widget-title { }

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

Расширяйте компоненты модификаторами классов

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

/* Плохо */
.widget { }
#sidebar .widget { }

/* Хорошо */
.widget { }
.widget-sidebar { }

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

Организуйте CSS в логическую структуру

Джонатан Снук в своей замечательной книге SMACSS убеждает разделять CSS-правила на четыре отдельные категории: базовые, раскладку, модули и состояния. Базовые состоят из сбросов и умолчаний для элементов. Раскладка — для расположения глобальных элементов сайта, а также общих вспомогательных вещей вроде модульных сеток. Модули — это визуальные элементы для повторного использования и стили состояний для оформления того, что можно включить или выключить с помощью JavaScript.

В системе SMACSS модули (эквивалентные тому, что я называю компонентами) составляют большинство от всех правил в CSS, поэтому я часто прихожу к необходимости разбить их ещё больше, отделив абстрактные шаблоны.

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

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

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

Используйте классы строго для оформления

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

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

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

Тем не менее, устоявшиеся договорённости помогут полностью избежать этой проблемы. Когда вы видите класс в HTML, вы должны быть способны чётко сказать, для чего он предназначен. Мой совет — добавлять префикс ко всем неоформительским классам. Я использую .js- для JavaScript и .supports- для классов Modernizr. Все классы без префикса — для оформления и только для оформления.

Это позволяет искать неиспользуемые классы и удалять их из HTML простым поиском по папке со стилями. Вы можете даже автоматизировать этот процесс с помощью JavaScript, сравнивая классы в HTML с классами в объекте document.styleSheets. Классы, которых нет в document.styleSheets, можно безопасно удалять.

Итак, полезно разделять содержимое и представление, и столь же важно отделять представление от поведения. Использование классов с оформлением в качестве основы для JavaScript так сильно связывает CSS с JavaScript, что становится сложно или даже невозможно обновить оформление некоторых элементов, не сломав их поведение.

Логическая структура в именах классов

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

Николас Галлахер недавно написал о своем решении этой проблемы, которое я тоже (с некоторыми изменениями) с большим успехом применил. Чтобы проиллюстрировать необходимость в договорённости об именовании, рассмотрим следующий пример:

/* Компонент */
.button-group { }

/* Модификатор компонента (изменяющий .button) */
.button-primary { }

/* Вложенный объект (находится внутри .button) */
.button-icon { }

/* Это класс компонента или раскладки? */
.header { }

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

/* Правила шаблонов (с использованием Sass) */
%template-name
%template-name--modifier-name
%template-name__sub-object
%template-name__sub-object--modifier-name

/* Правила компонентов */
.component-name
.component-name--modifier-name
.component-name__sub-object
.component-name__sub-object--modifier-name

/* Правила для раскладки */
.l-layout-method
.grid

/* Правила состояний */
.is-state-type

/* Классы для JavaScript без оформления */
.js-action-name

Переработанный первый пример:

/* Компонент */
.button-group { }

/* Модификатор компонента (изменяющий .button) */
.button--primary { }

/* Вложенный объект (находится внутри .button) */
.button__icon { }

/* Класс раскладки */
.l-header { }

Инструменты

Поддержка эффективной и хорошо организованной архитектуры CSS может быть очень сложной, особенно в больших командах. Несколько плохих правил здесь, несколько там — и снежный ком неразрешимых проблем уже покатился. Когда CSS вашего приложения уже дошел до войн за специфичность и сомнительных побед за счёт !important, может оказаться, что пути назад уже нет, разве что переписать всё с нуля.

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

Препроцессоры

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

Препроцессоры помогают писать CSS быстрее, но не качественнее. В конце концов код превращается в обычный CSS, к которому применяются все те же правила. Если препроцессор помогает вам писать CSS быстрее, он так же помогает быстрее писать плохой CSS, поэтому важно понимать, что такое хорошая архитектура CSS, а не просто думать, что препроцессор решит все ваши проблемы.

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

  • Никогда не вкладывайте правила только для организации кода. Вкладывайте только тогда, когда это нужно в CSS на выходе.
  • Никогда не используйте примеси (mixin), если не передаёте аргумент. Примеси без аргументов гораздо лучше использовать в качестве шаблонов, которые можно расширить.
  • Никогда не используйте @extend для селектора, который не является одиночным классом. Это не имеет смысла с точки зрения дизайна и раздувает скомпилированный CSS.
  • Никогда не используйте @extend для компонентов интерфейса в модификаторе компонента, иначе вы нарушаете цепь наследования (подробнее об этом дальше).

Лучшая часть препроцессоров — это функции, вроде @extend и %placeholder. Обе они позволяют просто управлять абстракциями в CSS, при этом не раздувая код и обходясь без добавления в HTML огромного количества базовых классов, с которыми потом очень сложно управиться.

@extend нужно использовать с осторожностью, потому что иногда эти классы будут нужны в HTML. Например, когда вы впервые узнаёте про @extend, то его сразу хочется применить ко всем классам-модификаторам как-то так:

.button {
    /* Стили кнопки */
    }
/* Плохо */
.button--primary {
    @extend .button;
    /* Стили модификатора */
    }

Проблема с этим подходом в том, что вы теряете цепь наследования в HTML. Теперь довольно сложно выбрать все экземпляры кнопки с помощью JavaScript.

Как правило, я не расширяю компоненты интерфейса или что-то другое, тип чего мне может пригодиться знать в будущем. Для этого случая как раз и придуманы компоненты, и это ещё один способ, помогающий отличать шаблоны от компонентов. Шаблон — это нечто, к чему вы никогда не обратитесь в логике вашего приложения, и поэтому его можно безопасно расширить с помощью препроцессора.

Как это может выглядеть на примере модального окна, о котором шла речь выше:

.modal {
    @extend %dialog;
    @extend %drop-shadow;
    @extend %statically-centered;
    /* Другие стили окна */
    }
.modal__close {
    @extend %dialog__close;
    /* Другие стили кнопки закрытия */
    }
.modal__header {
    @extend %background-gradient;
    /* Другие стили заголовка окна */
    }

CSS Lint

Николь Салливан и Николас Закас создали CSS Lint, инструмент для контроля за качеством кода, который помогает разработчикам находить плохие подходы в их CSS. На сайте он описан так:

CSS Lint указывает на проблемы в вашем CSS-коде. Он делает базовую проверку синтаксиса, а также применяет к коду набор правил, которые позволяют выделить в нём проблемные подходы или признаки неэффективности. Все правила расширяемы, потому вы легко можете написать свои или пропустить ненужные.

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

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

Основываясь на договорённостях, которые я предложил выше, очень легко написать правила для определения неверных подходов. Вот несколько правил, которые я использую:

  • Не допускайте ID в своих селекторах.
  • Не используйте несемантические типы селекторов (div и span, напр.) для любого неодиночного правила.
  • Не используйте больше двух комбинаторов в селекторе.
  • Не допускайте использование классов, начинающихся с .js-.
  • Внимание, если раскладка и позиционирование применяются в правилах для элементов без префикса .l- в названии класса.
  • Внимание, если класс, определённый сам по себе, позднее переопределяется как дочерний или иначе.

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

HTML Inspector

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

HTML Inspector проходит по вашему HTML и (почти как CSS Lint) позволяет вам написать собственные правила, которые вызывают ошибки или предупреждения, когда какие-то договорённости нарушаются. Сейчас я использую следующие правила:

  • Внимание, если один и тот же ID используется на странице два раза.
  • Не используйте классы, не упомянутые ни в одном из файлов стилей или передайте список разрешённых (с префиксом .js-, напр.)
  • Классы модификаторов не должны использоваться без их базовых классов.
  • Классы вложенных объектов не должны использоваться в отсутствие родительского базового класса.
  • Простые элементы <div> и <span> не должны использоваться в HTML без назначенных классов.

Заключение

CSS — это не просто средство визуального дизайна. Не стоит забывать о правильных подходах к программированию только потому, что вы пишете CSS. Подходы вроде ООП, DRY, принцип открытости и закрытости, разделение ответственности и т.п. также применимы к CSS.

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

Перевод оригинальной записи «CSS Architecture» Филипа Уолтона (Philip Walton). Переведено и опубликовано с разрешения автора.

Перевод Вадима Макеева, редактура Ольги Алексашенко.

Теги: css, html, семантика

Организация и оптимизация стилей / Habr

В этом посте я приведу пример организации стилей на типичном проекте.

Небольшое вступление, попробую объяснить актуальность проблемы и зачем это нужно.
Рассмотрим такую ситуацию. Разработчику ставят задачу, реализовать очередной функционал на сайте. Это допустим включает добавление новых разделов, блоков, элементов. Разработчики зачастую не доверяют чужому коду, и когда доходят до верстки, находят css-файл с названием типа main.css и дописывают в конец свои новые стили.
Проходит некоторое время, приходит новый разработчик, ему ставят подобную задачу, он если и пытается разобраться в стилях, то видит, что там нет никакой закономерности, и повторяет то же, что делали предыдущие.
Руководство ставит сроки, разрабатывается все новый и новый функционал, проект растет. В итоге css файлы превращаются в мусорку, сайт грузится дольше, появляется больше дефектов и т.д..
Я думаю, многим это знакомо.

Теперь поговорим непосредственно о самой структуризации стилей.
Держать все стили в одном файле неразумно, со временем в нем довольно сложно становится ориентироваться. Плюс на каждой странице используются около 10% правил из этого файла, а весит он не мало.
Гораздо оптимальнее разделять стили по логическим блокам сайта.

Так же к проекту необходимо подключить библиотеку для работы с css (LESS, SASS, SCSS). Нам понадобится работа с переменными, функциями.
Для уменьшения запросов на сервер необходима сборка файлов. Файлы должны склеиваться по специальной конструкции, можно, например, использовать стандартную констукцию css — import. Здесь возможно потребуется помощь разработчика для редактирования исходников выбранной вами библиотеки css.
Плюс, для уменьшения объема, файлы должны приходить клиенту сжатые. dotLess, например, сжимает файлы при значении <dotless minifyCss="true" cache="false"/> в web.config.

Каждому логическому блоку будет соответствовать отдельный css файл. Так упрощается поддержка, поиск нужных стилей, да и вообще ориентация в файлах. Все данные файлы являются исходниками, будем содержать их в папке /css/sources/. Остальные css-файлы — сборщики, они линкуются на страницы и собирают импортом исходники.
Допустим рассматриваемый проект это некая соцсеть, исходя из этого можно выделить следующую структуру:

/css
        /sources — папка для ресурсов, не выкладывается на сервер
                /global-vars — файлы данной папки подключаются в каждый css-файл сборщик по мере необходимости
                        locals.css — глобальные переменные
                        functions.css — глобальные функции
                /common
                        reset.css — думаю, объяснять не нужно, понятно, что за стили
                        utils.css — стили типа .clearfix
                /content
                        base.css — основные стили для контента, а именно — h2-h6, p, буллиты для списков (ul.text, ul.dashed и т.д.), dl, dd, dt, изображения и панели в тексте (обтекание текстом), текстовые колонки и т.д.
                        panels.css — различные панели
                        tables.css — стили для таблиц в контенте (th, черезполосица)
                /controls
                        buttons.css — виды кнопок
                        forms.css — общие стили для input-полей (к примеру, внутренняя тень, фокус (рамка), оформление валидационных сообщений и их скрытие по умолчанию)
                        tabs.css — табы, вкладки
                        system-notifications.css — системные сообщения, как правило бывают 3-х типов: success (зеленые), failure (красные) и info (серые, синие)
                        pager.css — пейджер
                        banners.css — баннеры на сайте
                        balloons.css — всякие баллуны, всплывающие подсказки, кастомные тултипы и т.д.
                /member
                        thumb.css — аватарка пользователей
                        card.css — карточка пользователя (аватарка, имя, краткие данные)
                        cards-list.css — например, грид с карточками
                        profile.css — профиль пользователя
                /modules — различные модули к сайту
                        search.css
                        news-list.css
                        gifts.css
                        games.css
                /not-auth — для неавторизованных пользователей
                        login.css — форма авторизации
                        registration.css — форма регистрации
                /auth — для авторизованных пользователей
                        my-account.css
                        mail-system.css — inbox сообщения, outbox и т.д.
                        auth-menu.css — меню навигации в авторизованной зоне
                        my-profile.css — просмотр своего профайла, редактирование
                /layouts
                        common.css
                        header.css
                        top-menu.css
                        footer.css
                        overlay.css — например, все всплывающие поверх слои будут с затемнением 0.5
        main.css — основной сборщик, линкуется на всех мастер-страницах
        /layouts
                default.css — основной layout сайта, собирает файлы из папки /layouts, подключается на мастере с основным layout’ом
                popup-windows.css — стили для popup’ов, подключается на мастер-страницах для popup окон
        not-auth.css — собирает стили из папки /sources/not-auth/
        auth.css — собирает стили из папки /sources/auth/
        /themes — различные тематики сайта
                new-year.css
                st-valentine.css
/%section-name% — какой-нибудь новый раздел сайта, «сайт в сайте», характерный наличием своего подменю и т.д.
        /css
                %section-name%.css
                layout.css
                /sources
                        menu.css

Конечно же для каждого проекта своя уникальная структура. Важен принцип разделения файлов.

Дополнительное описание к некоторым файлам:

main.css — собирает файлы из папок:
        /sources/global-vars
        /sources/common
        /sources/content
        /sources/controls
        /sources/member
        /sources/modules

functions.css — содержит глобальные функции, типа:

.rounded-corners(@radius)
{
        border-radius: @radius;
        -moz-border-radius: @radius;
        -webkit-border-radius: @radius;
        *behavior: url(/libs/progressive-IE.htc);
}

sources/layouts/common.css — глобальные стили по layout’у:

.columns-wrapper
{
        display: table;
        *zoom: 1;
}
.columns-wrapper .column
{
        display: table-cell;
        *float: left;
}

Подключение файлов not-auth.css и auth.css зависит от состояния авторизации пользователя. Например, в asp.net это будет выглядеть так:

<asp:LoginView runat="server">
  <AnonymousTemplate>
    <link href="/css/not-auth.css" rel="stylesheet" type="text/css" />
  </AnonymousTemplate>
  <LoggedInTemplate>
    <link href="/css/auth.css" rel="stylesheet" type="text/css" />
  </LoggedInTemplate>
</asp:LoginView>

* This source code was highlighted with Source Code Highlighter.

Хочу привести концепцию, которой, я считаю, следует держаться.
Новые страницы должны строиться из компонентов, «кирпичиков» — css классов. Некоторые неверно понимают данную концепцию и строят страницу из классов типа mar-bottom-15, float-left или pad-20, что тоже является большой ошибкой.
На всем сайте должен сохраняться единый стиль элементов, т.е. заголовок h2 на одной странице должен выглядеть так же, как и h2 на другой. Заголовки, абзацы, списки, панели, табы, пейджеры, контентные таблицы и т.д. по дизайну должны соблюдать единый стиль.
Перед тем как писать стили для новой страницы сайта следует проанализировать уже существующие css-файлы проекта, возможно там уже есть необходимые стили. Css файл не должен увеличиваться без необходимости.

В заключении скажу, что все описанное выше так же актуально и для JS.

Каскадные Таблицы Стилей

Оформление текста → ← Введение

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

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

Чтобы понять, что такое селектор, и понять, как он работает, рассмотрим несколько простых примеров:

*
Этому селектору соответствуют абсолютно все теги на странице, поэтому все его свойства будут применены к каждому тегу.
div
Свойства этого селектора будут применены к тегу <div>. Точно так же можно записать любой тег, опустив символы «<» и «>», в качестве селектора.
div *
Свойства повлияют на все элементы внутри <div>
div span
Свойства повлияют на все элементы <span> внутри <div>
div, span
Свойства повлияют на все элементы <span> и на все элементы <div>
.abc
Этому селектору соответствуют все теги, у которых присутствует атрибут class (класс, которому принадлежит тег, может быть одинаковым у нескольких тегов), равный abc
#abc
Этому селектору соответсвуют все теги, у которых присутсвует атрибут id (идентификатор, должен быть уникальным — встречаться на странице один раз), равный abc

Также допустимы и более сложные конструкции, о которых можно подробнее узнать на сайте спецификации w3c.org

Свойства у селектора описываются следующим образом:

селектор {
    свойство1: значения;
    свойство2: значения;
    ...
    свойствоN: значения;
}

Таких описаний селекторов может быть в файле сколько угодно.

Связать CSS файл с HTML страничкой можно, поместив между тегами <head> и </head> тег вида:

<link rel="stylesheet" href="путь/к/файлу.css" type="text/css" />

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

Единицы измерения

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

  • px — Пиксель. Употребляется для абсолютного задания размера шрифтов, блоков и т.д.
  • em — 1em равен размеру шрифта родительского элемента (0.5em — половине).
  • % — Проценты относительно родителя.

Существует возможность также задавать величины в дюймах (in), сантиметрах (cm), миллиметрах (mm), но это употребляется довольно редко.

Оформление текста → ← Введение

Создание HTML 5 структуры на практике

Статья, в которой рассматривается положение дел, связанных с созданием HTML5-структуры на практике, а также некоторые другие моменты, которые необходимо учитывать во время её разработки.

Перед тем как перейти к разработке структуры документа согласно спецификации HTML5, рассмотрим на каком уровне осуществляется её поддержка в браузерах и других пользовательских агентах.

Поддержка HTML5 структуры пользовательскими агентами

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

Чтобы авторы обратили на это внимание, разработчики спецификации опубликовали в стандарте HTML5 следующий абзац.

Фрагмент спецификации, содержащий сведения о поддержки HTML 5 структуры пользовательскими агентами

Основное содержимое вышеприведённого абзаца заключается в том, что они призывают авторов не полагаться полностью на структуру документа, описанной в этой спецификации, по крайне мере до тех пор, пока новая структура не получит широкую поддержку. Стандарт рекомендует авторам, как и прежде, создавать структуру веб-страниц с помощью элементов h2, h3, h4, h5, h5 и h6 или такую, которая была бы обратно совместимой с заголовочной.

Несмотря на расплывчатую поддержку HTML5 структуры документа пользовательскими агентами, авторам всё равно стоит задуматься о её внедрении. Это позволит сделать документ структурированным, семантическим и логичным с точки зрения HTML5.

До тех пор пока HTML 5 структура документа, не будет однозначно пониматься пользовательскими агентами, её создание будет обусловлено необходимостью использования обратной совместимости с HTML4. Таким образом, при создании структуры документа авторам следует учитывать то, что она должна быть правильной как в отношении HTML4, так и в отношении HTML5.

Создавать такую структуру не так уж сложно как это может показаться на первый взгляд. Для этого авторам всего лишь необходимо использовать внутри секционных элементов заголовки соответствующего ранга. Определяется ранг по уровню вложенности секционного элемента. Корневой секционный элемент имеет 1 ранг. Секции, которые расположены непосредственно в нём, имеют 2 ранг. Секции, которые расположены внутри секций второго ранга, соответственно имеют 3 ранг и т.д.

Создание HTML5-структуры обратно совместимой с заголовочной


<body>
  <!-- Заголовок секции документа (1 уровень) -->
  <h2>Заголовок документа</h2>
  <!-- Секция nav, вложенная в секцию документа (2 уровень) -->
  <nav>
      <h3>Навигация</h3>
      ...
  </nav>
  <!-- Секция article, вложенная в секцию документа (2 уровень) -->
  <article>
    <h3>Заголовок секции article</h3>
    ...
    <!-- Секция section, вложенная в секцию article 2 уровня -->
    <section>
      <h4>Заголовок секции section</h4>
      ...
    </section>
    <!-- Секция aside, вложенная в секцию article 2 уровня -->
    <aside>
      <h4>Заголовок секции aside</h4>
      ...
       <!-- Секция section, вложенная в секцию aside 3 уровня -->
      <section>
        <h5>Заголовок секции section</h5>
        ...
      </section>
    </aside>
    ...
  </article>
  ...
</body>

Вышеприведенный пример будет иметь следующую структуру (outline):


В HTML5:
[document] Заголовок документа
  [nav] Навигация
  [article] Заголовок секции article
    [section] Заголовок секции section
    [aside] Заголовок сеции aside
      [section] Заголовок секции section
В HTML4:
[h2] Заголовок документа
  [h3] Навигация
  [h3] Заголовок секции article
    [h4] Заголовок секции section
    [h4] Заголовок сеции aside
      [h5] Заголовок секции section

Процесс создания HTML5-структуры документа обратно совместимой с заголовочной (HTML4) рассмотрим на примере страницы блога, содержащей статью.

Начнём процесс проектирования с рассмотрения основных групп контента, из которых состоит данная страница.

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

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

Процесс создания HTML5-структуры документа обратно совместимой с заголовочной (HTML4) и оптимизированной под поисковые системы выполним поэтапно.

На 1 этапе разработаем HTML5-структуру страницы, не обращая внимание на то, как она будет выглядеть с точки зрения HTML4 (заголовочной структуры).

Для этого воспользуется элементами article, section, nav и aside из категории sectioning, и элементом h2 из группы heading.

Создание HTML5 структуры документа. Этап первый


<!-- Секция document (документа) -->
<body>
  <h2>Название сайта</h2>
  <!-- Секция nav (навигация) -->
  <nav>
    <h2>Навигация по сайту</h2>
  </nav>
  <!-- Секция article (статьи) -->;
  <article>
    <h2>Название статьи</h2>
    <section>
      <h2>1 раздел статьи</h2>
      ...
      <section>
        <h2>1 подраздел 1 раздела</h2>
        ...
      </section>
    </section>
    <section>
      <h2>2 раздел статьи</h2>
      ...
      <section>
        <h2>1 подраздел 2 раздела</h2>
        ...
      </section>
      <section>
        <h2>1 подраздел 2 раздела</h2>
        ...
      </section>
    </section>
    <section>
      <h2>3 раздел статьи</h2>
      ...
    </section>
    <section>
      <h2>Комментарии к статье</h2>
      ...
    </section>
  </article>
  <!-- Секция aside (содержимое, косвенно связанное с остальным содержимым страницы) -->
  <aside>
    <h2>Дополнительные разделы</h2>
    <section>
      <h2>Поиск</h2>
      ...
    </section>
    <section>
      <h2>Облако тегов</h2>
      ...
    </section>
    <section>
      <h2>Комментарии</h2>
      ...
    </section>
    <section>
      <h2>Статьи</h2>
      ...
    </section>
    <section>
      <h2>Голосование</h2>
      ...
    </section>
    <section>
      <h2>О блоге</h2>
      ...
    </section>
  </aside>
</body>


HTML5 структура страницы:
[document] Название сайта
  [nav] Навигация по сайту
  [article] Название статьи
    [section] 1 раздел статьи
      [section] 1 подраздел 1 раздела
    [section] 2 раздел статьи
      [section] 1 подраздел 2 раздела
      [section] 2 подраздел 2 раздела
    [section] 3 раздел статьи
    [section] Комментарии к статье
  [aside] Дополнительные разделы
    [section] Поиск
    [section] Облако тегов
    [section] Комментарии
    [section] Статьи
    [section] Голосование
    [section] О блоге

HTML4 структура страницы:
[h2] Название сайта
[h2] Навигация по сайту
[h2] Название статьи
[h2] 1 раздел статьи
[h2] 1 подраздел 1 раздела
[h2] 2 раздел статьи
[h2] 1 подраздел 2 раздела
[h2] 2 подраздел 2 раздела
[h2] 3 раздел статьи
[h2] Комментарии к статье
[h2] Дополнительные разделы
[h2] Поиск
[h2] Облако тегов
[h2] Комментарии
[h2] Статьи
[h2] Голосование
[h2] О блоге

На 2 этапе доработаем структуру, полученную на 1 этапе, таким образом, чтобы она была обратно совместимой с заголовочной.

Создание HTML5 структуры документа. Этап второй


<!-- Секция document (документа) -->
<body>
  <h2>Название сайта</h2>
  <!-- Секция nav (навигация) -->
  <nav>
    <h3>Навигация по сайту</h3>
  </nav>
  <!-- Секция article (статьи) -->;
  <article>
    <h3>Название статьи</h3>
    <section>
      <h4>1 раздел статьи</h4>
      ...
      <section>
        <h5>1 подраздел 1 раздела</h5>
        ...
      </section>
    </section>
    <section>
      <h4>2 раздел статьи</h4>
      ...
      <section>
        <h5>1 подраздел 2 раздела</h5>
        ...
      </section>
      <section>
        <h5>1 подраздел 2 раздела</h5>
        ...
      </section>
    </section>
    <section>
      <h4>3 раздел статьи</h4>
      ...
    </section>
    <section>
      <h4>Комментарии к статье</h4>
      ...
    </section>
  </article>
  <!-- Секция aside (содержимое, косвенно связанное с остальным содержимым страницы) -->
  <aside>
    <h3>Дополнительные разделы</h3>
    <section>
      <h4>Поиск</h4>
      ...
    </section>
    <section>
      <h4>Облако тегов</h4>
      ...
    </section>
    <section>
      <h4>Комментарии</h4>
      ...
    </section>
    <section>
      <h4>Статьи</h4>
      ...
    </section>
    <section>
      <h4>Голосование</h4>
      ...
    </section>
    <section>
      <h4>О блоге</h4>
      ...
    </section>
  </aside>
</body>


HTML5 структура страницы:
[document] Название сайта
  [nav] Навигация по сайту
  [article] Название статьи
    [section] 1 раздел статьи
      [section] 1 подраздел 1 раздела
    [section] 2 раздел статьи
      [section] 1 подраздел 2 раздела
      [section] 2 подраздел 2 раздела
    [section] 3 раздел статьи
    [section] Комментарии к статье
  [aside] Дополнительные разделы
    [section] Поиск
    [section] Облако тегов
    [section] Комментарии
    [section] Статьи
    [section] Голосование
    [section] О блоге

HTML4 структура страницы:
[h2] Название сайта
  [h3] Навигация по сайту
  [h3] Название статьи
    [h4] 1 раздел статьи
      [h5] 1 подраздел 1 раздела
    [h4] 2 раздел статьи
      [h5] 1 подраздел 2 раздела
      [h5] 2 подраздел 2 раздела
    [h4] 3 раздел статьи
    [h4] Комментарии к статье
  [h3] Дополнительные разделы
    [h4] Поиск
    [h4] Облако тегов
    [h4] Комментарии
    [h4] Статьи
    [h4] Голосование
    [h4] О блоге

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

Создание HTML5 структуры документа. Этап третий


<body>
  ...
  <h2>Название статьи</h2>
  <section>
    <h3>1 раздел статьи</h3>
    ...
    <section>
      <h4>1 подраздел 1 раздела</h4>
      ...
    </section>
  </section>
  <section>
    <h3>2 раздел статьи</h3>
    ...
    <section>
      <h4>1 подраздел 2 раздела</h4>
      ...
    </section>
    <section>
      <h4>1 подраздел 2 раздела</h4>
      ...
    </section>
  </section>
  <section>
    <h3>3 раздел статьи</h3>
    ...
  </section>
  <section>
    <h4>Комментарии к статье</h4>
    ...
  </section>
  <aside>
    <h5>Дополнительные разделы</h5>
    <section>
      <h5>Поиск</h5>
      ...
    </section>
    <section>
      <h5>Облако тегов</h5>
      ...
    </section>
    <section>
      <h5>Комментарии</h5>
      ...
    </section>
    <section>
      <h5>Статьи</h5>
      ...
    </section>
    <section>
      <h5>Голосование</h5>
      ...
    </section>
    <section>
      <h5>О блоге</h5>
      ...
    </section>
  </aside>
</body>


HTML5 структура страницы:
[document] Название статьи
  [section] 1 раздел статьи
    [section] 1 подраздел 1 раздела
  [section] 2 раздел статьи
    [section] 1 подраздел 2 раздела
    [section] 2 подраздел 2 раздела
  [section] 3 раздел статьи
  [section] Комментарии к статье
[aside] Дополнительные разделы
  [section] Поиск
  [section] Облако тегов
  [section] Комментарии
  [section] Статьи
  [section] Голосование
  [section] О блоге

HTML4 структура страницы:
[h2] Название статьи
  [h3] 1 раздел статьи
    [h4] 1 подраздел 1 раздела
  [h3] 2 раздел статьи
    [h4] 1 подраздел 2 раздела
    [h4] 2 подраздел 2 раздела
  [h3] 3 раздел статьи
    [h4] Комментарии к статье
      [h5] Дополнительные разделы
        [h5] Поиск
        [h5] Облако тегов
        [h5] Комментарии
        [h5] Статьи
        [h5] Голосование
        [h5] О блоге

Проверить разработанную структуру документа можно с помощью следующих инструментов:

  • расширения «HTML5 Outliner» для браузера Google Chrome;
  • онлайн инструмента HTML5 Outliner;
  • сервиса проверки разметки W3C, доступного по адресу https://validator.w3.org/;
  • расширения headingsMap 2.1 для браузера Mozilla Firefox.

Сервис W3C предназначен в первую очередь для проверки соответствия кода HTML-документа выбранной спецификации (HTML 4.01, HTML5 и др.). Кроме этого он также позволяет также проверить структуру документа, если будет включена соответствующая опция.

>Проверка структуры документа с помощью сервиса W3C

Расширение HeadingsMap для браузера Mozilla Firefox — это очень удобный инструмент, который позволяет проверить структуру документа в соответствии со спецификацией HTML5 и HTML4.

Проверка структуры документа с помощью HeadingsMap

В заключение можно отметить то, что авторам при создании структуры документа, необходимо её сделать не только соответствующей спецификации HTML5, но и HTML4. Это утверждение будет ещё актуально довольно продолжительное время, и закончит своё существование только тогда, когда основная масса пользовательских агентов обзаведётся полноценной поддержкой структурных алгоритмов, работающих в соответствии со спецификацией HTML5.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *