Что такое модульный CSS?

• Оригинальный адрес:What is Modular CSS?
• Оригинальный автор:Scott Vandehey
• Перевод с:Программа перевода самородков
• Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
• Переводчик:ssshooter
• Корректор:Hopsken Park-ma

Модульные CSS - это набор принципов для записи кода, который является исполнительным и ремонтом. Он возник из разработчиков в Yahoo и Yandex, чтобы удовлетворить проблемы поддержания больших кодовых базов. Некоторые из правил были немного противоречивыми сначала, но позже были рассмотрены наилучшей практикой.

содержание:

1. Трудности в обработке крупномасштабных CSS
2. что такое модульный
3. модульная структура
   1. OOCSS
   2. BEM
   3. SMACSS
4. Принцип общей модульности
5. FAQ
6. В заключение, модульный CSS прекрасен.

(Подлость для вас: если вы чувствуете себя ошеломленным объемом этой статьи,смотреть видеоВозможно, вам больше подойдет эта статья, основанная на этом выступлении. )

Трудности в обработке крупномасштабных CSS

Основной вариант использования модульного CSS — сложный крупномасштабный CSS. в видеNicholas Gallagher сказал:

источник:Nicholas Gallagher,рисунок:dotCSS

Эта цитата затрагивает суть серьезной проблемы CSS. Писать код не сложно, самое сложное — не допустить, чтобы ваш код стал «техническим долгом», который со временем тянет вас вниз.

непостижимый

Ниже приведеныCSS GuidelinesПример в , который показывает проблему: никто не знает, что делает этот код, кроме того, кто его написал.

<div class="box profile pro-user">
  <img class="avatar image" />
  <p class="bio">...</p>
</div>

boxиprofileкаковы отношения?profileиavatarкаковы отношения? Или они действительно родственники? ты должен бытьbioдобавить рядом сpro-user?imageиprofileНаписано в том же разделе CSS? можно использовать в другом местеavatar?

Вы не можете ответить на эти вопросы, просто взглянув на код, вы должны рассуждать об их роли в коде CSS.

сложно повторно использовать

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

Теперь у вас есть две проблемы: одна копия исходного кода, одна копия дублированного кода, и ваша нагрузка на обслуживание удваивается.

сложно поддерживать

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

Это напоминает мне одну из моих любимых шуток о CSS:

что такое модульный

Так как же нам решить эти проблемы? Ответ заключается вмодульныйКонцепция, но что это? давайте сначала посмотримHarry Robertsправильноразделение интересовСтатистика:

источник:Harry Roberts,рисунок:CSSwizardry.com

Это обычная практика программирования, но с ней не знакомы многие разработчики CSS. Идея состоит в том, чтобы убедиться, что вы не пишете больше, чем хотите.

Как пример того, как я работал до того, как изучил модульный CSS. Дизайнер дал мне этот эскиз:

рисунок:Yandex

Я бы сказал: «Хорошо, вот страница книжного магазина с некоторыми виджетами на боковой панели, список справа от того, что, вероятно, является обложками книг, избранные обзоры книг и другие обзоры ниже».

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

рисунок:Yandex

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

На странице вы найдете логотип, панель поиска, навигацию, список фотографий, дополнительную навигацию, вкладку, видеоплеер и многое другое. Это вещи, которые можно использовать самостоятельно в любом месте участка. Они просто так совмещены на этой конкретной странице.

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

рисунок:BEM Method

Вам это напоминает Лего? Должен быть! Почти каждый, кто пишет о модульном CSS, использует аналогию с Lego. Хорошей идеей является создание пользовательских интерфейсов с использованием стандартизированных, простых для понимания и независимых от контекста блоков.

Один из самых известных примеров таких «блоков» изготовленNicole SullivanОпределенный как «медиа-объект», она считает этот тип объекта одним из самых маленьких компонентов, которые вы найдете на любом веб-сайте.

Он сочетает изображение фиксированной ширины со стороной контейнера гибкой ширины, шаблон, который вы сейчас видите повсюду. Она написала статью под названиемThe Media Object Saves Hundreds of Lines of CodeОдним из самых ярких примеров применения этого шаблона к большому веб-сайту является Facebook:

