Не пишите заголовки в 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
таблицу стилей.
Несколько причин для этого:
- после того, как вы закончите, рефакторинг быстрее, чем поиск правил (которые, вероятно, не существуют) и внедрение кода
- вы будете писать вещи, которые будете удалять, а внедрение кода только усложнит удаление этого кода.
- добавление в исходный файл легко приводит к дублированию правила / селектора
simplicity
,complexity
,maintenance
,structure
иrefactoring
.