CSS методологии. CSS БЭМ, SMACSS, ECSS

Содержание материала:

CSS методологии. CSS БЭМ, SMACSS, ECSS

На сегодняшний момент почти не осталось организаций, которые не имеют веб-сайт. Основной задачей первых веб-сайтов раньше было отображение информации и обеспечение легкости ориентирования в ней [1]. Однако сейчас это уже далеко не так. Для некоторых организаций сайт является визиткой, на которой описана полезная информация, которая должна отражать деятельность данной организации. Для других организаций сайт нужен не только как визитка, но и как место для сбыта товаров. А для того, чтобы организация смогла пробиться сквозь сотни конкурентов и заинтересовать пользователей содержанием своего сайта, нужен дизайн, который выделяет эту организацию среди других. Дизайн сайта, в большей степени, создается с помощью CSS – формального языка описания внешнего вида документа, написанного с использованием языка разметки [3]. Разработчик Бен Фрейн однажды заметил: «Писать CSS-код легко. Масшабировать и поддерживать его — нет» [2]. Поэтому для упрощения организации кода используются различные методологии.

Одной из таких методологий является БЭМ. Данная методология была разработана в Yandex. На данный момент БЭМ является одной из самых популярных методологий во всём мире. Основная идея БЭМ заключается в том, что типовые проекты должны разрабатываться быстро, но жить долго.

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

Пример кода, написанный с использованием методологии БЭМ, представлен на рисунке 1.

Рис. 1. Код проекта с использованием методологии БЭМ

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

Результат работы с использованием методологии БЭМ показан на рисунке 2.

Рис. 2. Результат работы с использованием методологии БЭМ

Таким образом, БЭМ является достаточно удобной методологией для использования в больших проектах, однако, если использовать её для небольших проектов, то БЭМ сделает код только сложнее. Примером использования БЭМ в больших проектах является, к примеру, Яндекс.Маркет.

Другой методологией является OOCSS. OOCSS означает объектно-ориентированный CSS [6]. Основная идея OOCSS заключается в многократном использовании написанного кода. В эту методологию заложены две основные идеи:

¾ разделение структуры и оформления;

¾ разделение контейнера и содержимого [4].

Пример кода, написанный с использованием методологии OOCSS:

  • нет определенных правил;
  • низкий порог вхождения.
  • появляется слишком много классов.

Можно сделать вывод, что методология OOCSS, в сравнении с БЭМ, является более удобной, если использовать её в небольших проектах. Однако для больших проектов она непригодна. Примером использования OOCSS в небольших сайтах является «дневник» разработчика по имени Nicolas Gallagher.

Ещё одной методологией является MCSS. MCSS – это Multilayer CSS (многослойный CSS). Основная идея заключается в распределение стилей по уровням. Многослойная система организации CSS основана на принципах OOCSS и БЭМ [5]. MCSS использует:

  • фундамент – корневые малоизменяемые стили, располагаемые в самом начале;
  • базовый слой – стили многократно используемых на сайте элементов (кнопки, поля для ввода текста);
  • проектный слой – отдельные модули, а также модификации элементов в зависимости от браузера клиента, устройства;
  • косметический слой – простые, маловлияющие стили, созданные по принципу OOCSS.
  • хорошо изолированные модули;
  • строго определенная логика.
  • немного непривычное расположение классов;
  • сложная логика распределения по слоям и правил взаимодействия между слоями.

Таким образом, MCSS является довольно сложной методологией, которая подойдет под любой проект. Данная методология использовалась для создания социальной сети «Одноклассники»

Другая методология называется SMACSS. SMACSS – это способ изучить ваш процесс проектирования, а также способ приспособить эти жесткие рамки под гибкий мыслительный процесс. Это попытка документирования последовательного подхода к разработке сайта с использованием CSS [3]. Основной идеей является разделение стилей на 5 составляющих. Базовые категории SMACSS:

  • Base – в эту категорию входят правила, которые определяют внешний вид элементов по умолчанию. Одиночные селекторы элементов, селекторы атрибутов, селекторы псевдоклассов, смежные селекторы и т.д. Например, html, body, a, a:hover и т.д.
  • Layout – категория для стилей, с помощью которых страница разделяется на секции.
  • Module – стили модулей — блоков, которые могут использоваться несколько раз на одной странице
  • State – к этой категории относятся стили внешнего вида макета или модулей в определенном состоянии (например, видимый, скрытый, раскрытый или закрытый) или в определенном виде (например, домашняя страница или внутренняя страница).
  • Theme – категория похожа на State, в нее входят стили, отвечающие за внешний вид макетов и модулей. Эта категория нужна не во всех проектах, но знать про нее необходимо.
  • подход предлагает правильные рекомендации для модульного и поддерживаемого CSS-кода, избегая при этом излишних предписаний;
  • SMACSS быстро выучить;
  • система именования SMACSS менее подробна и в чем-то проще БЭМ;
  • система достаточно гибкая, чтобы работать с крупными и маленькими проектами [3].
  • нужно чётко соблюдать правила;
  • поначалу непривычно использовать.

Таким образом, можно сделать вывод о том, что SMACSS также, как и MCSS, является подходящей методологией как для малых проектов, так и для больших. Однако, следует отметить, что поначалу её довольно непривычно использовать из-за четкого распределения стилей.

Итак, подводя итоги, можно констатировать следующее: среди проанализированных методологий нет идеальных. Каждая из представленных имеет свои достоинства и недостатки. БЭМ лучше всего использовать для крупных проектов, а методологию OOCSS для малых проектов. Методологии MCSS и SMACSS являются универсальными и их можно использовать, как в крупных, так и в небольших проектах.

CSS методологии. CSS БЭМ, SMACSS, ECSS

Многослойная система организации CSS основана на принципах OOCSS и БЭМ. Методология родилась и развивается в команде разработчиков OK.ru и рекомендуется к использованию как основа для собственного свода правил и документаций.

Несмотря на то, что MCSS изначально был создан для организации большого количества стилей, данная методология рекомендуется и веб сайтам среднего размера.

Документация постоянно обновляется и развивается, в том числе и в сопровождении вспомогательных инструментов, таких как движок документирования верстки Source.

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

Всегда будем рады ответить на ваши вопросы в разделе Issues на Github или в комментариях на страницах сайта проекта.

Быстрая навигация

Основные правила

Методология MCSS максимально абстрагирована и не акцентирует внимание на конкретном стиле написания кода, организации файлов и обязательных инструментах для работы с ней. Модули документации самостоятельны и подходят для использования вне основных правил методологии.

Блоки вёрстки делятся на модули, каждый из которых сам по себе независим и максимально абстрагирован от фиксированных размеров.

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

Нулевой слой, или фундамент

Фундамент включает в себя ресеты и мало изменяемые стили, которые закладываются в основу вёрстки и применяются на все страницы.

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