рисунок:Nicole Sullivan

Здесь выделяются все медиа-объекты в потоке Facebook. Личная информация вверху слева, элементы навигации справа, каждый пост, на который вы подписаны, и даже реклама — это медиа-объекты. Иногда они вложены друг в друга. Хотя они используются для разных целей, все они имеют один и тот же базовый шаблон: изображения фиксированной ширины, текст эластичной ширины.

Она говорит о том, что при работе в масштабе Facebook существует более нескольких десятков медиаобъектов, сотни тысяч таких страниц. Поэтому вполне возможно, что если вы оптимизируете стиль повторного использования, вы сможете сэкономить много кода, что может привести к действительно высокой производительности и низкой стоимости.

модульная структура

Ну, так как мы дали понятьмодульныйконцепции, то давайте посмотрим на три основных фреймворка, которые продвигали эту концепцию на протяжении многих лет:

OOCSS

Объектно-ориентированный CSS (объектно-ориентированный CSS)/OOCSSявляется источником модульного CSS, созданногоNicole SullivanПредставлено в 2009 году на основе ее работы в Yahoo. Основная идея этого фреймворка заключается в том, что объектмногоразовые шаблоны, чей внешний вид не определяется контекстом.

• Некоторые люди сомневались в способностях Yahoo, команда разработчиков Yahoo, разработанная в то время.YUI libraryЭто очень передовая технология. В 2009 году Yahoo не была технологической компанией без будущего.

источник:Nicole Sullivan,рисунок:John Morrison

Таково происхождение модульного CSS, как она определила его в 2009 году. Помимо этого, OOCSS сводится к нескольким основным принципам:

без контекста

Во-первых, независимо от того, где вы его поместите, объект долженвыглядит неотличимо, объект не должен стилизоваться в зависимости от его контекста.

Например, вместо того, чтобы делать все кнопки на боковой панели оранжевыми, а все кнопки в основной области — синими, вы должны создать класс синих кнопок и оранжевый модификатор. Таким образом, оранжевые кнопки доступны везде, они не привязаны к боковой панели, это просто один из ваших стилей кнопок.

кожа (тема)

Еще одна концепция, о которой она говорила, заключалась в том, каккожа применяетсяАбстрагированныйструктура объекта.

Мы можем вернуться к примеру с медиа-объектом. Его стиль не зависит от структуры метки. Есть контейнер, изображение фиксированной ширины и контент. Вы можете применять разные стили, но структура метки остается неизменной независимо от того, как меняются стили.

Другой подход, который она предлагает, заключается в создании повторно используемых классов для общих визуальных паттернов. Она привела пример, когда почти все на Amazon в 2009 году имело оттенки, но поскольку они были созданы разными дизайнерами, они были похожи, но не одинаковы. Стандартизировав эти тени элементов, вы можете оптимизировать свой код и сделать свой веб-сайт более эффективным.

использовать класс

В то время она предложила очень спорное правило, которое с тех пор стало общепринятым: использовать класс для именования объектов и их дочерних элементов, что позволяет изменять теги HTML, не затрагивая стиль.

Она не хочет, чтобы CSS определялся тегами HTML, поэтому, если она изменит заголовок с «h1» на «h4», ей не нужно будет обновлять CSS. Независимо от того, какой тег выбран, заголовок должен иметь неотъемлемый класс. Например, ваша навигация должна выглядеть так.site-nav вместо #header ul.

Не использовать идентификатор

Поскольку рекомендуется «всегда использовать класс», селекторы ID, естественно, запрещены. Это шло вразрез с общепринятой практикой использования идентификаторов в качестве пространств имен в то время, напрямую ссылаясь на элементы, вложенные в них.

Идентификаторы мешают расстановке приоритетов CSS, и, во-вторых, объекты должны быть повторно используемыми. По определению идентификаторы уникальны. Таким образом, если вы установите идентификатор для объекта, вы не сможете повторно использовать его на той же странице, упустив смысл модуляризации объектов.

