Не пишіть заголовки в CSS
Просто розділіть розділи на файли. Будь-які коментарі CSS, повинні бути саме такими, коментарі.
reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css
Використовуйте сценарій для об'єднання їх в одне ціле; якщо необхідно. Ви навіть можете мати гарну структуру каталогів і просто вимагати, щоб ваш скрипт рекурсивно сканував .cssфайли.
Якщо ви повинні написати заголовки, майте TOC на початку файлу
Заголовки в TOC повинні бути абсолютно рівними заголовкам, які ви пишете пізніше. Боліти пошуки рубрик. Щоб додати проблему, як саме хто припускає знати, що ви маєте ще один заголовок після першого заголовка? пс. не додайте док-подібний * (зірочку) на початку кожного рядка під час написання TOC-кодів, це просто робить більш прикрою вибір тексту.
/* 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;
}
Уникайте використання TAG в якості селекторів, коли ви можете використовувати id / класи
По-перше, теги 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;
}
Тому що додаткові звисаючі DIV там нічого не додають селектору. Вони також змушують зайве тег-правило. Якби ви змінили, наприклад, .answerз "a" 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-скидання / скидання, всі ваші загальні чари повинні стосуватися принаймні одного кореневого компонента
Вони не економить ваш час, вони змушують голову вибухнути; а також зробити технічне обслуговування кошмаром. Коли ви пишете правило, ви можете знати, де вони застосовуються, однак це не має гарантії, що ваше правило згодом не буде з вами.
Додавання до цього загальних правил є заплутаним і важко читається, навіть якщо ви маєте уявлення про документ, який ви стилюєте. Це не означає, що ви не повинні писати загальних правил, просто не використовуйте їх, якщо ви дійсно не маєте намір зробити їх загальними, і навіть вони додають стільки інформації обсягу в селектор, скільки можете.
Такі речі ...
.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), щоб допомогти вам знайти частину сміття, прихованого у ваших ядрах css та кані.
Зберігайте unsorted.cssфайл
Скажімо, ви створюєте сайт із забезпечення якості, і у вас вже є таблиця стилів для "сторінки відповідей", яку ми зателефонуємо answers.css. Якщо вам зараз потрібно додати багато нового CSS, додайте його до unsorted.cssтаблиці стилів, а потім рефактор у вашу answers.cssтаблицю стилів.
Для цього є кілька причин:
- швидше зробити рефактор після того, як ви закінчите, тоді це пошук правил (яких, мабуть, не існує) та введення коду
- ви будете писати речі, які ви видалите, введення коду просто ускладнить видалення цього коду
- додавання до вихідного файлу легко призводить до дублювання правил / селектора
simplicity,complexity,maintenance,structureіrefactoring.