Принципы организации css кода и его семантика – какие существуют варианты и чем отличаются?

@TrogWarZ · Регистрация: 01.09.2012

Студворк — интернет-сервис помощи студентам

Доброго времени суток!

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

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

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

CSS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/* root */
.wrapper {}
 
/* 
 * Reset or maybe styling for some common code?
 * It's okay too for this purposes.
 */
.nav {}
 
    /* horizontal collision */
    .wrapper .header {}
        .wrapper .header .nav {}
            .wrapper .header .nav .item {}
 
    .wrapper .sidebar {}
        .wrapper .sidebar .nav {}
            .wrapper .sidebar .nav .item {}
 
    /* in depth collision */
    .wrapper .content {}
        .wrapper .content .news {}
            .wrapper .content .news > .item {}
                .wrapper .content .news > .item .comments {}
                    .wrapper .content .news > .item .comments > .item {}
 
    .wrapper .content {}
        .wrapper .content .news {}
            .wrapper .content .news > .item {}
                .wrapper .content .news > .item .comments {}
                    .wrapper .content .news > .item .comments > .item {}

HTML5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<!-- root -->
<div class="wrapper">
 
    <!-- horizontal collision -->
    <div class="header">
        <div class="nav">
            <div class="item"></div>
            <div class="item"></div>
            <div class="item"></div>
        </div>
    </div>
 
    <div class="sidebar">
        <div class="nav">
            <div class="item"></div>
            <div class="item"></div>
            <div class="item"></div>
        </div>
    </div>
 
    <!-- in depth collision -->
    <div class="content">
        <div class="news">
            <div class="item">
                <div class="comments">
                    <div class="item"></div>
                </div>
            </div>
            <div class="item">
                <div class="comments">
                    <div class="item"></div>
                </div>
            </div>
            <div class="item">
                <div class="comments">
                    <div class="item"></div>
                </div>
            </div>
        </div>
    </div>
 
</div><!-- root -->

Плюсы: на каждом новом уровне только уточнение стиля, каскадность ("cascading style sheets" же), универсальность, нейтральные формулировки вроде "item" для блоков с неизвестным содержимым, отсутствие дублирования правил, лёгкая читабельность html.
Минусы: во избежание коллизий – жуткая и огромная многословность правил (только посмотрите на длину строки стиля комментария!), редактирование стиля не_конечного звена может сломать что угодно в слоях ниже, неперносимость (особенно если стиль зависит от верхних).

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

CSS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/* root */
.wrapper {}
 
/* reset or common code */
.common-nav {}
 
/* horizontal collision */
.header {}
.header-nav {}
.header-nav-item {}
 
.sidebar {}
.sidebar-nav {}
.sidebar-nav-item {}
 
/* in depth collision */
.content {}
.content-news {}
.content-news-post {}
.content-news-post-comments {}
.content-news-post-comments-comment {}
 
.content {}
.content-news {}
.content-news-post {}
.content-news-post-comments {}
.content-news-post-comments-comment {}

HTML5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<!-- root -->
<div class="wrapper">
 
    <!-- horizontal collision -->
    <div class="header">
        <div class="header-nav common-nav">
            <div class="header-nav-item"></div>
            <div class="header-nav-item"></div>
            <div class="header-nav-item"></div>
        </div>
    </div>
 
    <div class="sidebar">
        <div class="sidebar-nav common-nav">
            <div class="sidebar-nav-item"></div>
            <div class="sidebar-nav-item"></div>
            <div class="sidebar-nav-item"></div>
        </div>
    </div>
 
    <!-- in depth collision -->
    <div class="content">
        <div class="content-news">
            <div class="content-news-post">
                <div class="content-news-post-comments">
                    <div class="content-news-post-comments-comment"></div>
                </div>
            </div>
            <div class="content-news-post">
                <div class="content-news-post-comments">
                    <div class="content-news-post-comments-comment"></div>
                </div>
            </div>
            <div class="content-news-post">
                <div class="content-news-post-comments">
                    <div class="content-news-post-comments-comment"></div>
                </div>
            </div>
        </div>
    </div>
 
</div><!-- root -->

Плюсы: отсутствие коллизий от слова совсем, блоки могут перемещаться между собой, между любой частью проекта или даже между проектами – изменение стиля не требуется, добавлением общих по наименованию стилей можно добиться более сухого кода тем самым применять готовые стилевые шаблоны дизайна.
Минусы: в плане читабельности и длине правил всё ещё хуже (тире вместо точек да ещё и html раздувается), при пересортировке блоков между собой семантика наименования классов может потеряться или даже стать противоположной реальности (придётся рефакторить в том числе и их).

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

@Alorian · 16.07.2013, 06:30

Была такая тема:
Как Вы форматируете свои CSS файлы?

Повторюсь оттуда же. Я пользуюсь примерно такими правилами:
http://html-agency.ru/docs/pra... menta.html
Там описан похожий на ваш первый вариант, только по другому структурированный. Если все в одно дерево пихать, то отступов сильно много будет. Отдельные ветки дерева(блоки) выносятся на первый уровень.

@Forastero · 16.07.2013, 09:04

Мое личное мнение - селекторы вида

CSS
1
.content-news-post-comments-comment

и

CSS
1
.wrapper .content .news > .item .comments > .item

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

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