BEM

Далее идет следующий фреймворк, воспевающий дух модульного CSS.BEM, три буквы обозначают Блок, Элемент и Модификатор соответственно. БЭМ также был предложен в 2009 году и создан Яндексом (можно сказать, что это русская версия Google).Помимо поискового бизнеса, он также управляет программой веб-почты. , так что им тоже надо решать задачи по программированию.Головоломка такого же размера как Yahoo.

Они предлагают очень похожий набор принципов кодирования. Их основные понятия:блокировать(Николь называет это «объектом») по сабвуферуэлементсоставляют и могутмодифицированный(или «тематика»).

Вот один из разработчиков, отвечающий за БЭМVarya StepanovaОписание БЭМ:

источник:Varya Stepanova,рисунок:ScotlandJS

БЭМ состоит из 3 частей:

Блокировать

Блоки являются независимыми компонентами логики и функциональности веб-страницы. Спонсоры БЭМ выдвинули более подробное его определение:

Во-первых, блоквкладываемый. Они должны иметь возможность быть включены в другой блок без нарушения каких-либо стилей. Например, на боковой панели может быть блок, обозначающий виджеты интерфейса, и этот блок может содержать кнопки, которые также являются своего рода отдельным блоком. Стиль кнопки и стиль элемента с вкладками не влияют друг на друга, один вложен в другой и все.

Во-вторых, блокПовторяемый. Интерфейс должен иметь возможность содержать несколько экземпляров одного и того же блока. Как Николь сказала о медиа-объектах, мультиплексирование блоков может сэкономить много кода.

Элемент

Элемент является частью блока, его нельзя использовать вне блока. Хороший пример: навигационное меню, содержащее элементы, не имеющие значения вне контекста меню. Вы не определяете блоки для пунктов меню, само меню должно быть определено как блок, а пункты меню являются его дочерними элементами.

Модификатор

Модификаторы определяют внешний вид и поведение блока. Например, внешний вид блока меню может быть вертикальным или горизонтальным, в зависимости от используемого модификатора.

соглашение об именовании

Еще одна вещь, которую делает БЭМ, — это определение очень строгих соглашений об именах:

.block-name__element--modifier

Это выглядит немного сложно, поэтому позвольте мне разбить его:

• Имена пишутся строчными буквами
• Слова в именах пишутся через дефис (-) разделенный
• Элементы представлены двойным подчеркиванием (__) разделенный
• Модификатор состоит из двойного дефиса (--) разделенный

Это тоже немного абстрактно, вот пример:

Теперь у нас есть стандартная минифигурка LEGO. Он синий астронавт. мы будем использовать.minifigкласс, чтобы отличить его.

можно увидеть.minifigБлоки состоят из более мелких элементов, таких как.minifig__headи.minifig__legs. Теперь добавляем модификатор:

добавлением.minifig--redмы создали красную версию стандартного синего астронавта.

В качестве альтернативы мы можем использовать.minifig--yellow-newМодификатор меняет наших космонавтов на новую желтую версию униформы.

Вы можете сделать более преувеличенные модификации таким же образом. используя.minifig--batmanмодификатор, мы меняем внешний вид каждой части минифигурки всего одним классом.

Вот пример синтаксиса БЭМ в действии:

<button class="btn btn--big btn--orange">
  <span class="btn__price">$9.99</span>
  <span class="btn__text">Subscribe</span>
</button>

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

Не вкладывать CSS

Подобно тому, как OOCSS рекомендует использовать классы вместо идентификаторов, БЭМ накладывает некоторые ограничения на стиль кода. В частности, они утверждают, что селекторы CSS не должны быть вложенными. Вложенные селекторы портят приоритет и затрудняют повторное использование кода. Например, просто используйте.btn__price вместо .btn .btn__price.

Примечание. Вложение здесь относится к практике вложения селекторов в Sass или Less, но это применимо, даже если вы не используете препроцессор, поскольку это вопрос приоритета селектора.

