Вступ / довідка: компоненти CSS
Для відносно великого веб-сайту ми працюємо з SASS і намагаємося керувати CSS в компонентах. Основна ідея компонентів полягає в тому, що компонент повинен виглядати однаково скрізь, незалежно від елементів контейнера далі в DOM.
Отже, ми хочемо уникати подібних матеріалів (SASS):
// User picture component.
.user-picture {
img {..}
}
// Override user picture for the frontpage.
body.page-front .user-picture img {..}Натомість, якщо ми хочемо, щоб зображення користувача виглядало по-різному на титульній сторінці, це було б іншим компонентом. Наприклад, із спадщиною SASS або з сумішшю:
// User picture component.
.user-picture {
img {..}
}
// User picture on frontpage.
.user-picture-front {
@extend .user-picture;
img {..}
}Тоді нам потрібно відрегулювати html на титульній сторінці, щоб вона використовувала іншу версію зображення користувача.
Все йде нормально. Я виклав вище, як ілюстрацію мого теперішнього розуміння того, що стосується компонентів CSS.
Питання: Класи модифікаторів - хороша практика?
Зараз ми стикаємося з проблемою: деякі сторінки мають темний (чорний) фон, і тому текст, межі та інші елементи повинні бути білими.
Це якимось чином виходить за рамки компонентів: Цей же компонент повинен мати темний текст за замовчуванням, але білий текст, якщо він знаходиться в контейнері з темним фоном.
Отже, у нас є ця дивовижна ідея:
// Generic modifier class for all dark-background containers.
.white-on-black {
// Generic text color change.
color: white !important;
}
// Component.
.my-component {
border: 1px solid blue;
// Special for white-on-black.
.white-on-black & {
border-color: yellow;
}
}Таким чином, у нас є зовнішній клас "модифікатор" або "контекст", white-on-blackякий змінює спосіб відображення внутрішніх елементів.
Мотивація полягає в тому, що сам компонент не відповідає за фон елемента контейнера далі в DOM.
Це працює. Проблема полягає лише в тому випадку, якщо у нас є контейнер з білим тлом в контейнері з темним фоном. Але це вбік, це працює нормально.
Питання полягає в тому, чи є це архітектурно гарною практикою, на тлі намагання зберегти компоненти незалежними один від одного.
Альтернативою було б мати інший компонент, наприклад my-component-on-dark-bg, який успадковує my-componentі має різний колір тексту та меж. Але тут (наприклад, PHP) код, який виробляє компонент html, повинен знати про зовнішню сторону, тобто про те, чи використовується темний bg. Якщо припустити, що код PHP, який надає компонент, є окремим від коду PHP, який надає контейнер. Що все ще керується, але може бути аргументом для шаблону з класом модифікаторів, як описано вище.
Примітки
Ми фактично префіксуємо наші класи CSS за допомогою префікса, характерного для проекту. Я просто покинув це тут для простоти, і тому над яким чиїм ділом я працюю :).