Компоновка модулей

Порядок подключения стилей

Что бы сохранить вес и приоритетность каждого слоя, стили разных слоев подключаются в определенном порядке:

Первый слой — базовый

Первый слой — это портальный фреймворк, ядро интерфейса, которое состоит из наиболее переиспользуемых и абстрактных конструкций, например:

  • формы
  • кнопки
  • блоки навигации и пр.
  • и другие

Разметка модулей первого слоя тесно завязана на общем стиле портала (веб сайта) и на дизайнерских гайдлайнах. Так как модули первого слоя являются часто реиспользуемыми они должны легко вписыватся в большинство интерфейсов вашего проекта без больших изменений.

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

Как часть первого слоя можно смело использовать такие популярные фреймворки, как Bootstrap, 960gs, inuit.css и пр.

Правила

Основное правило первого слоя — абстрактность как в названиях, так и в разметке:

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

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

Ядро (1-й слой) должно быть абстрагировано от модулей 2ого слоя, пример:

Взаимодействия стандарта форм со стандартом кнопок — модифицирование каскадом от 1-го слоя:

Взаимодействие проектного модуля со стандартом во 2-м слое:

Модификация 2-го слоя, от 1-го запрещена! В такой ситуации слои смешиваются, вызывая беспорядок:

Базовые стили подключаются сразу после фундамента, перед 2-м слоем, для поддержания низкого уровня приоритета по весу селекторов.

Преимущества

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

Имея разработанную базу, легко на её основе создавать новые интерфейсы, большая часть которых состоит из стандартных элементов.

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

Второй слой — проектный

Второй слой включает в себя изолированные, проектные модули, из которых в дальнейшем собирается страница:

  • форма регистрации
  • блок логина
  • корзина товаров
  • и другие

Правила

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

Каждый модуль должен быть максимально изолирован и существовать как отдельная, независимая единица интерфейса, которая общается только с базовым слоем.

Чтобы в проектном модуле использовать конструкцию из первого слоя, нужно просто добавить рядом CSS-класс:

В примере описан модуль второго слоя .toolbar, который использует стандарт первого слоя .umenu. Чтобы модифицированиевать стандарт под проектные нужды, используется каскад в CSS:

Стили второго слоя могут быть модифицированы каскадом только от других модулей этого слоя.

Можно:

Преимущества

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

Стили каждого модуля можно подключать по отдельности только на те страницы, где они необходимы.

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

Третий слой — косметический

Третий слой состоит из простых, мало влияющих стилей:

  • цвета ссылок
  • Простые OOCSS селекторы — пара свойств на класс (.font-size_XL, .margin-t_L)
  • глобальные модификаторы

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

Правила

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

Позволяется использовать простые OOCSS-классы, не больше трёх на блок, для редких, не проектных ситуаций:

Стили косметического слоя нельзя модифицировать каскадом от других слоёв, кроме контекста.

Косметические стили подключаются в самом конце, так же допускается использование !important.

Преимущества

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

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

Контекст

Слой включает в себя стили высшего контекста и @media-правила, которые могут использоваться для изменения стандартных стилей под особенности различного контекста:

  • .ie8, .ie9 — браузеры
  • .touch — особенности устройства
  • .logged-in — высший контекст в рамках веб сайта
  • Media queries

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

Примеры использования

Посмотреть взаимодействие слоёв на практике можно на этой странице. В примере, все слои поделены на секции в одном CSS файле, таким же образом можно делить содержание секций на отдельные файлы:

Во втором примере, изображено взаимодействие MCSS с Bootstrap, в качестве первого (базового) слоя.

Сайт проекта тоже сверстан по методологии MCSS, не стесняйтесь заглянуть в исходники.

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

Рекомендации

Code style

Вместе с методологией советуем использовать следующие полезные практики для улучшения своего кода:

Введение в CCSS (Компонентный CSS)

CCSS или компонентный CSS , это архитектура, которая упрощает составление CSS для крупных веб-приложений.

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

С появлением такого большого количества фреймворков, руководств, инструментов и методологий ( OOCSS, SMACSS, BEM и т.д.), разработчики нуждаются в CSS архитектуре, которая обеспечит простое сопровождение, управление и масштабирование проектов.

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

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

Давайте рассмотрим, что такое CCSS и как вы можете использовать его в настройке архитектуры CSS для сложного веб-приложения.

Элементы CCSS

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

SMACSS

SMACSS, был создан Джонатаном Снуком , и расшифровывается, как Scalable and Modular Architecture for CSS ( Масштабируемая и модулируемая архитектура для CSS ). Это, скорее, руководство по стилям, чем фреймворк. Для получения более детальной информации о том, как он используется в структуре CCSS , прочитайте статью SMACSS .

BEM был создан разработчиками Yandex , расшифровывается, как “ Block ”, “ Element ”, “ Modifier ” (« Блок «, « Элемент «, « Модификатор «). Эта методология предлагает новый подход при разработке веб-интерфейсов. Более подробную информацию по BEM вы можете найти в отличной статье Гарри Робертса .

Sass — это CSS с суперсилами. Я очень рекомендую именно его, но вы можете использовать также Less . Дополнительную информацию вы можете найти в документации Sass .

Compass

Compass не содержит определения классов; это расширение для Sass , предоставляющее много дополнительных утилит. Оно используется для создания примесей и компиляций Sass .

Примеси Compass практически всегда должны использоваться, когда нам нужны префиксы. Опять же, его применение весьма желательно, или по своему усмотрению вы можете использовать Bourbon .

Принципы CCSS

Теперь давайте рассмотрим основные принципы CCSS .

Компонентная основа

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

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

Модульность и изолированность

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

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

Возможность компоновки

При составлении CSS должно уменьшаться количество времени, необходимое для написания CSS , и соответственно нужно больше времени на изменение HTML-классов элементов, модифицируя их или добавляя новые стили.

Для всех разработчиков гораздо проще составлять CSS -код, похожий на блоки конструктора « Лего », чем участвовать в CSS войне. Классы CSS являются строительными блоками, которые используются для составления стилей.

Предсказуемость

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

Документирование

Большинство людей считают, что CSS не требует пояснений. На самом деле это, как правило, не так! Компоненты CSS должны быть четко задокументированы, с тем, чтобы в описаниях было подробно разъяснено, что они делают и как они должны использоваться.

Структура каталогов

Ниже для облегчения восприятия приводится пример структуры папок. Я также разместил пример настройки CCSS в хранилище на GitHub :

Нужно только отредактировать / составить файлы в папке scss/ дерева папок , приведенного выше. Это позволяет легко обновлять внешние библиотеки, расположенные в папке ext/ .

Топ-пост этого месяца:  Установка Joomla в деталях и картинках, решение возможных проблем