Этот принцип хорош из-за строгих соглашений об именах. Раньше мы использовали вложенные селекторы, чтобы изолировать их в контексте пространств имен. Само соглашение об именовании БЭМ предоставляет пространства имен, поэтому нам больше не нужна вложенность. Несмотря на то, что все на корневом уровне CSS является одним классом, имена достаточно специфичны, чтобы избежать конфликтов.

Как правило, селекторы могут работать без вложенности, поэтому не вкладывайте их. Единственным исключением из этого правила, допускаемым БЭМ, являются элементы стиля, основанные на состоянии блока или его модификаторах. Например, вы можете использовать.btn__textзатем используйте.btn--orange .btn__textЧтобы переопределить текстовый цвет кнопки с примененным модификатором.

SMACSS

Последний фреймворк, который мы собираемся обсудить, этоSMACSS, что означает масштабируемую и модульную архитектуру CSS.Jonathan SnookSMACSS был предложен в 2011 году, когда он работал в Yahoo, создавая CSS для Yahoo Mail.

источник:Jonathan Snook,рисунок:Elida Arrizza

Ключевая концепция, которую он добавляет к OOCSS и BEM, заключается в том, чтокатегорияКомпоненты должны обрабатываться по-разному.

Категории

Вот категории, которые он определяет для правил, которые может содержать система CSS:

1. БазаПравила — это стили по умолчанию для элементов HTML, таких как ссылки, абзацы и заголовки.
2. МакетПравила делят страницу на разделы и группируют один или несколько модулей вместе. Они определяют только макет, а не цвет или типографику.
3. Модуль(он же «объект» или «блок») — это многоразовый дизайн-в-модуле. Например, кнопки, медиа-объекты, списки товаров и т. д.
4. СостояниеПравила описывают, как модуль или макет должен выглядеть в определенном состоянии. Обычно применяется или удаляется с помощью JavaScript. Например, скрыть, развернуть, активировать и т. д.
5. ТемаПравила описывают, как выглядит модуль или макет при применении темы, например, в Yahoo Mail может использоваться пользовательская тема, которая влияет на каждый модуль на странице. (Это прекрасно работает для таких приложений, как Yahoo, но большинство сайтов не используют эту категорию.)

префикс соглашения об именах

Следующий принцип — использовать префиксы для различения категорий. Ему нравится явное соглашение об именах БЭМ, но он также хочет иметь возможность сразу увидеть тип модуля.

• l-Используется в качестве префикса для правил компоновки:l-inline
• m-Используется в качестве префикса для правил модуля:m-callout
• is-Используется в качестве префикса для правил состояния:is-collapsed

(Базовые правила не имеют префикса, потому что они применяются непосредственно к элементам HTML без использования классов.)

Принцип общей модульности

Эти фреймворки больше похожи, чем отличаются. Я вижу явную эволюцию от OOCSS к BEM и SMACSS. Их разработка отражает растущий опыт нашей отрасли в производительности и крупномасштабных CSS.

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

модульные элементы

Модульная система состоит из следующих элементов:

• Модуль:(также известный как объект, блок или компонент) Автономный шаблон многократного использования. Например, медиа-объекты, навигация и заголовки.
• Дочерний элемент:Небольшой блок, который не может стоять сам по себе и является частью модуля. Например, изображения в медиаобъектах, навигационные вкладки и логотипы заголовков.
• Модификатор модуля:(также известные как скины или темы), чтобы изменить внешний вид модуля. Медиа-объекты, такие как выравнивание по левому/правому краю, вертикальная/горизонтальная навигация.

Модульная категория

Стили в модульной системе можно разделить на следующие категории:

• БазаПравила — это стили по умолчанию для HTML-элементов, например:a,liиh1
• МакетПравила управляют расположением модулей, но не их внешним видом, например:.l-centered,.l-gridи.l-fixed-top
• МодулиВизуальные стили — это многократно используемые независимые компоненты пользовательского интерфейса, такие как:.m-profile,.m-cardи.m-modal
• СостояниеПравила добавляются с помощью JavaScript, например:.is-hidden,.is-collapsedи.is-active
• Помощник(также известные как функции) правила имеют небольшой объем и не зависят от модулей, например:.h-uppercase,.h-nowrapи.h-muted

