Управление CSS Explosion

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

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

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

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

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

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

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

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

• Рефакторинг рано, рефакторинг часто. Часто очищайте CSS-файлы, объединяйте несколько определений одного и того же класса. Удалите устаревшие определения немедленно .

• При добавлении CSS во время исправления ошибок, оставьте комментарий о том, что делает изменение («Это нужно, чтобы окно было выровнено в IE <7»)

• Избегайте избыточностей, например, определяя то же самое в .classnameи .classname:hover.

• Используйте комментарии, /** Head **/чтобы построить четкую структуру.

• Используйте инструмент prettifier, который помогает поддерживать постоянный стиль. Я использую Polystyle , которым я вполне доволен (стоит 15 долларов, но деньги потрачены не зря). Также есть бесплатные (например, Code Beautifier на основе CSS Tidy , инструмента с открытым исходным кодом).

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

• Используйте семантику, избегайте супа DIV - используйте <ul>s для меню, например.

• Определите все на как можно более низком уровне (например, семейство шрифтов по умолчанию, цвет и размер в body) и используйте, inheritгде это возможно

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

• Если вы работаете в команде, подчеркните необходимость качества и стандартов для CSS-файлов. Все хорошо разбираются в стандартах кодирования на своих языках программирования, но мало кто знает, что это необходимо и для CSS.

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

• Не работать с !important. Не только потому, что IE = <7 не может справиться с этим. В сложной структуре использование !importantчасто заманчиво для изменения поведения, источник которого не может быть найден, но это яд для долгосрочного обслуживания.

Создание разумных классов

Вот как мне нравится создавать разумные занятия.

Сначала я применяю глобальные настройки:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

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

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

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

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

Например, допустим, у вас есть три уровня навигационных меню. Эти три меню выглядят по-разному, но они также имеют определенные характеристики. Например, все <ul>они имеют одинаковый размер шрифта, и все элементы расположены рядом друг с другом (в отличие от отображения по умолчанию для an ul). Кроме того, ни одно из меню не имеет маркеров ( list-style-type).

Сначала определите общие характеристики в классе с именем menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

затем определите конкретные характеристики каждого из трех меню. Уровень 1 - 40 пикселей в высоту; уровни 2 и 3, 20 пикселей.

Примечание: вы также можете использовать несколько классов для этого, но Internet Explorer 6 имеет проблемы с несколькими классами , поэтому в этом примере используется ids.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

Разметка для меню будет выглядеть так:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

Если у вас есть семантически похожие элементы на странице - например, эти три меню - попробуйте сначала определить общие черты и поместить их в класс; затем определите конкретные свойства и примените их к классам или, если вам нужно поддерживать Internet Explorer 6, идентификаторы.

Разные советы по HTML

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

• Если возможно, присвойте телу каждой страницы уникальный класс: <body class='contactpage'>это позволяет очень легко добавлять специфичные для страницы настройки в таблицу стилей:

  body.contactpage div.container ul.mainmenu li { color: green }

• При автоматическом создании меню добавьте как можно больше контекста CSS, чтобы позже можно было использовать расширенные стили. Например:

  <ul class="mainmenu">
   <li class="item_first item_active item_1"> First item </li> 
   <li class="item_2"> Second item </li> 
   <li class="item_3"> Third item </li> 
   <li class="item_last item_4"> Fourth item </li> 
  </ul>

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

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

Вот только 4 примера:

• Соглашения CSS / Модели макета кода
• Существуют ли какие-либо стандарты CSS, которым я должен следовать при написании моей первой таблицы стилей?
• Какой метод лучше всего привести в порядок CSS?
• Лучшие практики - Форматирование таблицы стилей CSS

На все 4 мои ответы включали советы по загрузке и чтению PDF CSS-систем Натали Даун . (В PDF включены тонны заметок, которых нет на слайдах, так что читайте PDF!). Принять к сведению ее предложения по организации.

РЕДАКТИРОВАТЬ (2014/02/05) четыре года спустя, я бы сказал:

• Используйте препроцессор CSS и управляйте своими файлами как частными (я лично предпочитаю Sass с Compass, но Less тоже неплох, а есть и другие)
• Читайте о таких понятиях, как OOCSS , SMACSS и BEM или getbem .
• Посмотрите, как структурированы такие популярные CSS-фреймворки, как Bootstrap и Zurb Foundation . И не стоит сбрасывать со счетов менее популярные фреймворки - Inuit интересный, но есть множество других.
• Объедините / минимизируйте свои файлы с помощью шага сборки на сервере непрерывной интеграции и / или запускающего задачи, такого как Grunt или Gulp.

Не пишите заголовки в CSS

Просто разделите разделы на файлы. Любые комментарии CSS, должны быть просто комментариями.

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

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

Если вы должны написать заголовки, имейте оглавление в начале файла

Заголовки в оглавлении должны полностью совпадать с заголовками, которые вы напишете позже. Больно искать заголовки. Чтобы добавить к проблеме, как кто-то должен знать, что у вас есть еще один заголовок после вашего первого? пс. не добавляйте doc-like * (звездочку) в начале каждой строки при написании оглавлений, это только делает более раздражающим выделение текста.

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

Пишите комментарии с правилами или в пределах правил, а не вне блока

Прежде всего, когда вы редактируете скрипт, есть вероятность 50/50, что вы обратите внимание на то, что находится за пределами блока правил (особенно, если это большой текстовый фрагмент;)). Во-вторых, нет (почти) ни одного случая, когда вам понадобился бы «комментарий» снаружи. Если это за пределами, это 99% времени названия, так что держите это так.

Разделить страницу на компоненты

Компоненты должны иметь position:relative, нет paddingи нет margin, большую часть времени. Это упрощает% правила много, а также позволяют гораздо проще absolute:position«ИНГИ элементов, так как если есть абсолютный позиционированный контейнер абсолютный позиционируемый элемент будет использовать контейнер при вычислении top, right, bottom, leftсвойства.

Большинство DIV в документе HTML5 обычно являются компонентом.

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

Повторюсь с примером страницы QA:

#navigation
#question
#answers
#answers .answer
etc.

Разбивая страницу на компоненты, вы делите свою работу на управляемые блоки.

Положите правила с совокупным эффектом на одной линии.

Например border, marginи padding(но не outline) все добавляют к размерам и размеру элемента, который вы стилизуете.

position: absolute; top: 10px; right: 10px;

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

padding: 10px; margin: 20px;
border: 1px solid black;

Используйте стенографию, когда это возможно:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

Никогда не повторять селектор

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

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

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

Прежде всего, теги DIV и SPAN являются исключением: вы никогда не должны их использовать, никогда! ;) Используйте их только для прикрепления класса / идентификатора.

Эта...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

Должно быть написано так:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Потому что лишние висящие DIV там ничего не добавляют к селектору. Они также вынуждают ненужное правило тега. Например, если бы вы изменили .answerс a divна a, articleваш стиль сломался бы.

Или, если вы предпочитаете больше ясности:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Причина в том, что border-collapseсвойство является специальным свойством, которое имеет смысл только применительно к table. Если .statisticsэто не так, это tableне должно применяться.

Общие правила - это зло!

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

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

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

Вещи, как это ...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

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

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

В основном это читается как:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

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

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

Предположим, у вас есть paginationкомпонент. Вы используете его во многих местах на вашем сайте. Это было бы хорошим примером того, когда вы будете писать общее правило. Допустим, вам display:blockданы ссылки на отдельные номера страниц и выделите темно-серый фон. Чтобы они были видны, у вас должны быть такие правила:

.pagination .pagelist a {
    color: #fff;
}

Теперь предположим, что вы используете свою нумерацию страниц для списка ответов, вы можете столкнуться с чем-то вроде этого

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

Это сделает ваши белые ссылки черными, чего вы не хотите.

Неправильный способ исправить это:

.pagination .pagelist a {
    color: #fff !important;
}

Правильный способ исправить это:

#answers .header .pagination .pagelist a {
    color: #fff;
}

Сложные «логические» комментарии не работают :)