@Alorian · 16.07.2013, 09:12

Сообщение от Forastero

селекторы вида ... Никуда не годятся

Соглашусь. Писать полный путь аж от body для каждого элемента абсолютно бесполезно.

@TrogWarZ · 16.07.2013, 13:03 **[ТС]**

Сообщение от Alorian

Была такая тема:
Как Вы форматируете свои CSS файлы?

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

CSS
1
2
3
4
5
6
7
8
9
10
11
12
.span1  { width:  82px; }
.span2  { width: 164px; }
.span3  { width: 246px; }
.span4  { width: 328px; }
.span5  { width: 410px; }
.span6  { width: 492px; }
.span7  { width: 574px; }
.span8  { width: 656px; }
.span9  { width: 738px; }
.span10 { width: 820px; }
.span11 { width: 902px; }
.span12 { width: 984px; }

Сообщение от Alorian

http://html-agency.ru/docs/pravila-n...dokumenta.html

Айдишники для стилей? Зачем, в чём выигрыш данного подхода? (я разграничиваю: для стилей css классы, а для поведения js – id).
Хотя, кажется, идею уловил – логические разделение на "сброс", "структуру" и "конкретные блоки"? Это интересно, спасибо за идею! Попробую писать так у себя.

Сообщение от Alorian

Если все в одно дерево пихать, то отступов сильно много будет.

Да, согласен, именно отступы (вкупе с длиной строки) мне и не нравится в древовидном подходе.

Сообщение от Forastero

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

Насколько я знаю нисколько, производительность на одинаковом уровне. Например, в случае правила `.block ul li *` парсер сначала выделит селектор `*`, затем найдёт `li *`, только потом отфильтрует найденную кучу по `ul li *` и так далее. Соответственно, разница в конкретном примере из САБЖа между `.content-news-post-comments-comment` и `.wrapper .content .news > .item .comments > .item` в два раза (т.к. для любой выборки трёх .item придётся парсеру сначала просмотреть все шесть).
Лично я не встречался с настолько огромными проектами (десятки тысяч узлов), чтобы селекторы (при условии табу на "звёздочку") представляли из себя bottleneck. Кстати, "независимый" вариант решает эту проблему by design.

Сообщение от Alorian

Писать полный путь аж от body для каждого элемента абсолютно бесполезно.

Если это какой-нибудь `.wrapper`, то согласен.

@Alorian · 16.07.2013, 13:12

Сообщение от TrogWarZ

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

Мне так больше нравится. Сразу можно все взглядом охватить, а не десятки экранов листать.

Сообщение от TrogWarZ

Хотя, кажется, идею уловил – логические разделение на "сброс", "структуру" и "конкретные блоки"

Ну да. Для этого и id. Структурные блоки вроде #header, #middle, #footer, #wrapper сразу видно становится.
Только еще отдельно контентные стили, для самого текста. Четвертый логический блок.

@TrogWarZ · 16.07.2013, 13:17 **[ТС]**

Сообщение от Alorian

Только еще отдельно контентные стили, для самого текста. Четвертый логический блок.

Вот как-раз его смысл я плохо понял. Почему `input.button`именно там? И зачем нужен класс `.text`? Его, получается, нужно добавлять к каждому блоку, в котором вообще присутствует текст?
Я такие вещи обычно размещал в блоке "reset". В чём идеологическая разница этих блоков?

@Alorian · 16.07.2013, 13:21

Сообщение от TrogWarZ

И зачем нужен класс `.text`?

Там .text p{}. Отступы у абзацев текста.
Туда например можно вынести смайлы, отступы, обтекание картинок внутри текста, иконки для ссылок в тексте, таблицы в тексте и т.д. То есть все то что будет использовать редактор сайта потом при добавлении текстов, при добавлении контента.

Новые блоги и статьи Все статьи Все блоги /
Установка Android SDK, NDK, JDK, CMake и т.д. 8Observer8 25.01.2026 Содержание блога Перейдите по ссылке: https:/ / developer. android. com/ studio и в самом низу страницы кликните по архиву "commandlinetools-win-xxxxxx_latest. zip" Извлеките архив и вы увидите. . .	Вывод текста со шрифтом TTF на Android с помощью библиотеки SDL3_ttf 8Observer8 25.01.2026 Содержание блога Если у вас не установлены Android SDK, NDK, JDK, и т. д. то сделайте это по следующей инструкции: Установка Android SDK, NDK, JDK, CMake и т. д. Сборка примера Скачайте. . .	Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .
Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом	http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .	http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь(не выше 3-го порядка) постоянного тока с элементами R, L, C, k(ключ), U, E, J. Программа находит переходные токи и напряжения на элементах схемы классическим методом(1 и 2 з-ны. . .

@Alorian 694 / 534 / 40 Регистрация: 22.06.2009 Сообщений: 1,293
	16.07.2013, 06:30
	Была такая тема: Как Вы форматируете свои CSS файлы? Повторюсь оттуда же. Я пользуюсь примерно такими правилами: http://html-agency.ru/docs/pra... menta.html Там описан похожий на ваш первый вариант, только по другому структурированный. Если все в одно дерево пихать, то отступов сильно много будет. Отдельные ветки дерева(блоки) выносятся на первый уровень. 0