CSS-o-Gram

CSSG описывает конструкцию сущности привычным каскадом CSS классов. Наименование классов происходит в соответствии с принятыми в компании стандартами. Сторонние проектные классы указываются рядом с основными. Вспомогательные (косметические) классы как правило не указываются, за исключением особенных случаев (рассматриваются во второй части).

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

Ваша первая CSSG

Предположим, HTML выглядит примерно так:

<div class="post">
	<div class="post_h">
		<div class="post_h_name">Заголовок</div>
	</div>
	<div class="post_b">
		Контент
	</div>
	<div class="post_f">
		Дополнительные сведения
	</div>
</div>

CSS примерно так:

.post {
	font-size: 14px;
}

.post_h {
	font-weight: bold;
}

и т.д.

CSSG иллюстрирует структуру HTML в терминологии CSS и располагается в документе до правил:

/*

    post
        post_h
            post_h_name
            post_h_date

        post_b
        	...

        post_f

*/

.post {
	font-size: 14px;
}

Если вы работали с HAML или имеете представление о его синтаксисе, конструкция более чем привычна. По умолчанию все элементы конструкии не имеют определенного DOM-представления, т.е. класс первичнее тэга. Когда необходимо подчеркнуть связь конкретного тэга с классом, используется привычная запись zen-coding:

/*

    post
        post_h
            post_h_name
            i.post_h_date

*/

Несколько правил:

потомки элементов отбиваются табами

соседние элементы разделяютс дополнительной строкой в случае наличия потомков

конструкция CSSG для удобства прочтения не должна превышать высоту экрана

Ключевой контент

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

/*

    post
        post_h
            post_h_name
            	...
            post_h_date
            	...

        post_b
        	...

        post_f
        	...

*/

Ключевой контент может располагаться рядом с другой важной частью структуры:

/*

    post
        post_h
            post_h_name
            post_h_date

        post_b
        	...
			post_b_author

        post_f

*/

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

/*

    post
        post_h
            {date}
        post_b
            post_cnt
                {... article}

*/

Ссылки

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

>> начало CSS

/*

    post
        #header
        #body
        #aux

*/

>> продолжение CSS

/* #header

    post_h
        post_h_name

*/

ссылка на составную часть конструкции обозначается через привычный символ - #

Модификаторы и проектные классы

Наш HTML меняется - в зависимости от контекста или сам по себе. Модификаторы в CSS позволяют видоизменять сущность. Модификатор представляет из себя класс типа .post__new или .__compact, который указывается рядом с основным классом. Проектный класс (микс-ин) позволяет переиспользовать сущность и указывается самостоятельно или отдельно от основного класса, например - .post-featured.

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

/*

    post                        -project __new __featured
        post_h
        post_b
            post_b              __compact

*/

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

подробнее о модификаторах во второй части

Опциональные части

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

/*

    post
        [post_teaser]
        post_h
        post_b
            [
            post_b_top
                post_b_top_tx
            ]

*/

Если опциональная часть является оберткой, используем следующий синтаксис:

/*

    [post_w]
        post
            post_h
            post_b
            	[post_b_cnt]
            		[post_b_tx]
            			...
            		[/post_b_tx]
        		[/post_b_cnt]
    [/post_w]

*/

синтаксис переносов и пробелов в данном случае не является догмой. Здесь на первом месте выступает удобство прочтения и чистота кода

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

Неизменяемые блоки

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

Когда нельзя их игнорировать или наоборот - необходимо проиллютрировать их наличие применяется следующий синтаксис:

/*

    post
        post_h
        post_b
        post_f
            post_f_ac
                <social>

*/

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

в большой команде разработчиков список должен быть один