Многие приложения поддерживаются внешними CSS -фреймворками, такими как Bootstrap или Foundation , поэтому я добавил их в этом примере в папку ext/ . Хотя конечно здорово, если все CSS -коды пишутся с нуля; тем не менее, вы можете использовать описанный выше метод.

Папка components/ отлично подходит для применения AngularJS , но ее можно настроить под другие фреймворки или приложения. Более подробно я расскажу об этом в разделе « Архитектура ».

На странице HTML , включающей в себя все файлы .css из папки style/ , содержатся все скомпилированные CSS-коды ( из Grunt, Compass и т.д .). Никогда не изменяйте их.

Конвенция имен — упрощенный BEM

  • u-className — глобальные базовые классы / классы утилит;
  • img-className — глобальные классы изображений;
  • animate-className — глобальные классы анимации;
  • ComponentName — стандартные компоненты (B);
  • ComponentName-elementName — элементы компонента (E);
  • ComponentName—modifierName — модификатор компонента (М).

Обратите внимание на название стиля компонентов UpperCamelCase , это основной элемент; это означает, что он является верхним элементом компонента. Имена элементов и модификаторов — elementName и modifierName , соответственно. Не используйте дефис (-), чтобы разделять имена компонентов, так как он означает начало элемента / имени элементов.

Архитектура и дизайн

Давайте рассмотрим архитектуру, построенную согласно принципам CCSS .

Grunt

Grunt является отличным элементом для запуска задач, который автоматизирует многие рутинные действия ( например, компиляцию CSS или проверку HTML ).

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

Организация файлов

Посмотрите еще раз на структуру папок, которая является производной от SMACSS . Обратите внимание на папку ext/ , которая содержит все внешние фреймворки ( такие как Bootstrap ). Для более простого внесения изменений изменения и расширения должны вноситься не в нее, а в папку base/ .

base/ — это место, где хранятся глобальные базовые стили, используемые приложением в целом.
_base.scss — базовые стили только для селекторов элементов. Они являются своего рода « CSS-переключателями «.
_base-classes.scss — все классы утилит, используемые по всему приложению в разных представлениях, компонентах и на страницах. Используется префикс имени класса u- .
images.scss используется в качестве источника компиляции SCSS . Должен определять и встраивать все изображения сайта, как Data URI . /app/styles/images.css генерируется из этого файла.
_animate.scss содержит все классы анимации всего приложения.
_bootstrap-overrides.scss содержит только файлы, измененные фреймворком. Иногда уровень, назначенный селекторам фреймворка, настолько высок, что их переопределение требует дополнительных селекторов. Изменение на глобальном уровне не может быть осуществлено в контексте компонента SCSS . Вместо этого все глобальные изменения собираются здесь.

Компоненты

Любой блок многоразово используемого CSS -кода, не упомянутого выше, считается « компонентом «. Мы используем AngularJS , поэтому я разделяю их на три основные категории: представления / страницы, директивы и стандарты; следовательно, структура этих папок опирается на SMACSS .

В примере настроек, размещенном на GitHub , я, чтобы было понятнее, создал отдельные папки.

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

Это дало мне огромный плюс, так как стимулировало остальных членов команды следовать синтаксису BEM . Это также позволило избежать путаницы при отходе от использования типичного стиля BEM с его символами -, — и __, которые генерируют такие имена классов, как module-name__child-name—modifier-name !

Также важно, что порядок определения классов CSS в компоненте отражает представление HTML . Это облегчает сканирование, назначение стилей, редактирование и применение классов.

Наконец, хорошо иметь для веб-приложения обширное руководство по стилям и следовать гайдлайнам по CSS и Sass ( например, избавиться от необходимости использования @extend ).

Пример CCSS

Смотрите код примера настроек CSS .

Вот пример компонента на Sass :

Это код компилируется в следующий CSS :

И ваш HTML -код может выглядеть приблизительно следующим образом:

Вы можете задействовать упрощенную BEM-примесь , которая для достижения этой цели использует эталонный селектор, и является более простой, чем @at-root .

В Sass 3.3+ работать с BEM стало намного проще, что дает нам возможность поддерживать и сопровождать код, который легко понять.

Ваше участие

Ваше участие в развитии материалов, размещенных на GitHub , в виде просьб добавить больше примеров, разъяснений и т.д., будет очень полезным.

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

Данная публикация представляет собой перевод статьи « Introducing CCSS (Component CSS) » , подготовленной дружной командой проекта Интернет-технологии.ру

БЭМ-методология организации CSS-кода

Писать CSS-код легко. Масшабировать и поддерживать его — нет

Это правда. И это неоднократно подтверждалось во многих проектах. Будь то конструктор сайтов с настраиваемыми темами (проект Getsocio — 28 тысяч строк CSS) кода или сайт-визитка со сравнительно небольшим количеством стилей. Любые сколь-нибудь сложные правки в связи с изменениями дизайна или с появлением новых страниц приводят к долгому рефакторингу, в самом запущенном случае — к дублированию стилей. При этом постоянно присутствует риск что-нибудь сломать в самом неожиданном месте.

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

Почему так происходит? На начальном этапе, когда разработчики получают макеты, они создают структурy ассетов, в которую довольно хорошо вписывается весь существующий дизайн. Проблема рождается именно в этот момент, потому что текущий дизайн — это вершина айсберга по сравнению с будущим дизайном. Можно представить варианты решений, приходящих в голову на данном этапе. У нас всего две страницы — можно поместить все стили в один файл. Или еще. У нас десять страниц и все они непохожи, поэтому не стоит заморачиваться выделением компонент внутри страниц и вынесением их в отдельные файлы, проще создать по файлу стилей на каждую страницу. Идеи выглядят вполне здравыми, учитывая текущие аспекты дизайна. Опытные разработчики даже могут сделать некоторые предположения о том, как поменяется дизайн в ближайшем будущем, но немногие готовы к тому, во что превратится проект через, скажем, пять лет.

CSS имеет ряд недостатков, которые приводят к вышеперечисленным проблемам. В недавнем докладе (React: CSS in JS), породившем множество дискуссий в среде фронтенд разработчиков, один из сотрудников Facebook озвучил проблемы с масштабированием CSS. Среди них использование глобального пространства имен, удаление мертвого кода, изоляция и т. д. В итоге он предложил хранить стили в JavaScript. Интересное, но довольно радикальное решение, не всегда применимое к обычным сайтам, страницы которых рендерятся на сервере. Многие компании, не только Facebook, пытаются решить проблему масштабирования CSS. Поэтому на сегодняшний день существует множество подходов к написанию стилей. Одна из наиболее интересных методологий родилась в Yandex.

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

