Bazaprogram.ru

Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Правила именования css

CSS GuideLines, часть 3. Именование классов

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

  • Для чего используется класс;
  • Где класс может быть использован;
  • С какими другими классами связан этот класс.

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

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

Разделение дефисом

Все слова в названиях классов должны быть разделены дефисом:

CamelCase и знак подчеркивания не используются для классов, следующий пример неправилен:

БЭМ-подобное именование

Для более крупных взаимосвязанных частей интерфейса я использую БЭМ-подобное именование классов.

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

БЭМ разделяет компоненты верстки на три группы:

  • Блок: главный корневой элемент.
  • Элемент: часть блока.
  • Модификатор: вариант или модификация блока.

Проведем аналогию:

В начале класса всегда ставится название блока, для обозначения элемента мы отделяем название блока от названия элемента двумя подчеркиваниями (__), а для обозначения модификатора используем два дефиса (—).

В примере выше мы можем видеть, что .person <> — это блок; у него нет предков. .person__head <> — это элемент, часть блока; наконец, .person—tall — это модификатор, разновидность блока .person <> .

Использование блоков

Блок должен быть логической, самостоятельной единицей. Продолжая наш пример с классом .person <> : мы не можем создать класс .room__person , потому что .room <> — это самостоятельная единица. В таком случае стоит разделять блоки:

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

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

Каждая часть кода представляет свой собственный блок. Неправильный пример использования:

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

Множество слоев

Если бы мы добавили к нашему блоку .person <> еще один элемент, скажем, .person__eye , то нам не нужно было бы при именовании элемента делать шаг назад, добавляя названия предыдущих элементов, вплоть до корневого элемента. То есть, правильно будет писать .person__eye , а не .person__head__eye .

Добавляем модификации элементов

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

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

Но что делать, если мы хотим описать лицо красивого человека? То есть человек красив сам по себе, в отличие от предыдущего примера, и нам нужно описать его лицо? Это делается следующим образом:

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

Заметьте, что мы не добавляем новый элемент .person__face внутрь элемента .person—handsome ; вместо этого мы используем родительский селектор Sass внутри уже существующего селектора .person__face . Это значит, что все правила, связанные с .person__face будут находиться в одном месте, и нам не придется разбрасывать их по всему файлу. Это хорошая практика при работе с вложенным кодом: храните все нужные стили внутри одного контекста (в нашем случае, внутри .person__face ).

Именование в разметке

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

Как классы .box и .profile связаны друг с другом? Как классы .profile и .avatar связаны друг с другом? Связаны ли они вообще? Зависит ли класс .bio от класса .pro-user ? Можно ли использовать класс .avatar вне этой разметки?

При просмотре такой разметки очень сложно ответить на все эти вопросы. Использование соглашения об именовании меняет дело:

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

JavaScript-хуки

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

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

Читать еще:  Css form styles

Как правило, разработчики используют отдельный класс для js, начинающийся с префикса «js-», например:

Такая разметка позволяет использовать стили .btn в любом другом месте, при этом не затрагивая поведения .js-btn .

data-* атрибуты

Также довольно часто разработчиками используются data-* атрибуты в качестве js-хуков, но это неправильно. data-* атрибуты, согласно спецификации, предназначены для хранения данных, недоступных на странице. data-* атрибуты созданы для хранения данных, а не для для привязки к js.

В продолжение темы.

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

Правила именования css

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

Clone with HTTPS

Use Git or checkout with SVN using the web URL.

Downloading

Want to be notified of new releases in yoksel/common-words ?

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio

Latest commit

Files

Permalink

TypeNameLatest commit messageCommit time
Failed to load latest commit information.
CONTRIBUTING.mdUpdate CONTRIBUTING.mdNov 7, 2016
README.mdperf: add main blockJan 14, 2020

Слова, часто используемые в CSS-классах

image , img , picture , pic — картинка

userpic , avatar — юзерпик, маленькая картинка пользователя

