Как и для любых других стандартов кодирования целью формирования стандартов кодирования CSS в WordPress является создание основы для сотрудничества и контроля в рамках различных аспектов проекта и сообщества WordPress, от основного кода до тем и плагинов. Файлы в проекте должны выглядеть так, как будто созданы одним разработчиком. Прежде всего, создавайте код, который будет читаемым, существенным, последовательным и красивым.
Внутри основной таблицы стилей часто будут обнаруживаться несоответствия. Мы работаем над решением этих проблем и прилагаем максимум усилий, чтобы патчи с этого момента соответствовали стандартам кодирования CSS. Подробная информация по данной теме и о вкладе в UI/front-end разработку будет изложена в виде отдельного набора инструкций.
Есть много различных методов для структурирования таблиц стилей. Что касается CSS в ядре, важно сохранять высокую степень читабельности. Это позволяет последующим вкладчикам иметь четкое понимание документа.
Правильно:
#selector-1,
#selector-2,
#selector-3 {
background: #fff;
color: #000;
}
Неправильно:
#selector-1, #selector-2, #selector-3 {
background: #fff;
color: #000;
}
#selector-1 { background: #fff; color: #000; }
Со специфичностью связано больше ответственности. Общие селекторы позволяют нам быть эффективными, но могут иметь отрицательные последствия, если не выполнено тщательное тестирование. Более специфичные селекторы могут сохранить нам время, но быстро приведут к сумбуру в таблице стилей. Опыт - лучший помощник для нахождения правильного баланса между общими стилями и шаблоном DOM.
Правильно:
#comment-form {
margin: 1em 0;
}
input[type="text"] {
line-height: 1.1;
}
Неправильно:
#commentForm { /* Избегайте CamelCase-нотации. */
margin: 0;
}
#comment_form { /* Избегайте знаков подчеркивания. */
margin: 0;
}
div#comment_form { /* Избегайте излишней детализации. */
margin: 0;
}
#c1-xr { /* Что значит c1-xr?! Используйте осмысленное имя. */
margin: 0;
}
input[type=text] { /* Должно быть [type="text"] */
line-height: 110% /* Вдвойне неправильно */
}
Также как и в случае с селекторами, слишком детализированные свойства ухудшают гибкость дизайна. Меньше означает больше. Убедитесь, что вы не повторяете стили и не вводите фиксированные размеры (когда резиновое решение является более приемлемым).
“Группируйте понравившиеся свойства вместе, особенно если у вас их много.” - Nacin
Прежде всего, выберите то, что имеет смысл для вас и является в некотором роде семантическим. Случайный порядок - это хаос, а не поэзия. Для ядра WordPress наш выбор - логическое или групповое упорядочивание, при котором свойства сгруппированы по смыслу и упорядочены определенным образом в рамках этих групп. Свойства в пределах группы упорядочиваются так, чтобы создать переходы между секциями, например фон непосредственно перед цветом шрифта. Основная схема упорядочивания:
Вещи, которые пока не используются в ядре, такие как CSS3-анимации, могут не иметь предписанного места, но скорее всего вписались бы в приведенную выше схему каким-то логическим способом. Просто поскольку CSS развивается, наши стандарты будут меняться вместе с ним.
Top/Right/Bottom/Left (TRBL/trouble) - порядок для любых соответствующих свойств (например, margin). Свойства углов (например, border-radius-*-*) должны идти в порядке: top-left, top-right, bottom-right, bottom-left. Эти правила следуют из того, как указываются универсальные свойства.
Пример:
#overlay {
position: absolute;
z-index: 1;
padding: 10px;
background: #fff;
color: #777;
}
Другой метод, который часто используется, в том числе и группой Automattic/WordPress.com Themes, состоит в упорядочивании свойств по алфавиту, с некоторыми исключениями или без них.
Пример:
#overlay {
background: #fff;
color: #777;
padding: 10px;
position: absolute;
z-index: 1;
}
Мы используем grunt-autoprefixer в качестве инструмента предварительной обработки, чтобы легко управлять необходимыми для браузеров префиксами, таким образом делая большую часть этой спорной работы. Для тех, кому интересно, каким должен быть выход без использования Grunt, префиксы разработчиков должны идти от длинных (-webkit-) к коротким (без префикса). Остальные правила упорядочивания стандартны.
.sample-output {
-webkit-box-shadow: inset 0 0 1px 1px #eee;
-moz-box-shadow: inset 0 0 1px 1px #eee;
box-shadow: inset 0 0 1px 1px #eee;
}
Есть множество способов ввода значений свойств. Следуйте инструкциям ниже, чтобы помочь нам сохранить высокую степень согласованности.
Правильно:
.class { /* Правильное использование кавычек */
background-image: url(images/bg.png);
font-family: "Helvetica Neue", sans-serif;
}
.class { /* Правильное использование нулевых значений */
font-family: Georgia, serif;
text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.5),
0 1px 0 #fff;
}
Неправильно:
.class { /* Избегайте пропускать конечную точку с запятой */
background:#fff
}
.class { /* Избегайте добавлять единицу измерения к нулевым значениям */
margin: 0px 0px 20px 0px;
}
Использование команды @media позволяет изящно подстраивать дерево DOM для различных размеров экрана. При добавлении команды @media обязательно проверьте результат выше и ниже пограничного размера, который вы используете.
Пример:
@media all and (max-width: 699px) and (min-width: 520px) {
/* Your selectors */
}
Заголовки разделов и подразделов:
/**
* #.# Заголовок раздела
*
* Описание раздела, имеет ли он команды media и т.д.
*/
.selector {
float: left;
}
Inline-комментарии:
/* Комментарий, описывающий селектор */
.another-selector {
position: absolute;
top: 0 !important; /* Объяснение, почему используется !important */
}
Таблицы стилей, как правило, получаются длинные. Фокус медленно теряется, в то время как цели начинают повторяться и перекрываться. Написание умного кода с самого начала помогает сохранить общую канву и не потерять гибкость при изменениях.