Пройдемся немного по понятиям. Блок — независимый компонент страницы, который инкапсулирует внутри себя поведение (JavaScript) и внешний вид (CSS). Благодаря независимости блока возможно его повторное использование в любом месте страницы. Элемент — составная часть блока, которая не может использоваться в отрыве от него. Модификатор — сущность, изменяющая внешний вид блока или элемента в зависимости от состояния или требований дизайна. При желании можно использовать несколько блоков на одном HTML элементе. Такой способ в терминологии БЭМ имеет название Микс.

Теперь можно вернуться к нашим проблемам и посмотреть какое решение нам предлагает БЭМ. Первая проблема — это глобальное пространство имен. Пусть у нас есть навигационное меню.

Если вдруг на странице появится другой компонент, содержащий элемент списка ( item ), или некий элемент связанный с редактирванием ( edit ), то новые стили повлияют на уже существующие.

В этом примере проблема решается выделением двух компонент. toolbar и user-profile — имена этих компонент в глобальном пространстве имен. Дальше мы определяем стили внутренних элементов в пределах этих компонент.

Но такое решение очень плохо масштабируется. Если представить себе более сложные компоненты ( page , company-preview , user-post ), то мы получим ту же самую проблему, но уже в пределах одного компонента. Уточнение селекторов, например .page > .edit — очень плохая идея, так как создает связанность между HTML шаблонами и представлением. Меняя шаблон, нам нужно будет поменять и стили тоже. Вдобавок ко всему добавляя класс к селектору мы меняем его специфичность, а это в свою очередь усложняет переопределение CSS правил для элемента. В других местах появляются классы для увеличения специфичности, начинается гонка селекторов и головная боль для верстальщика.

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

Вложенные элементы, принадлежащие блоку, будут использовать это имя блока toolbar в качестве префикса. __ служит разделителем между блоком и элементом, а _ — разделителем между БЭМ-сущностью (в данном случае элементом) и модификатором. Здесь toolbar__item_edit и toolbar__item_edit — это модификаторы элемента toolbar__item .

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

Осталось поговорить о самодисциплине. Чтобы не свести на нет полученные приимущества нужно следовать некоторым правилам и рекоммендациям. Можно держать в голове следующий чеклист.

  • Позиционирование блока задается родителем
  • Для описания сущностей используются классы, но не id
  • Нельзя создавать элементы элементов ( block__elem1__elem2 )
  • В именах модификаторов и элементов всегда присутствует имя блока
  • Из предыдущего пункта следует, что нельзя создавать глобальные модификаторы
  • Блоки могут не содержать вложенных элементов ( link )
  • Блоки могут заключать в себе все содержимое страницы или крупные ее части ( page , page-section )

Чтобы не утратить возможность переносимости блока между разными частями страницы желательно чтобы позиционирование и размеры блока ( margin , top , left , width ) задавались родителем.

Предположим что наш toolbar находится внутри блока header и должен занимать его правую половину. Решение может выглядеть следующим образом.

CSS код блока toolbar при этом остается неизменным.

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

Разберем еще один пример. Предположим к нам пришел такой дизайн тулбара.

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

Здесь для того чтобы не дублировать общие стили для каждого элемента блока toolbar мы выделяем элемент toolbar__item и используем микс с остальными элементами: toolbar__button , toolbar__spacer и toolbar__text . Некоторые элементы являются вложенными, но при этом внутренняя структура блока все еще остается плоской, то есть не нарушается правило о том, что нельзя создавать элементы элеметов. И еще одно — все элементы, требующие стилизации имеют классы, в том числе и img . Ссылка на реализацию со стилями.

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

CSS методологии. CSS БЭМ, SMACSS, ECSS

I’ve been analyzing my process (and the process of those around me) and figuring out how best to structure code for projects on a larger scale. What I’ve found is a process that works equally well for sites small and large.

Learn how to structure your CSS to allow for flexibility and maintainability as your project and your team grows.

What is it?

SMACSS (pronounced “smacks”) is more style guide than rigid framework. There is no library within here for you to download or install. There is no git repository for you to clone. SMACSS is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process. It is an attempt to document a consistent approach to site development when using CSS. And really, who isn’t building a site with CSS these days?!

Get to know Scalable and Modular Architecture for CSS:

Read it Online

SMACSS started out as a free online book and that continues to be true. You can always read the book online.

Download the Book

The e-book comes in PDF, ePub, and mobi formats for easy installation on almost any e-reader. Download the zip!

Методология БЭМ в примерах

Приветствую Вас дорогой коллега! Сегодня я хочу рассказать про такую технологию в веб-разработке, как БЭМ. А если точнее то, как называть классы объектам документа при верстке. Помню, когда я начинал и не знал про всякие методики типа БЭМ’а мне сложно было придумывать классы, я постоянно путался, у меня постоянно было пересечение классов, что в итоге сильно тормозило работу.

БЭМ (Блок, Элемент, Модификатор) — это не только простое именование классов, это компонентный подход к работе. Компонентный подход — это когда мы делим разрабатываемый интерфейс на отдельные блоки. При надобности данный блок можем использовать в другой части сайта или приложения без дублирования стилей. Сейчас конечно же мало, что понятно, но мы будем разбирать примеры.

Основу БЭМ методологии составляют 3 составляющие:

Их еще называют БЭМ сущности. Ниже мы разберем каждую сущность по отдельности.

Сразу хочу отметить, что по БЭМ’у написана отличная документация на русском языке, усваивается очень легко и просто. Я лично данную документацию перечитывал несколько раз. В первое время я испытывал сложности, а именно когда создавать блок, когда элемент, а модификаторы и вовсе не использовал или использовал не по методике. Теперь наконец-то встало все на свои места.

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

Блоком в БЭМ называют функционально независимый компонент, который может быть повторно использован на любой странице сайта и в любой части документа. Блок именуется только атрибутом class . Название блока (а именно присваемовый класс) должно характеризовать смысл или предназначение блока (что это — «шапка сайта»: header ; «меню»: menu ; «виджет»: widget и т. д.), а не его состояние (какой, состояние — «красный»: red ; «активный»: active и т. п.).

Вот еще пример блока:

А вот это уже будет неправильно:

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

Вложенность блоков

Блоки могут быть вложены один в другой. Например в блоке шапки сайта может быть вложен блок логотипа.

Микс блоков

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

В данном примере мы блоку logo задали дополнительный класс header__logo , тем самым переопределяя блок logo в шапке сайта header (к примеру, в шапке сайта логотип можно уменьшить до определенных размеров, оставляя все остальное как есть).

Элемент

Элемент — это составляющая блока, которая не может быть использована в отрыве от него. Именование элемента выглядит следующим образом: имя-блока__имя-элемента . То есть название элемента отделяется от имени блока двойным нижним подчеркиванием (__). Также, как и для блока название элемента нужно задавать правильно: «что это?» — «пункт»: item, «текст»: text , т. е. характеризует смысл, а не состояние объекта: «красный»: red, «большой»: big . Думаю, здесь все понятно. Теперь давайте рассмотрим небольшой пример.