модульные правила

При написании стилей в модульной системе придерживайтесь следующих правил:

• не использовать идентификатор
• Не вкладывать более одного уровня CSS
• Добавить имя класса в дочерний элемент
• следовать соглашениям об именах
• Префикс имени класса

FAQ

Разве в HTML не было бы много классов, делающих это?

Наиболее распространенное возражение против модульного CSS заключается в том, что он создает множество классов в HTML. Я думаю, это потому, что в течение долгого времени передовая практика CSS считала, что следует избегать интенсивного использования классов. Николь Салливан написала отличный пост в блоге еще в 2011 году.Our (CSS) Best Practices are Killing Us, что явно опровергает эту идею.

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

Имена классов БЭМ длинные и некрасивые!

Не пугайтесь длинных имен классов, они самодокументируются! Я в восторге, когда вижу имена классов в стиле БЭМ (или любое другое модульное соглашение об именах), потому что с первого взгляда могу сказать, что означают эти классы. Вы можете ясно понять их в HTML.

Каково соглашение об именах внучатых элементов?

Короче говоря: нет такого.

Новички в модульном CSS могут быстро понять концепцию дочерних элементов:minifig__armдаminifigчасть. Однако иногда, когда они имеют дело со структурой DOM в CSS, у них возникают вопросы о том, как сделать глубокую вложенность, напримерminifig__arm__hand.

В этом нет необходимости. Помните, идея состоит в том, чтобы отделить стили от разметки. несмотря ни на чтоhandдаminifig, не имеет значения, сколько уровней вложено. CSS заботится только оhandдаminifigдети.

.minifig {}
  .minifig__arm {}
      .minifig__arm__hand {} /* don't do this */
  .minifig__hand {} /* do this instead */

А конфликты модулей?

Еще одна проблема для новичков в модульном CSS — конфликты между модулями. Например, если я поставлюl-cardмодули иm-author-profileМодули, примененные к одному и тому же элементу одновременно, вызовут ли это проблемы?

Ответ таков: в идеале модули не должны слишком сильно перекрываться. В этом примереl-cardМодули сосредоточены на макете, в то время какm-author-profileМодули сосредоточены на стилях, как вы могли видеть.l-cardустановить ширину и поля, аm-author-profileУстановите цвет фона и шрифт.

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

Если вы обнаружите, что вам нужно применить два модуля к одному и тому же элементу, и они конфликтуют, подумайте, действительно ли это два отдельных модуля. Может их можно объединить в модуль с модификатором?

Последним исключением из этого правила является то, что классы «помощник» или «утилита» могут конфликтовать, в этих случаях вы можете безопасно рассмотреть возможность использования!important. Я знаю, что тебе сказали!importantПлохая вещь, и ее никогда не следует использовать, но в нашем подходе есть нюанс: все же приятно использовать его упреждающе, чтобы гарантировать, что вспомогательные классы всегда имеют приоритет. (Harry Roberts has more to say on this topic in the CSS Guidelines. )

В заключение, модульный CSS прекрасен.

Кратко повторим, помните этот код?

<div class="box profile pro-user">
  <img class="avatar image" />
  <p class="bio">...</p>
</div>

boxиprofileкаковы отношения?profileиavatarкаковы отношения? Или между ними есть связь? ты должен бытьbioдобавить рядом сpro-user?imageиprofileНаписано в том же разделе CSS? можно использовать в другом местеavatar?

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

<div class="l-box m-profile m-profile--is-pro-user">
  <img class="m-avatar m-profile__image" />
  <p class="m-profile__bio">...</p>
</div>

Мы можем видеть, какие классы связаны друг с другом, какие не связаны друг с другом и как. Мы знаем, какие классы мы не можем использовать за рамками этого компонента, и, конечно же, мы знаем, какие классы мы можем повторно использовать в другом месте.

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

Или, другими словами,Модульный CSS предсказуем, прост в сопровождении и эффективен.

Теперь мы можем вернуться к этой старой шутке, концовка изменилась:

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

---

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.