Управление взрывом CSS

Ответ 1

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

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

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

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

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

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

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

• Постройте разумные классы. Ниже приведены несколько замечаний по этому вопросу.

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

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

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

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

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

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

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

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

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

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>, все они имеют одинаковый размер шрифта, а элементы находятся рядом друг с другом (в отличие от рендеринга по умолчанию 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 имеет проблемы с несколькими классами., поэтому в этом примере используется id s.

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 мог работать с несколькими классами; Я еще не пробовал, но выглядит очень многообещающе, от Дина Эдвардса. До тех пор вам нужно будет установить наиболее важный для вас класс (номер позиции, активный или первый/последний) или использовать идентификаторы. (booo IE6!)

Ответ 2

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

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

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

EDIT (2014/02/05) четыре года спустя, я бы сказал:

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

Ответ 3

Не записывайте заголовки в CSS

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

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

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

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

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

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

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

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

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

Компоненты должны иметь position:relative, no padding и no 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;
}

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

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

Это...

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;
}

Поскольку дополнительные висячие DIVs ничего не добавляют к селектору. Они также вызывают ненужное правило тегов. Если вы должны были изменить, например, .answer от div до 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- reset/unreset, вся ваша общая магия должна применяться к хотя бы одному корневому компоненту

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

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

Вещи вроде этого...

.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, которые вы не используете. Убедитесь, что все хорошо, и у вас нет противоречивых или дублированных правил.

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

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

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

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

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

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

Ответ 4

Взгляните на 1. SASS 2. Compass

Ответ 5

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

Там даже OOCSS фреймворк там очень хорош.

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

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

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

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

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

Ответ 6

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

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

Например,

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

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

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

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

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

Ответ 7

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

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

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

например.

 #parent{     
  width: 100%;

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

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

Что это значит: Применяет ширину: 100% для обоих # child1 и # child2.

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

Это приведет к

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

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

Ответ 8

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

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

• CSS reset, на основе Eric Meyers. (Потому что в противном случае я обнаружил, что для большинства элементов у Ive есть хотя бы одно или два правила, которые просто восстанавливают стили браузера по умолчанию - большинство моих списков, например, не похожи на стиль HTML по умолчанию для списков.)

• Сетка системы CSS, если сайт требует ее. (I base mine на 960.gs)

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

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

• Стили, относящиеся только к отдельным страницам

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

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

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

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

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

ОБНОВЛЕНИЕ: SMACSS похож на OOCSS, но легче адаптироваться вообще.

Ответ 11

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

Что-то вроде

/* Headings and General Text */

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

/* Main page layout */

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

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

Ответ 12

Основные принципы разумного CSS, извлеченные из Рефакторинг CSS: от append-only до модульного CSS

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

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

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

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

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

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

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

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

Ответ 13

Вы должны посмотреть BEM.

Теория

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

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

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

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

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

На практике

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

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

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

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

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

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

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

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

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

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

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

Там еще некоторое чтение здесь, а также фреймворк Полимер здесь, который стоит посмотреть

Наконец

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

Ответ 14

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

Ответ 15

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

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