Как уже было отмечено, элементы не могут быть сами по себе вне блока. То есть в примере ниже будет неправильно.

Элементы могут быть вложены один в другой. Структура DOM-дерева будет примерно следующей:

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

Css

Sass

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

Хочу отметить, что элемент не обязателен для блока. То есть блок может быть и без элементов, а элемент, как вы уже знаете, без блока быть не может.

Когда создавать блок, а когда элемент?

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

Топ-пост этого месяца:  Маркетплейс – что это и как работает, плюсы и минусы

Элемент

Создавайте элемент тогда, когда элемент не может существовать без родительской сущности сам по себе. В примере с формой элемент input не может быть вне блока формы, поэтому обязательно помещаем его в блок .form

Модификатор

Модификатор — это БЭМ сущность, которая определяет вид, состояние или поведение блока или элемента. Например:

  • Внешний вид: «какой размер?», «какая тема?», «какой цвет?». Размер — size_m . Тема — theme_dark . Цвет — color_blue ;
  • Состояние — active , disabled , focused .

Модификатор отделяется от названия блока или элемента одинарным нижним подчеркиванием (_). Структура имени модификатора будет следующим:

  • Для блока: имя-блока_модификатор
  • Для элемента: имя-блока__имя-элемента_модификатор

Некоторые разработчики для отделения имени модификатора используют не одинарное нижнее подчеркивание (_), а двойной дефис (—). Я лично использую нижнее подчеркивание. Вы можете использовать то, что вам удобно, но в официальной документации используется нижнее подчеркивание.

Типы модификаторов

Модификаторы могут подразделять на типы: 1. ключ-значение; 2. булево значение.

Ключ-значение

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

  • Для блока: имя-блока_модификатор_значение
  • Для элемента: имя-блока__имя-элемента_модификатор_значение

Значение модификатора от имени отделяется (как и само имя модификатора) одинарным нижним подчеркиванием (_).

Пример

Булевый

Данный модификатор используют только тогда, когда требуется само наличие модификатора, а не его значение. Например, «активно»: active .

Пример

Считается, что при наличии булевого модификатора его значение равняется true .

Что еще предлагает технология БЭМ?

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

Файловая структура проекта

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

  • одному блоку соответствует одна директория;
  • имя блока и имя директории совпадают, например, блок header — директория header/ или блок меню — директория menu/ ;
  • имена директорий элементов начинаются с двойного нижнего подчеркивания (__), например, header/__logo/ или header/__form ;
  • имена директорий модификаторов начинаются с одинарного нижнего подчеркивания (_), например, header/__form_bg ;
  • реализация элементов и модификаторов происходит в отдельных файлах и называются примерно так: form__input.js , form_bg_blue.sass .

Пример

Для примера возьмем блок с формой, структура папок и файлов будет следующая:

Лично мне такой подход к разработке очень нравится. В дальнейшем хочу перейти именно на подобную структуру файлов. Естественно все файлы css и js на выходе будут объединены в общие файлы. Делается это с помощью сборщиков, например таких, как Webpack, Gulp, GruntJs и др.

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

На этом пожалуй и завершу. Задавайте вопросы в комментариях, если таковы имеются. Чем смогу — помогу. Всем пока и до встречи в других моих постах!

Заур Магомедов

Верстальщик с большим опытом работы. Занимаюсь созданием сайтов с 2009 года. Постоянно обучаюсь и совершенствую свои навыки. Веду свои проекты, в том числе и данный блог.

CSS методологии. CSS БЭМ, SMACSS, ECSS

We recommend upgrading to the latest Google Chrome or Firefox.

Join GitHub today

GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.

bem-css-methodology-complete-guide / rus.md

#b_ BEM CSS методология: Полное руководство

Главное: классы b-someblock__someelement__element__element-modificator — это не BEM! Как правильно верстать по BEM — читайте ниже.

  1. Длинное необязательное вступление
  2. Суть #b_
  • Зачем это всё?
  • Блок
  • Элемент
  • Модификатор
  • Префикс b- и его воображаемые друзья: l-,i-,g- и еретический js-
  • Как менять внешний вид блока: правила модификации
  1. Три главных правила
  2. Три главных ошибки, про которые нигде не написано
  3. Типичные вопросы, ответов на которые вы не нашли на bem.info
  4. Альтернативы или же братья: SMASS, OOCSS, MCSS и BEM.
  5. Семантика в BEM.
  6. BEM и CSS-препроцессоры: Sass и LESS.
  7. Путь Яндекса: кому и зачем нужны bem-tools и прочие «ужасы»
  8. bem-bl и bem-bl в сниппетах от Яндекса (скоро!)
  9. Альтернативные реализации BEM-методологии
  10. Примеры сайтов на BEM
  • Яндекс-сайтов по BEM
  • НЕ-Яндекс-сайтов по BEM
  • Редизайна по BEM
  1. Отзывы: Мнения людей меняется за пару месяцев работы с BEM. Путь к пониманию.
  2. BEM для атеистов — почему это не религия

1. Длинное необязательное вступление

История понимания BEM и зачем он нужен. Можно смело пропустить и читать сразу пункт №2.

— Я не понимал BEM («что за ерунда придуманная программерами, которые не знают CSS»). Нет не программерами. И не ерунда. — Потом я думал что понимал BEM («у меня типа независимые стили: специфичность длиной в ширину экрана»). — Потом не знал как же правильно его применять, особенно в рамках веб-студии.

Теперь понимаю и знаю. И хочу рассказать и доказать вам что BEM — единственный правильный вариант организации вёрстки.

  • Да-да, и для небольших студий, у которых не один большой, а множество средних проектов.
  • И для фрилансера с маленькими сайтами.
  • И для лендингов.
  • И даже когда вы делаете правки в чужом спагетти-коде — вы можете (и должны) примерять BEM!

В BEM прекрасно вписываются SMACSS, OOCSS, MCSS. Большинство не знает что такое BEM, или думает, но знает неправильно. Если вы знаете что такое BEM и считаете что он не для вас (или вообще только Яндексу нужен) — дочитайте до конца. Я расскажу вам о том что BEM — это не «xslt, bem-bl, xml, bem-tools, js», а это методология которая решает проблемы с которыми сталкиваемся мы все. Нужная всем. Незаменимая для компаний, значительно ускоряющая скорость и стоимость разработки, поддержки, развития, передачи проекта другим разработчикам, масштабирования. Это прорыв уровня ООП для CSS.

И более того: BEM — семантичен как ничто другое при правильном применении! Поехали, я расскажу вам о тех идеях и логике, что стоят за BEM, и почему и как вы можете его использовать!

Существует огромное кол-во статей, докладов, презентаций про BEM. Почти все — от Яндекса. Я читал все статьи, все доклады по BEM, ездил на субботники, общался с Харисовым, Ткаченко и разработчиками библиотеки bem-bl. Но чтоб понять всё (а не думать что понял) мне потребовалось 5 лет.