thumbnail , thumb — миниатюра, уменьшенное изображение

title , subject , heading , headline , caption — заголовок

lead , tagline — лид-абзац в тексте

text — текстовый контент

desc — описание, вариант текстового контента

excerpt — отрывок текста, обычно используется перед ссылкой «Читать далее. »

quote , blockquote — цитата

snippet — пример кода

copyright , copy — копирайт

list , items — список

item — элемент списка

page — корневой элемент страницы

header — шапка (страницы или элемента)

footer — подвал (страницы или элемента)

section — раздел контента (один из нескольких)

main , body — основная часть (страницы или элемента)

content — содержимое элемента

sidebar — боковая колонка (страницы или элемента)

aside — блок с дополнительной информацией

widget — виджет, например, в боковой колонке

wrapper , wrap — обёртка, обычно внешняя

inner — внутренняя обёртка

container , holder , box — контейнер

grid — раскладка (страницы или элемента) в виде сетки (обычно содержит в себе row и col )

row — контейнер в виде строки

col , column — контейнер в виде столбца

button , btn — кнопка, например, для отправки формы

control — элемент управления, например, стрелки «Вперёд/назад» в фотогалерее, кнопки управления слайдером

dropdown — выпадающий список

phone , mobile — мобильные устройства

phablet — телефоны с большим экраном (6-7″)

notebook , laptop — ноутбуки

desktop — настольные компьютеры

tiny — маленький, крохотный

big , large — большой

socials — блок иконок соцсетей

advertisement , adv , commercial , promo — рекламный блок (режутся Адблоком, не рекомендуется использовать такие классы для блоков с внутренней рекламой)

features , benefits — список основных особенностей товара, услуги

slider , carousel — слайдер, интерактивный элемент с прокруткой содержимого

pagination — постраничная навигация

user , author — пользователь, автор записи или комментария

meta — блок с дополнительной информацией, например, блок тегов и даты в посте

cart , basket — корзина

breadcrumbs — навигационная цепочка, «хлебные крошки»

more , all — ссылка на полную информацию

modal — модальное (диалоговое) окно

popup — всплывающее окно

tooltip , tip — всплывающее подсказки

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

active , current — активный элемент, например, текущий пункт меню

hidden — скрытый элемент

error — статус ошибки

warning — статус предупреждения

success — статус успешного выполнения задачи

pending — состояние ожидания, например, перед сменой статуса на error или success

Именование

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

Абстрактность

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

Чтобы название оставалось абстрактным — оно должно быть максимально отделено от представления.

Представление

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

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

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

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

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

В помощь по выбору названий пригодятся следующие разделы.

Размеры

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

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

Cтили

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

Ключевое слово

Правило ключевого слова (keyword) применимо ко всем контекстам где важно наглядно определить логическую связь элементов. Если в файловой системе это правило в большинстве случаев неактуально, и связь элементов определяется вложенностью, то в HTML/CSS может очень пригодится.

В CSS

По MCSS (из основ АНБ), использование каскада в CSS ограничено ради поддержания независимости блоков и связанности с другими их элементами. Поэтому, самое основное правило именования заключаются в необходимости использовать название модуля (оно же ключевое слово) в начале каждого класса этого модуля:

Чтобы не раздувать названия классов, советуется использовать cловарь сокращений.

Логические части и вложенность названий

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

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

Пример в HTML/CSS:

В примере видно, что класс .module-name_child_t не унаследовал цепочку названия от .module-name_child_cnt, потому, что этот элемент является просто оберткой, которая не несет логики с точки зрения содержания, а используется только для декорации.

Цепочку вложенности названия можно (и нужно) сокращать до тех пор, пока не будет нарушена логическая связь между элементами.

Ограничение вложенности

Словарь сокращений не избавит от длинных названий, есле не ограничивать вложенность. По мотивам BEM подхода в именовании классов, стоит ограничиватся вложенностью в 1-2 элемента, и дробить сущности на мелкие блоки.

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

Рассмотрим на примере предыдущей секции:

Чтобы избежать черезмерной вложенности, мы вынесем абстрактный элемент .module-name_child в отдельный блок.

Таким образом мы убираем прямую связь между блоком .module-name и новым блоком .module-name-child. Они остаются частью одного модуля, но уже в более несвязанном виде .

Обертки

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

Как работать с CSS-препроцессорами и БЭМ

Список рекомендаций по неусложнению жизни себе и другим участникам проекта по вёрстке.

Содержание

Sass, LESS, stylus, PostCSS.

Если у вас есть что дополнить или вы хотите принять участие в разработке этих соглашений, пожалуйста, создайте issue на GitHub или форкните репозиторий и пришлите pull request.

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

Золотые правила

Cоблюдайте предложенные здесь или свои собственные соглашения.

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

  1. Весь код проекта должен выглядеть так, словно он написан одним человеком, вне зависимости от количества разработчиков.
  2. Делать нужно настолько просто, насколько возможно. Но не проще.
  3. Любой инструмент при бездумном использовании может выстрелить в ногу.

БЭМ (как метод именования селекторов)

Зачем

  • Самодокументируемость.
  • Имитация пространства имён (простота и безопасность модификации).
  • Отсутствие зависимости от DOM-структуры.
  • Проектное реиспользование блоков.
  • Кросспроектное реиспользование блоков.

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

Блок — это самостоятельная часть страницы

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

Блоки можно и нужно вкладывать друг в друга

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

Элемент — часть БЭМ-блока

  • Название класса формируется из названия блока с добавлением __ и названия элемента.
  • Название класса должно быть простым и коротким.
  • Название класса должно отвечать на вопрос «Что это?»
  • Избегайте сокращений, кроме наиболее частых.
  • Название не должно отвечать на вопрос «Как выглядит?»

Элемент можно использовать вне его блока только в исключительных случаях

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

Пример: расположение попапа-элемента не внутри блока-родителя, а в самом конце DOM (дабы показывать попап независимо от ограничения видимости родителей).

Если Вы используете БЭМ только как метод именования селекторов, при написании разметки никогда не используйте элемент вне блока.

Почему нельзя просто так располагать элемент вне блока:

  • теряется логика разметки,
  • сложно стилизовать элементы, которые могут оказаться где угодно (float, абс. позиционирование и некоторые другие стили такого элемента могут «сломать» верстку).

Элементов может не быть

Не у всех блоков должны быть элементы: кнопка — всегда БЭМ-блок, но БЭМ-элементы у неё внутри встречаются относительно редко.

Как отличить БЭМ-блок и БЭМ-элемент

Просто задайте себе вопрос: «Эта сущность может потребоваться мне отдельно, сама по себе? Или она нужна только внутри её родителя?» Если нужна отдельно — это БЭМ-блок, если мыслима только внутри родителя — это БЭМ-элемент.

В действительно сомнительных случаях делайте выбор в пользу БЭМ-блока.

Не забывайте о миксовании (возможности иметь на одном теге и класс уровня БЭМ-элемента какого-то родительского блока, и свой класс уровня БЭМ-блока).

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

Некоторые фрагменты дизайна — всегда БЭМ-блоки

  • Кнопка (любые кнопки)
  • Блоки внутри форм (блок для текстового поля, блок для радиокнопки и т.п.)
  • Пагинация
  • Табы
  • Лейблы (метки)
  • Социальные ссылки
  • «Лайк» со счётчиком

Модификатор — дополнительный класс для смены оформления или поведения

  • Название класса формируется из названия блока/элемента с добавлением — и названия модификатора.
  • Название должно быть простым и коротким.
  • Название класса может отвечать на вопросы «Что это?», «Что меняется?», «Чем отличается от прочих?»
  • Избегайте сокращений, кроме наиболее частых.

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

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

Миксование — комбинирование на одном теге классов БЭМ-блока и БЭМ-элемента

