Уровень развития CSS: пристальный взгляд на CSS архитектуры

Мы все знаем, что организация, порядок и модульность - это ключ к успеху при работе с CSS, и поэтому CSS архитектуры становятся все более популярными.

Я хотел попробовать их все, чтобы проверить плюсы и минусы, и это то, с чем я пришел.

OOCSS от Nicole Sullivan означает Объектно Ориентированный CSS и направлен на поощрение повторного использования кода путем отделения структуры от внешней части и контейнеров от контента. Это делает стили модульными, масштабируемыми и более простыми в обслуживании.

OOCSS можно рассматривать как пионера и родителя всех других систем CSS.Он больше определил новый способ подхода к таблицам стилей чем четкую систему правил и организаций.

Все, что было представлено позже, было на самом деле эволюцией OOCSS, и я думаю, что с момента выпуска OOCSS был сделан ряд шагов вперед. В настоящее время мы можем просто считать само собой разумеющимся, что объектно-ориентированный метод не является более предпочтительным вариантом, он больше необходим для мышления при работе с большими проектами, но этого недостаточно. Итак, давайте двигаться вперед!

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

SMACSS предлагает пять типов категорий (Base, Layout, Modules, States and Theme), которые требуют от нас задавать себе некоторые вопросы в процессе разработки, думая о фактической роли, которую каждый элемент играет в системе. Это также подразумевает признание шаблонов разработки, поощрение повторного использования и поддержки кода.

Я все еще придерживаюсь всех принципов разделения между категориями Base, Layout и Modules. То, к чему я действительно начал относиться по-разному, были прежде всего media queries.

ITCSS от Harry Roberts означает «Перевернутый треугольник CSS», а его ключевым принципом является разделение CSS-кода на несколько уровней, основанных на уровне специфичности. Определенные уровни отображаются как перевернутый треугольник: «Settings», «Tools», «Generic», «Elements», «Objects», «Components», «Trumps».

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

Мне также нравится практика использования префиксов для каждого имени основного класса (o - для объектов, c - для компонентов и u - для утилит). Это дает разработчику четкое представление о том, для чего используется каждый класс и где именно он находится внутри исходного кода.

Теперь я привык располагать классы на основе их уровня специфичности, но я предпочитаю упростить структуру каталогов в меньшем количестве слоев, учитывая, что Settings, Tools и Generic являются абстрактными уровнями, а Elements, Object и Components - это все модули.

ACSS от Thierry Koblenz означает Atomic CSS и также известен как функциональй CSS. Его основная концепция заключается в создании высокоуровневого и многоразового CSS, используя систему селекторов с низкой специфичностью. Я предлагаю вам прочитать эту статью Sitepoint, которая правильно объясняет, как это работает: Узнайте о CSS-архитектуре: Atomic CSS

Хотя ACSS может показаться простым способом справиться с классами с низкой специфичностью, я думаю, что это может привести к большим проблемам поддерживаемости. Использование классов, таких как mt10 и pb10, дает вам представление о компоновке компонентов, а не о его реальной роли, так что будет, если компонент изменит свой стиль? Мы, вероятно, должны редактировать как HTML, так и CSS. Я предпочитаю работать над разметкой без стилей и сосредоточиться вместо этого на роли, которую играют компоненты при выборе имен классов CSS.

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

BEM от команды Яндекса, означает Блок-Элемент-Модификатор и его основная концепция заключается в определении основных автономных объектов (блоков, то есть хедер, футер, меню), их внутренние части (элементы, то есть название заголовка, пункт меню) и их состояния (модификаторы , например чекнутый чекбокс).

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

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

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

Присоединяйтесь к нашим каналам FrontEndDev и Web Stack в Telegram, чтобы не пропустить самое интересное!

Если вы нашли какие-либо недочеты или вопиющие ошибки в коде или переводе - не стесняйтесь оставлять комментарии. Это заставляет нас более тщательно с потом у лба проверять наши переводы. Спасибо.

Оригинал статьи - State of the art in CSS: a closer look at CSS architecture systems