Вообще если бы было меньше бредовых статей типа этой: http://habrahabr.ru/post/203440/ которые пишут те, кто сам ничего не понял, было бы лучше. И ошибок было бы меньше.

2.1 Зачем это всё?

Главная проблема вёрстки: каскад.

Зачем был придуман BEM? Чтоб уйти от каскада.

Почему надо уходить от каскада?

Идея убрать каскад кажется дикой — как, это же каскад. У нас каскадные таблицы стилей! Каскад сверху до низу по всей странице! Мы в детстве 2000-х играли в игру «кто напишет меньше тегов»!

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

Разновидности BEM: НБ, АНБ, Лего, текущий BEM, BEM-CSS у «не Яндекса».

Всё это BEM. Разновидности называются «подмножествами BEM».

Что не является BEM.

  • длинные строки каскада ради высокой специфичности селекторов — это не та независимость и ни разу не BEM.
  • базовые стили и их переопределения ниже от_контекста — как общий стиль вёрстки
  • BEM это не только bemjson, bem-tools и прочее. АНБ — тоже BEM

Главные правила BEM.

Чтобы их осознать, мы с вами должны вспомнить как писать правильно. Вспомнить правила. Я говорю «вспомнить», потому что то о чем мы будем говорить — это ручная верстка по BEM. В правильных терминах bem это называется «CSS подмножество BEM». Потому что bem он не только про CSS.

Нам придётся совершить экскурс в историю и пройти путь развития BEM чтобы сформулировать четкие правила «BEM CSS» из общей методилогии. Чтоб собрать все пришлось читать апокрифы. Нет единого стандарта. Есть множество толкований — диалектов BEM. Евангелие от Вегеда, проповедь на внутренней коференции и статьи других апостолов, простите евангелистов BEM. Сам BEM допускает множество вариантов самой методологии. А уж какой путь выбирать в каждом конкретном случае, при модификации кода например — можно спорить и спорить. Поэтому -тот- старый добрый ручной BEM и правду похож на религию.

Сводим всё из разных источников. Очень подробно. Много примеров.

Главное в BEM — понятие независимого блока.

Независимый блок (НБ или просто блок) это самодостаточный элемент страницы, который при перемещении в другое место на странице или на другую страницу не теряет своей самодостаточности. BEM.Клуб на Я.рушке, Независимый блок

Формальное определение

  1. для описания элемента используется class, но не id
  2. каждый блок имеет префикс
  3. в таблице стилей нет классов вне блоков BEM.Клуб на Я.рушке, История создания BEM (часть первая)

Формальное определение нужно только затем чтоб описать при каких условиях он должен таким стать. Что такое стили вне блоков я опишу ниже.

«Как его таким написать?» Просто писать стили тупо на каждый блок. BEM хорош тем, что позволяет не забивать голову ерундой с каскадом, а сосредоточимся на семантике и логике кода. А с препроцессорами BEM позволяет писать еще и очень чистый и логичный код. Но про это чуть позже.

Как проверить? Просто навести на блок в инспекторе кода. У него не должно быть каскада. Слайд инспектор кода

Не бывает элементов вложенных в элементы!

Я тоже раньше так писал:

Так делать нельзя.

Как надо?

Если вам нужно сделать элемент у элемента, значит вам нужно сделать новый блок!

Не пишите странные имена

У вас будут проблемы при переносе:

  • Модификатор
  • Префикс b- и его воображаемые друзья: l-,g- и еретический js-
  • Как менять внешний вид блока: правила модификации

##8. BEM и CSS-препроцессоры: Sass и LESS. Extend-Only Selectors в Sass == абстрактный блок (i-блок) в #b_

Что такое методология BEM?

Недавно я слышал о методологии BEM.

  • Что такое использование методологии BEM?
  • Как BEM облегчает нашу работу?
  • Хорошо ли использовать BEM?

BEM — это методология именования. Это означает модификатор Block Element, который нацелен на упрощение модульности и упрощение стилей и классов.

Это нелегко объяснить в ответ, но я могу дать вам основную идею.

Итак, если вы думаете о меню, то вся структура элемента/компонента будет:

Блок: Элемент Элемент: Модификатор (ы): горизонтальный, вертикальный

И, следуя стандартным соглашениям BEM, вы должны написать что-то вроде этого в CSS:

Как вы видите из кода, элементы отделены от блока двумя символами подчеркивания, а модификаторы разделены двумя тире.

Теперь, если вы измените модификатор в меню от —horizontal до —vertical , специальные стили модификаторов будут выбраны как для блока, так и для элемента внутри.

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

Также писать это с использованием прекомпилятора, такого как SASS, делает его еще проще (я не буду вдаваться в подробности, но чтобы дать вам идею):

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

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

Здесь используется прецедент, если вы хотите увидеть его в использовании в реальном проекте https://m.alphasights.com/how-we-use-bem-to-modularise-our-css-82a0c39463b0#.2uvxts71f

Надеюсь, это поможет:)

Что такое BEM?

BEM означает Blocks, Elements and Modifiers . Это методология, изначально задуманная российской технологической компанией Yandex. Как и следовало бы, методология BEM — все о компонентности вашего кода HTML и CSS в трех типах компонентов:

Блоки: автономные объекты, которые имеют смысл сами по себе. Примерами являются header , container , menu , checkbox и textbox

Элементы: Часть блоков, которые не имеют отдельного значения и семантически привязаны к их блокам. Примерами являются menu item , list item , checkbox caption и header title

Модификаторы: Флаги на блоке или элементе, используемые для изменения внешнего вида или поведения. Примеры: disabled , highlighted , checked , fixed , size big и color yellow

Цель BEM — оптимизировать читаемость, удобство обслуживания и гибкость вашего CSS-кода. Способ достижения этого — применить следующие правила.

  • Стили блоков никогда не зависят от других элементов на странице
  • Блоки должны иметь простое, короткое имя и избегать символов _ или —
  • При стилизации элементов используйте селектор формата blockname__elementname
  • При модификации стилей используйте селектор формата blockname—modifiername и blockname__elementname—modifiername
  • Элементы или блоки, которые имеют модификаторы, должны наследовать все от блока или элемента, который он модифицирует, кроме свойств, которые должен модифицировать модификатор.

Пример кода

Если вы применяете BEM к вашим элементам формы, ваши селектора CSS должны выглядеть примерно так:

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

Если вы используете BEM?

BEM приобрел немалую тягу среди американских и западноевропейских веб-разработчиков после популяризации влиятельных гуру CSS, таких как Harry Roberts. Это особенно популярно в сочетании с OOCSS и SMACSS (все это действительно вариации на тех же принципах написания модульного CSS). А модульный CSS имеет довольно много преимуществ. Однако модульный CSS может быть довольно многословным, и BEM, в частности, часто считается довольно уродливым.

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

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