Если вы напишите что-то вроде: «это значение зависит от бла-бла в сочетании с высотой бла-бла», это просто неизбежно, вы допустите ошибку и все упадет, как карточный домик.

Сделайте ваши комментарии простыми; если вам нужны «логические операции», рассмотрите один из тех языков шаблонов CSS, как SASS или LESS .

Как вы пишете цветной поддон?

Оставь это на конец. Есть файл для всего вашего цветового поддона. Без этого файла ваш стиль должен по-прежнему иметь пригодный для использования цветовой палитру в правилах. Ваш цветной поддон должен быть перезаписан. Вы связываете селекторы, используя родительский компонент очень высокого уровня (например #page), а затем пишете свой стиль как самодостаточный блок правил. Это может быть просто цвет или что-то еще.

например.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

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

Меньше имен, требуется меньше памяти, что облегчает чтение кода

Лучше использовать меньше имен. В идеале используйте очень простые (и короткие!) Слова: текст, тело, заголовок.

Я также считаю, что комбинация простых слов легче понять, чем суп из длинных «подходящих» слов: postbody, posthead, userinfo и т. Д.

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

Убери за собой

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

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

Вы можете использовать такой инструмент, как расширение Dust-Me Selectors для Firefox (совет: укажите его на свой sitemap.xml), чтобы помочь вам найти некоторые ненужные вещи, спрятанные в ваших ядерных бомбах css и карни.

Сохранить unsorted.cssфайл

Допустим, вы разрабатываете сайт QA, и у вас уже есть таблица стилей для «страницы ответов», которую мы будем называть answers.css. Если вам теперь нужно добавить много нового CSS, добавьте его в unsorted.cssтаблицу стилей, а затем рефакторинг в вашу answers.cssтаблицу стилей.

Несколько причин для этого:

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

Взгляните на 1. SASS 2. Компас

Лучший способ борьбы с CSSраздутием - это использование объектно-ориентированных принципов CSS.

Есть даже структура OOCSS , которая довольно хороша.

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

Ключевым моментом здесь является идентификация «объектов» или шаблонов строительных блоков на вашем сайте и разработка с их помощью.

Facebook наняла создателя OOCSS, Николь Салливан, чтобы получить большую экономию в своем коде внешнего интерфейса (HTML / CSS). Да , вы действительно можете получить экономию не только в вашем CSS, но в вашем HTML тоже, что по звуку, очень возможно для вас , как вы упоминаете преобразование tableмакета , основанного на много div-х

Еще один замечательный подход в некоторых аспектах аналогичен OOCSS, заключается в том, чтобы с самого начала планировать и писать свой CSS, чтобы он был масштабируемым и модульным. Джонатан Снук (Jonathan Snook ) сделал блестящую книгу и книгу / книгу о SMACSS - масштабируемой и модульной архитектуре для CSS

Позвольте мне связать вас с некоторыми ссылками:
5 ошибок массивного CSS - (видео)
5 ошибок массивного CSS - (слайды)
CSS Bloat - (слайды)

Вы также должны понимать каскад и вес, и как они работают.

Я заметил, что вы используете только идентификаторы классов (div.title). Знаете ли вы, что вы также можете использовать идентификаторы, и что идентификатор имеет больший вес, чем класс?

Например,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

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

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

Думайте об этом как цифры. Число 9 в столбце единиц по-прежнему меньше единицы в столбце десятков. Селектор с идентификатором идентификатора, спецификатором класса и двумя спецификаторами элемента будет иметь больший вес, чем селектор без идентификатора, 500 спецификаторов класса и 1000 спецификаторов элемента. Конечно, это абсурдный пример, но вы поняли идею. Дело в том, что применение этой концепции поможет вам очистить CSS.

Кстати, добавление спецификатора элемента в класс (div.title) не является необходимым, если вы не столкнетесь с конфликтами с другими элементами, которые имеют class = "title". Не добавляйте ненужный вес, потому что вам может понадобиться использовать этот вес позже.

Могу ли я предложить меньше CSS Dynamic Framework

Это похоже на SASS, как упоминалось ранее.

Это помогает поддерживать CSS для родительского класса.

Например

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

Что это делает: Применяет width: 100% к # child1 и # child2.

Кроме того, # child1 специфический CSS принадлежит #parent.

Это сделало бы

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

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

Я склонен упорядочивать свои файлы CSS примерно так:

1. Сброс CSS, основанный на Эрике Мейере . (Потому что в противном случае я обнаружил, что для большинства элементов у меня есть по крайней мере одно или два правила, которые просто сбрасывают стили браузера по умолчанию - большинство моих списков, например, не выглядят как стиль HTML по умолчанию для списков.)

2. Грид-система CSS, если сайт требует этого. (Я основываю свой на 960.gs )

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

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

5. Стили, которые актуальны только на отдельных страницах

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

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

Вы, кажется, находитесь на правильном пути с семантикой именования, но это может быть сделано еще дальше. Разделы HTML, которые неоднократно появляются на сайте без структурной модификации (так называемые «модули»), можно рассматривать как корни селектора, и оттуда вы можете настроить внутреннюю компоновку относительно этого корня. Это основной принцип объектно-ориентированного CSS , и вы можете прочитать / посмотреть больше об этом в этом выступлении инженера Yahoo .

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

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

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

Это зависит от вас, чтобы проанализировать конкретные потребности клиента, соответственно сбалансировать эти проблемы.

Как сказал до меня: попасть в OOCSS. Sass / Less / Compass заманчиво использовать, но пока ванильный CSS не будет использоваться правильно, Sass / Less / Compass будет только усугублять ситуацию.

Прежде всего, прочитайте о эффективной CSS. Попробуйте Google Page Speed ​​и прочитайте, что Соудерс написал об эффективном CSS.

Затем введите OOCSS.

• Научитесь работать с каскадом. (В конце концов, мы называем это каскадными таблицами стилей).
• Узнайте, как получить правильную гранулярность (снизу вверх, а не сверху вниз)
• Узнайте, как разделить структуру и оболочку (что является уникальным и каковы вариации этих объектов?)
• Узнайте, как разделить контейнер и контент.
• Учитесь любить сетки.

Это будет революционизировать каждый бит о написании CSS. Я полностью обновлен и люблю это.

ОБНОВЛЕНИЕ: SMACSS похож на OOCSS, но в целом проще для адаптации.

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

Пишите в SASS. Вы были бы безумны, чтобы отказаться от преимуществ переменных, mixins и так далее.

Никогда не используйте HTML ID для стилизации; всегда используйте классы . HTML-идентификаторы, при правильном использовании, появляются только один раз на всей странице, что является полной противоположностью повторного использования - одного из самых основных товаров в разумной инженерии. Более того, действительно трудно переопределить селекторы, содержащие идентификаторы, и зачастую единственный способ перекрыть один идентификатор HTML - это создать другой идентификатор, заставляя идентификаторы распространяться в кодовой базе, как и вредители, которыми они являются. Лучше оставить идентификаторы HTML для неизменных хуков Javascript или интеграционных тестов.

Назовите ваши CSS-классы по их визуальной функции, а не по их специфической для приложения функции. Например, скажите «.highlight-box» вместо «.bundle-product-discount-box». Кодирование таким образом означает, что вы можете повторно использовать существующие таблицы стилей, когда вы разыгрываете сторонние компании. Например, мы начали продавать юридические заметки, но недавно перешли к преподавателям. У наших старых CSS-классов были такие имена, как «.download_document_box», имя класса, которое имеет смысл, когда речь идет о цифровых документах, но может привести к путанице только при применении к новому домену частных репетиторов. Лучшее имя, которое подходит как для существующих служб, так и для любых будущих, будет ".pretty_callout_box".

Избегайте именования классов CSS после конкретной информации сетки. Был (и остается) ужасный анти-паттерн в сообществах CSS, когда дизайнеры и создатели CSS-фреймворков (кашель Twitter Bootstrap ) считают, что «span-2» или «cols-8» - разумные названия для CSS-классов. Смысл CSS заключается в том, чтобы дать вам возможность изменить свой дизайн, не влияя на разметку (сильно). Жесткое кодирование размеров сетки в HTML препятствует достижению этой цели, поэтому его не рекомендуется использовать в любом проекте, который будет длиться дольше выходных. Подробнее о том, как мы позже избегали классов сетки.

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

Минимизировать вложенность. Ввести новые классы вместо вложенных селекторов. Тот факт, что SASS устраняет боль повторяющихся селекторов при вложении, не означает, что вам нужно вложить пять уровней глубиной. Никогда не переусердствуйте в выборе селектора (например, не используйте «ul.nav», где «.nav» может выполнить ту же работу.) И не указывайте элементы HTML рядом с именем пользовательского класса (например, «h2.highlight»). Вместо этого просто используйте имя класса и удалите базовый селектор (например, предыдущий пример должен быть «.highlight»). Сверхквалификационные селекторы не добавляют никакой ценности.

Создавайте стили для элементов HTML (например, «h1») только при стилизации базовых компонентов, которые должны быть согласованы во всем приложении. Избегайте широких селекторов, таких как "заголовок ul", потому что, скорее всего, вам в любом случае придется их переопределить. Как мы постоянно говорим, большую часть времени вы хотите использовать определенный, хорошо названный класс, когда вам нужен определенный стиль.

Охватите основы Block-Element-Modifier. Вы можете прочитать об этом, например, здесь. Мы использовали его довольно легко, но все же это очень помогло нам в организации стилей CSS.

Много раз я видел, как люди разбивают файл на разделы с заголовком комментария между разделами.

Что-то вроде

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

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

Вы должны посмотреть на БЭМ .

теория

BEM - это попытка предоставить набор инструкций для организации и присвоения имен селекторам css в попытке сделать вещи более пригодными для повторного использования и модульными и избежать столкновений между селекторами такого рода, которые часто приводят к спагетти-коду и головным болям специфичности.

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

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

BEM хорошо работает с SASS, чтобы привнести в CSS почти объектно-ориентированный стиль. Вы можете создавать модульные файлы, которые обрабатывают отображение одного элемента пользовательского интерфейса и содержат переменные, такие как цвета и «методы», например, как обрабатываются внутренние элементы. Хотя хардкорный ОО-программист может отказаться от этой идеи, на самом деле, применяемые концепции привносят множество более приятных частей ОО-структур, таких как модульность, слабая связь и тесная связь, а также возможность повторного использования без контекста. Вы даже можете создать способ, который выглядит как инкапсулированный объект, используя Sass и &оператор .

Более подробную статью из Smashing Magazine можно найти здесь ; и один из Гарри Робертса из CCS Wizardry (который должен прочитать любой, кто связан с css) находится здесь .

На практике

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

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

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

И я также несколько полагаюсь на каскад и специфику. Здесь модуль БЭМ будет .primary-boxи .headerбудет контекстом для конкретной перегрузки

.header {
  .primary-box {
    color: #000;
  }
}

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

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

• проекты усложняются, поэтому важно заложить хорошие основы, включая css
• даже проект, который выглядит простым, потому что он построен на WordPress с небольшим JavaScript, все еще может быть очень сложным в CSS - ОК, вам не нужно делать никакого кодирования на стороне сервера, так что эта часть проста, но передняя часть изношена для брошюр имеет двадцать модулей и три варианта каждого: у вас есть очень сложный CSS!

Веб-компоненты

В 2015 году мы начинаем смотреть на веб-компоненты. Я пока не знаю об этом огромном количестве, но они стремятся объединить все функциональные возможности внешнего интерфейса в автономные модули, эффективно пытаясь применить принципы BEM к внешнему интерфейсу в целом и разбросать компоненты, но полностью связанные друг с другом такие элементы, как фрагменты DOM, Js (MVC) и CSS, которые создают один и тот же виджет пользовательского интерфейса.

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

Там какое - то дальнейшее чтение здесь , а также рамочное Polymer здесь что стоит посмотреть

в заключение

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

Я бы порекомендовал вам взглянуть на CSS-фреймворк "Compass Style" .

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

таким образом вы получаете лучшее из обоих миров, повышаете производительность (меньше запросов HTTP запрашивается из браузера) и разделяете проблемы кода при разработке.