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

.class {border: 1px solid #000; padding: 0; margin: 0;}

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

Об этом мистер Снук писал почти четыре года назад :).

Однако вам легче всего читать!

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

Но кое-что я скажу:

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

Лично я кодирую свой CSS так:

* { /* css */ }
body { /* css */ }
#wrapper { /* css */ }
#innerwrapper { /* css */ }

#content { /* css */ }
#content div { /* css */ }
#content span { /* css */ }
#content etc { /* css */ }

#header { /* css */ }
#header etc { /* css */ }

#footer { /* css */ }
#footer etc { /* css */ }

.class1 { /* css */ }
.class2 { /* css */ }
.class3 { /* css */ }
.classn { /* css */ }

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

Поскольку фактический порядок является важной частью того, как применяется ваш CSS, кажется немного глупым предлагать «алфавитный» вариант.

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

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

Выделите общие стили. Не стили, которые просто совпадают, стили, которые являются предназначена, будут одинаковыми - где изменение стиля для одного селектора, вероятно, будет означать, что вы захотите изменить и другой. Я поместил пример этого стиля в другой пост: Создайте переменную в файле CSS для использования в этом файле CSS..

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

Я использую такой порядок:

1. Общие правила стиля, обычно применяемые к голым элементам (a, ul, ol и т. д.), Но они также могут быть общими классами (.button, .error)
2. Правила макета страницы применяются к большинству / всем страницам
3. Индивидуальные правила макета страницы

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

Я обычно организовываю свой CSS следующим образом:

1. reset.css
2. base.css: устанавливаю макет для основных разделов страницы
   1. общие стили
   2. Заголовок
   3. Nav
   4. содержание
   5. нижний колонтитул
3. additional- [имя страницы] .css: классы, которые используются только на одной странице

Файлы CSS кэшируются на клиенте. Поэтому рекомендуется хранить все стили в одном файле. Но при разработке я считаю полезным структурировать свой CSS по доменам.

Например: reset.css, design.css, text.css и так далее. Когда я выпускаю финальный продукт, я объединяю все стили в один файл.

Еще один полезный совет - сосредоточьтесь на правилах, а не на стилях.

Пока:

ul li
{
    margin-left: 10px;
    padding: 0;
}

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

Вместо этого я использую такой формат:

rule { property: value; property: value; }

rule { property: value; property: value; }

Вот что я делаю. У меня есть индексная страница CSS без директив, которая вызывает разные файлы. Вот небольшой пример:

@import url("stylesheet-name/complete-reset.css");
@import url("stylesheet-name/colors.css");
@import url("stylesheet-name/structure.css");
@import url("stylesheet-name/html-tags.css");
@import url("stylesheet-name/menu-items.css");
@import url("stylesheet-name/portfolio.css");
@import url("stylesheet-name/error-messages.css");

Начинается с полного сброса. Следующий файл определяет цветовую палитру для удобства. Затем я стилизую основные <div/>, которые определяют макет, верхний колонтитул, нижний колонтитул, количество столбцов, где они подходят и т. д. Теги html определяют <body/>, <h1/>, <p/>, т и т. д. Затем идут определенные разделы сайта .

Это очень масштабно и очень ясно. Гораздо удобнее находить код для изменения и добавлять новые разделы.

Для начала взгляните на эти три слайд-шоу:

• Красивый поддерживаемый CSS
• Поддерживаемый CSS
• Эффективный, удобный в обслуживании модульный CSS

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

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

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

#content {
    /* css */
}
    #content div {
        /* css */
    }
    #content span {
        /* css */
    }
    #content etc {
        /* css */
    }

#header {
    /* css */
}
    #header etc {
        /* css */
    }

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

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

Разделяю ли я свой CSS на несколько файлов и в каких файлах зависит от размера и сложности сайта и CSS. У меня всегда есть хотя бы reset.css. Обычно это сопровождается layout.css для общего макета страницы, nav.css, если меню навигации сайта немного усложняется, и forms.css, если у меня достаточно CSS для стилизации моих форм. Помимо этого, я тоже все еще разбираюсь в этом. У меня могут быть colors.css и type.css/fonts.css, чтобы разделить цвета / графику и типографику, base.css, чтобы обеспечить полный базовый стиль для всех тегов HTML ...

Раньше я постоянно об этом беспокоился, но на помощь пришел Firebug.

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

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

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

БЭМ (Блок, Элемент, Модификатор)

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

Блокировать

Автономная сущность, имеющая смысл сама по себе, например:

header, container, menu, checkbox, input

Элемент

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

menu item, list item, checkbox caption, header title

Модификатор

Флаги на блоках или элементах. Используйте их, чтобы изменить внешний вид или поведение:

disabled, highlighted, checked, fixed, size big, color yellow

OOCSS

The purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain.

OOCSS основан на двух основных принципах:

1. Отделение структуры от кожи

This means to define repeating visual features (like background and border styles) as separate “skins” that you can mix-and-match with your various objects to achieve a large amount of visual variety without much code. See the module object and its skins.

2. Разделение контейнеров и содержимого

Essentially, this means “rarely use location-dependent styles”. An object should look the same no matter where you put it. So instead of styling a specific with .myObject h2 {...}, create and apply a class that describes the in question, like . This gives you the assurance that: (1) all unclassed s will look the same; (2) all elements with the category class (called a mixin) will look the same; and 3) you won’t need to create an override style for the case when you actually do want .myObject h2 to look like the normal .

SMACSS

SMACSS is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process. It is an attempt to document a consistent approach to site development when using CSS.

At the very core of SMACSS is categorization. By categorizing CSS rules, we begin to see patterns and can define better practices around each of these patterns.

Есть пять типов категорий:

/* Base */

/* Layout */

/* Modules */

/* State */

/* Theme */

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

Макет Будет содержать всю навигацию, панировочные сухари, карты сайта и т. д. И т. Д.

Модули Содержат стили для конкретной области, такие как стили контактной формы, плитки домашней страницы, список продуктов и т. д. И т. Д.

Состояние Содержит классы состояний, такие как isSelected, isActive, hasError, wasSuccessful и т. д.

Тема Содержит любые стили, связанные с тематикой.

Здесь слишком много подробностей, но обратите внимание на и другие:

• КостюмCSS
• AtomicCSS (не атомарный дизайн)
• oCSS (обычный CSS)

ITCSS

Гарри Робертс (CSS Wizardry)

Определяет глобальное пространство имен и каскад и помогает поддерживать низкую специфичность селекторов.

Состав

Первые два применимы только в том случае, если вы используете препроцессор.

1. (Настройки)
2. (Инструменты)
3. Дженерики
4. Элементы
5. Объекты
6. Составные части
7. Козыри

Обычно я делаю так:

1. <link rel = "stylesheet" href = "css/style.css">

2. В style.css я @import:

   @import url(colors.css);
   @import url(grid.css);
   @import url(custom.css); + some more files (if needed)
   

3. В colors.css я @import следующее (при использовании настраиваемых свойств CSS):

   @import url(root/variable.css);
   

Все в порядке и легко получить любую часть кода для редактирования. Буду рад, если это как-то поможет.