Зачем нужен БЭМ

Следуете ли вы БЭМу, и насколько он востребован вне Яндекса? — спрашивает наша ученица Евгения. Следуем, Евгения, и БЭМ вполне применим не только в Яндексе. Давайте разберёмся.

БЭМ расшифровывается как: блок, элемент, модификатор. Это такой набор абстракций, на который можно разбить интерфейс и разрабатывать всё в одних и тех же терминах. Как говорит сайт bem.info, БЭМ предлагает единые правила написания кода, помогает его масштабировать и повторно использовать, а также увеличивает производительность и упрощает командную работу.

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

В основу того, что мы сейчас называем БЭМом, легла идея независимых блоков, которую Виталий Харисов сформулировал и презентовал в 2007 году на первой российской конференции по фронтенду. Это было настолько давно, что тогда даже слова «фронтенд» ещё не было, тогда это называлось клиент-сайд.

Идея была в том, чтобы ограничить возможности CSS для более предсказуемых результатов. Использовать минимум глобальных стилей и каждый отдельный элемент страницы делать блоком со своим уникальным классом и стилями, которые полностью его описывают. Селекторы по элементам и ID, хрупкие связки вложенности — всё это заменялось на простые селекторы по классам. Каждый класс в стилях — это блок. Благодаря этому блоки можно легко менять местами, вкладывать друг в друга и не бояться конфликтов или влияния.

Потом появились абсолютно независимые блоки (АНБ), где у элементов внутри есть свой префикс с именем родителя, а состояния блоков снова дублируют класс, но уже с постфиксом. Подход обрёл черты современного БЭМа, одна из которых — многословность классов.

Эта многословность гарантирует уникальность элементов и модификаторов в рамках одного проекта. За уникальностью имён блоков вы следите сами, но это довольно просто, если каждый блок описан в отдельном файле. Глядя на такой класс в HTML или CSS, можно легко сказать, что это, и к чему оно относится.

Изначально АНБ, а потом и БЭМ, решали задачу важную для вёрстки любых масштабов: предсказуемое поведение и создание надёжного конструктора. Вы же хотите, чтобы ваша вёрстка была предсказуемой? Вот и Яндекс тоже. Ещё это называется «модульность» — о ней хорошо написал Филип Уолтон в «Архитектуре CSS», ссылка на перевод в описании.

Через пару лет в Яндексе окончательно сформулировали нотацию БЭМ. Любой интерфейс предлагалось разделять на блоки. Неотделимые части блоков — элементы. У тех и других есть модификаторы.

Например, блок поиска по сайту. Он может быть в шапке и в подвале — значит это блок. В нём есть обязательные части: поле поиска и кнопка «найти» — это его элементы. Если поле нужно растянуть на всю ширину, но только в шапке, то блоку или элементу, который отвечает за это растягивание, даётся модификатор.

Для полной независимости блоков мало назвать классы правильно или изолировать стили, нужно собрать всё, что к нему относится. В проекте по БЭМу нет общего script.js или папки images со всеми картинками сайта. В одной папке с каждым блоком лежит всё, что нужно для его работы. Это позволяет удобно добавлять, удалять и переносить блоки между проектами. Потом конечно все ресурсы блоков при сборке объединяются в зависимости от задач проекта.

Когда БЭМ вышел за пределы Яндекса, сначала его воспринимали как магию и старались воспроизводить дословно, вплоть до префиксов b- у каждого блока. Такой смешной карго-культ.

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

Топ-пост этого месяца:  Какой посоветуете плагин для резервного копирования сайта

А зачем вообще все эти нотации — я ведь один верстальщик на проекте, помните? Помню. А ещё помню, как сам верстал до БЭМа: в каждом проекте придумывал что-нибудь такое новенькое. А потом открывал код годичной давности и удивлялся — какой идиот это написал?

Возьмём, к примеру, русский язык. Мы же пишем с прописной имена людей, названия и прочее такое? Пишем. Чтобы легко потом считывалось: это Надя или надежда на лучшее? Уж не говоря про знаки препинания и другие полезные договорённости. Вот буква ё, например смягчает… так, о чём мы? Да, БЭМ.

До БЭМа были проекты с портянками стилей, которые нельзя трогать. Они копились годами, слой за слоем, как обои в древней коммуналке. Их просто подключали первыми, а потом перезаписывали что мешало. Когда у вас есть div < font-size: 80% >— это даже уже не смешно.

БЭМ продолжил развиваться в Яндексе и вырос за пределы вёрстки: появились уровни переопределения, богатый инструментарий, JS-библиотека для работы с БЭМ-классами, шаблонизаторы и целый БЭМ-стэк. БЭМу даже жест придумали, но это совсем другая история, специфичная для Яндекса.

Были и другие методологии: OOCSS Николь Салливан, SMACSS Джонатана Снука, вариации БЭМа и целые фреймворки. Даже у нас на продвинутом интенсиве HTML Академии можно было выбрать любую методологию для вёрстки учебного проекта.

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

Модульность и изоляцию стилей блока можно решить ещё лучше. Есть веб-компоненты, CSS-модули, куча решений CSS-в-JS и даже, прости господи, атомарный CSS. Но нет единого решения накопившихся проблем на следующие 10 лет, каким когда-то стал БЭМ. Что это будет? Посмотрим. Я ставлю на веб-компоненты.

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

Производительность и организация

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

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

Кроме того, эти несколько небольших шагов по улучшению производительности сайта могут окупиться в виде дивидендов. Производительность сайта напоминает правило 80/20, где 20% оптимизации ускорит примерно 80% сайта.

Стратегия и структура

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

Архитектура стиля

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

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

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

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

Стратегия организации стилей это не совсем новый путь и она уже упоминалась в разных методологиях CSS, включая объектно-ориентированный CSS (OOCSS) и SMACSS. Эти методологии имеют своё собственное мнение о структуре, а также о том, как использовать стили.

Объектно-ориентированный CSS

Методология объектно-ориентированного CSS впервые была описана Николь Салливан в её работе по написанию стилей для больших сайтов. Объектно-ориентированный CSS определяет два принципа, которые помогут создавать масштабируемые веб-сайты со строгой архитектурой и рациональным количеством кода. Эти два принципа включают в себя:

  • разделение структуры и оформления;
  • разделение содержимого и контейнера.

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

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

SMACSS

Похожей стратегии придерживается SMACSS (Scalable and Modular Architecture for CSS, масштабируемая и модульная архитектура для CSS), методология, разработанная Джонатаном Снуком. Масштабируемая и модульная архитектура для CSS способствует разбиению стилей на пять основных категорий, в том числе:

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

В приведённом выше примере класс alert попадает в категорию модуль, в то время как класс is-error попадает в категорию состояние. Стили от каждой из этих категорий затем наследуются по необходимости.