Комбинация возможна в любом сочетании: БЭМ-блок + БЭМ-элемент, БЭМ-блок + БЭМ-блок, БЭМ-элемент + БЭМ-элемент. Этот подход позволяет:

  • Добавить некоторые стилевые свойства, необходимые только в месте добавления (использование модификатора нерационально). Пример: для .btn внутри .page-header необходим внешний левый отступ в 37 пикс. Можно дописать для тега с .btn дополнительный класс .page-header__btn и дать отступ с помощью этого селектора. Это нормальная практика, её можно спокойно использовать.
  • Объединить стилизацию 2-х и более блоков. Пример: для .article и для .page-footer__section шрифтовые свойства одинаковы. Можно вынести определение шрифтовых свойств в новый блок .text и дописать этот класс на .article и .page-footer__section . Этот подход излишне связывет части страницы (напоминает OOCSS и класс-хелпер), не делайте так.
  • Обойтись без тега-обёртки с добавляемым селектором. Пример: страница каталога, 7+ товаров в потоке, каждый товар — .product , но каждому элементу потока нужны стилевые свойства ячеек модульной сетки (по которой выстроен потоковый вывод). Можно добавить для .product класс ячейки модульной сетки, что бы не делать обертку с этим классом. Это чревато конфликтом отступов/размеров, не смешивайте на одном теге классы обёртки и содержимого.

Классы БЭМ-блоков следует писать первыми.

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

Один БЭМ-блок = один файл

В файловой системе при работе с CSS-препроцессорами каждый БЭМ-блок должен быть описан в своём отдельном файле.

БЭМ-дерево плоское, в отличие от DOM

В классах БЭМ-элементов нельзя прописывать иерархию (два и более сегмента __ недопустимы).

Sass, LESS, Stylus, PostCSS.

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

  • Один БЭМ-блок = один препроцессорный файл. Всегда.
  • Файл со стилизацией БЭМ-блока должен называться так же, как сам блок.
  • Используйте «генераторы блоков» (простой пример, пример посложнее) для ускорения работы.

@import

  • Компилируйте один файл (диспетчер подключений), в котором подключаются все прочие.
  • Импортируйте файлы только в диспетчере подключений (допустимо импортировать примеси внутри отдельного файла, например, mixins.scss ).
  • Не пишите никаких селекторов в диспетчере подключений.
  • Не импортируйте файлы внутри медиа-условий.
  • Один БЭМ-блок = один препроцессорный файл. Всегда.

Вложения селекторов

  • Чем меньше уровней вложенности, тем лучше.
  • Не допускайте более 3-х уровней вложенности (псевдоэлемены, псевдоселекторы и медиа-условия не считаются увеличивающими вложенность).
  • Осторожно используйте жесткое наследование.
  • Всегда оставляйте пустую строку перед вложенным селектором или @media .
  • Всегда делайте дополнительный отступ для вложений.

@media

  • Вкладывайте @media в селекторы, а не наоборот.
  • Не вкладывайте @media друг в друга.
  • Предпочтите путь mobile-first, избегайте указания @media -условия max-width в пользу min-width.
  • Пишите @media рядом, не пишите селекторы между ними.
  • Пишите условия для @media там, где используете @media , не пишите условия в переменных.

Амперсанд

  • Используйте амперсанд только перед:
    • разделителем БЭМ-элемента,
    • разделителем БЭМ-модификатора,
    • псевдоэлементом или псевдоселектором.
  • Никогда не используйте амперсанд в местах разделения словосочетаний имён блоков, элементов или модификаторов (см. пример).
  • Никогда не повторяйте написанный с амперсандом селектор внутри одного контекста.

Очередность написания в контексте селектора

В контексте селектора используйте следующую очередность:

  1. Стилевые правила для этого селектора.
  2. @media этого контекста.
  3. Псевдоселекторы и псевдоэлементы.
  4. Вложенные сторонние селекторы.
  5. БЭМ-элементы.
  6. БЭМ-модификаторы.
Ссылка на основную публикацию
Adblock
detector