Выбор методологии

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

Производительность селекторов

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

Сохраняйте селекторы короткими

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

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

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

Вообще, цель коротких селекторов — уменьшить специфичность, создать чистый, более отзывчивый код.

Предпочитайте классы

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

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

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

Стоит также отметить — держитесь по возможности подальше от идентификаторов, поскольку они чрезмерно специфичны и не допускают любых повторений. В конце концов применение идентификатора не сильно отличается от использования !important .

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

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

Повторно используемый код не должен работать за счёт семантики. Одним из методов может быть соединение селекторов вместе, разделяя их запятой и позволяя одинаковым стилям наследоваться сразу двум селекторам. Другой подход, который часто встречается в ранее упомянутых методологиях OOCSS и SMACSS, включает в себя привязывание стилей к одному классу, а затем использование нескольких классов в одном элементе.

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

Минимизация и сжатие файлов

Простое удаление дублирующего и ненужного кода является лучшим способом для сокращения размера файла, однако существуют и дополнительные пути. Один из способов включает минимизацию и сжатие файлов, таких как HTML, CSS и JavaScript. Кроме того, могут быть сжаты изображения, путём удаления ненужных комментариев и цветовых профилей.

Сжатие gzip

Один из наиболее популярных видов сжатия файлов называется gzip. Сжатие gzip берёт типовые файлы, включая HTML, CSS, JavaScript и др. и определяет похожие строки для их сжатия. Чем больше найдено совпадений строк, тем сильнее файл может быть сжат, таким образом пересылая уменьшенный файл от сервера к браузеру.

Настройка gzip довольно безболезненная и HTML5 Boilerplate проделал большую работу для этого. Для файлов gzip требуется добавить файл .htaccess в корневую папку веб-сервера, помечая конкретные файлы, которые будут сжаты. Точка в начале имени файла правильная, так как файл .htaccess является скрытым.

В HTML5 Boilerplate часть файла .htaccess предназначается для сжатия gzip. Копирование части .htaccess или его целиком на ваш собственный сервер поможет настроить сжатие gzip. Кроме того, стоит отметить, что файлы .htaccess работают только на веб-серверах Apache, которые должны включать следующие модули.

  • mod_setenvif.c
  • mod_headers.c
  • mod_deflate.c
  • mod_filter.c
  • mod_expires.c
  • mod_rewrite.c

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

Измерение сжатия

В браузере Google Chrome веб-инспектор выдаёт изобилие данных связанных с производительностью, особенно во вкладке Network. Кроме того, есть несколько сайтов, которые помогают определить, что сжатие gzip включено.

Рис. 1.01. Вкладка Network идентифицирует каждый загруженный в браузере файл и выводит размер файла и время его загрузки. Обратите внимание, что применение gzip снизило размеры файлов примерно на 60%.

Рис. 1.02. Глядя на файл, конкретно определяют, какой тип сжатия поддерживает браузер. В нашем случае gzip, deflate и sdch помечены как поддерживаемые в заголовке запроса. Глядя на заголовки ответа определяют, что файл был отправлен с помощью метода сжатия gzip.

Сжатие изображений

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

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

Есть несколько инструментов, которые помогают сжимать изображения, двумя лучшими являются ImageOptim для Mac и PNGGauntlet для Windows. Оба они предлагают сжимать наиболее популярные форматы изображений, в частности, файлы JPG и PNG.

Демонстрация сжатия изображения

Несжатое, 455 Кб

Рис. 1.03. С помощью ImageOptim это изображение было уменьшено более, чем на 14% без снижения или потери качества.

Следует также отметить, что установка размеров изображения в HTML путём добавления атрибутов width и height действительно помогает отобразить страницу быстрее, оставляя соответствующее пространство для изображения. Поймите, эти атрибуты должны быть использованы только для идентификации точных размеров изображения, а не для его сокращения. Использование большого изображения, а затем его уменьшение с помощью атрибутов height и width является плохой практикой, так как это загружает больше данных, чем необходимо.

Уменьшение HTTP-запросов

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

Объединение файлов

Одним из способов и, возможно, простейшим путём уменьшения числа запросов является объединение файлов. В частности, объединить все CSS-файлы в один и все JavaScript-файлы в один. Комбинация этих файлов и их сжатие создаёт один, надеюсь небольшой, HTTP-запрос.

В общем, CSS для веб-страницы должен быть загружен в начале документа в , в то время как JavaScript для веб-страницы должен быть загружен в конце, непосредственно перед закрывающим тегом . Причина этих уникальных размещений происходит потому, что CSS может быть загружен, пока остальная часть сайта также загружается. JavaScript, с другой стороны, может рендерить только один файл за раз, тем самым запрещая загружать что-то ещё. С одним нюансом — когда JavaScript-файлы асинхронно загружаются после самой страницы, то происходит рендеринг. Другой нюанс, когда помощь JavaScript требуется для отображения страницы, как в случае с HTML5 shiv.

Спрайты

Практика спрайтов в CSS включает использование одного фонового изображения для нескольких элементов. Цель состоит в том, чтобы сократить число HTTP-запросов, сделанных с использованием нескольких фоновых изображений.

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

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

Рис. 1.04. Вот спрайт для меню текстового редактора; рамки приведены для справки, как будет изменена позиция фонового изображения.

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

Демонстрация спрайтов

Картинки через data:URL

Дополнительно, вместо спрайтов закодированные данные изображения могут быть включены в HTML и CSS напрямую через data:URL, вообще устраняя необходимость в HTTP-запросе. data:URL прекрасно работает для маленьких изображений, которые никогда не меняются и там, где HTML и CSS в значительной степени кэшируются. Есть, однако, несколько проблем. Картинки может быть сложно менять и поддерживать, что приводит к необходимости генерировать другие данные. И они не работают в старых браузерах, в частности, Internet Explorer 7 и ниже.

Если использование data:URL помогает сократить несколько HTTP-запросов и HTML или CSS могут быть в значительной степени кэшироваться, то преимущества, как правило, перевешивают риск. Несколько инструментов помогут генерировать data:URL, включая конвертеры и генераторы узоров. Будьте осторожны и всегда дважды проверьте, что data:URL меньше, чем само изображение.

Демонстрация data:URL

Кэширование общих файлов

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

Подобно файлам gzip, настройка заголовков для истечения кэширования файлов может быть установлена через файл .htaccess. И снова HTML5 Boilerplate находится на один шаг впереди нас. В их файле .htaccess есть раздел, помеченный как Expires headers.

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

Изменение «access plus 1 year» на значение «access plus 1 week» лучше подходит для CSS и JavaScript-файлов, которые меняются еженедельно, но не контролем версий с отдельными именами файлов. Для значений заголовков смотрите справку по синтаксису mod_expires.

Добавить комментарий