Как называть css-классы

Original author: David Boureau
  • Translation
Основываясь на моих любимых статьях по данной теме и личном опыте, вот мои 5 копеек о том, как называть CSS-классы.

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



Если это поле, используйте элемент input

Читать HTML-документ будет гораздо легче.

Пример:

<div class='submit'/> <!-- Чёёё? -->
<input class='submit'/> <!-- Аа, ясно -->


Источник: Рафаэль Гоитер (французская статья)


1. Назначайте классы как можно ниже по DOM-дереву



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

Пример:
<main class='mainly'>
  <p>Lorem ipsum</p> <!-- Я хотел бы застилизовать этот абзац -->
</main>


main.mainly p { /* Не делайте этого */
}

/* Вместо этого присвойте название класса p : <p class='paragraphly' /> */
.paragraphly {
}


Источник: Крис Койер

2. Называйте классы по содержимому



Пример:
.c-header-logo {
  /* Просто прочитав это название, я догадался, что этот селектор указывает на лого в шапке. */
}


Источник: phpied.com

3. Не называйте класс по содержимому, если картинка нагляднее



Скажем, лого шапки на самом деле выглядит так:
image

Тогда не называйте его header-logo.
.guillotine {
  /* О, сразу видно, что мы хотим стилизовать */
}


4. Попробуйте суффикс -like для лучшей переносимости кода.



Пример:
h3, .h3-like {
/* какое-то оформление */
}

<p class='h3-like'>
  <!-- Я НЕ заголовок h3, но поскольку дизайнер велел мне выглядеть так же,
      я не могу жаловаться на своё название класса -->
</p>


Источник: KNACSS v4

5. Не используйте верблюжийРегистр



Это затрудняет чтение

Пример:
.navToOneModuleICreated {
  font-size:2em;
}
/* против */
.nav-to-one-module-i-created {
  font-size:2em;
}


Источник: Гарри Робертс

6. Пробуйте БЭМ



На сегодняшний день это одно из самых популярных соглашений.

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


(двойной дефис) означает вариант элемента.

(двойное подчёркивание) означает дочерний элемент.

Пример:
<button class='btn btn--warning'> <!-- oдин из вариантов .btn — .btn--warning -->
  <div class='btn__text'></div> <!-- один из дочерних элементов .btn — .btn__text-->
</button>


.btn--warning {
/* Ура! По соглашению я знаю, что код относится к варианту кнопки «warning», даже не заглядывая в HTML-код. Какое облегчение! */
}
.btn__text {
/* По той же причине я знаю, что эти стили предназначаются для текста в кнопке */
}


Источник: Калиг, пятьдесят оттенков БЭМ

Рекомендовано: Smashing Magazine, боремся с БЭМ

7. Пробуйте ещё страшнее



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

Тем не менее, такая своеобразность помогает глазу моментально уловить суть происходящего, и в случае БЭМ, поверьте, это работает.

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

Пример:

.DIMENSIONS_OF_mycomponent {
  /* Куда ещё противнее. Зато теперь понятнее, о чём речь. */
  /* Я использую его для классов-заготовок в SASS. */
  /* Но всё же не злоупотребляйте этим правилом. */
}


8. Не сокращайте описывающие слова



Помимо уже устоявшихся nav, txt, url… следует избегать любых аббревиатур.

Источник: phpied.com

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



В случае визуального компонента начинайте с c-, а в случае объекта (напр. макет) — с o-, мне просто нравится этот трюк Гарри Робертса.

Пример:
<button class='o-layout'>
  <div class='o-layout-item o-grid c-button'></div>
  <!-- С первого взгляда на HTML видно, что за что отвечает.->
</button>


Источник: Гарри Робертс

10. Пробуйте [], когда слишком много классов одного типа



Этот небольшой трюк помогает быстрее изучить HTML. Заметьте, в CSS-файле нет классов .[ и .], они нужны только здесь, чтобы помочь другим читать HTML.

Пример:
<button class='[ o-layout ]'>
  <div class='[ o-layout-item o-layout-item--first ] c-button'></div>
  <!-- С первого взгляда на HTML видно, что за что отвечает.-->
</button>


Источник: исходный код «Inuit Kitchen Sink»

11. Используйте префикс js-, если он используется только для JavaScript



Если Javascript требуется выбрать элемент, не полагайтесь на CSS-стили. Задайте специальный префикс вроде js-.

Пример:
<button class='js-click-me'>
  <!-- При беглом просмотре HTML я понимаю, что у этой кнопки нет CSS-селектора для оформления.
       Но JavaScript использует её, видимо, чтобы поймать какое-то событие. -->
</button>


Источник: Дерик Бейли, книга по marionnette.js

12. Старайтесь отделить родительский элемент от дочернего



Если у класса слишком много обязанностей, разделите его на 2 отдельных свойства.

Пример:

(плохо)
<button class='a'>
  <!-- Этот класс ниже включает сочетание свойств,
       некоторые из которых участвуют в отношении a-b,
       а некоторые — в отношении b-c,
       CSS-файл будет трудно читать.-->
  <div class='child-of-a-and-parent-of-c'>
    <div class='c'>
    </div>
  </div>
</button>


(хорошо)
<button class='a'>
  <!-- Разделите на 2 класса-->
  <div class='child-of-a parent-of-c'>
    <div class='c'>
    </div>
  </div>
</button>


13. Несемантические классы должны явно описывать свои свойства.



Большинство из них содержат только одно свойство, и незачем его скрывать.

.horizontal-alignment { /* Не делайте этого. Выровнять по горизонтали можно разными способами, но при виде этого селектора в HTML-файле совершенно не ясно, КАК ИМЕННО это сделано. */
  text-align: center;
}
/* Предпочитайте этот способ. Смотрите выше про использование БЭМ и односимвольного префикса */
.u-text-align--center {
  text-align: center;
}


14. Явные хаки (I)



Если вы не довольны вашем CSS-селектором, скажите это всем.

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

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

Лично я использую слово «HACK», потому что IDE Atom его автоматически подсвечивает.

Пример:
.my-component {
  margin-left: -7px; /* ХАК здесь: магическое число, нужное, чтобы компенсировать пробел */
}


15. Явные хаки (II)



Еще толковый вариант — собрать весь код со «странностями» в отдельный файл, shame.css

Опять же, Гарри Робертс подсказал

Источник: Гарри Робертс

16. Старайтесь избегать более двух слов для одного имени



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

Пример:
.button {
  /* Хорошо */
}
.dropdown-button {
  /* Всё ещё хорошо */
}
.dropdown-button-part-one {
  /* Хм, по-прежнему хорошо, но будет нечитаемым при добавлении дочернего элемента, например: */
}
.dropdown-button-part-one__button-admin {
  /* Ой, всё!!! */
}


17. Используйте атрибут data-state для указания состояния компонента



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

Пример:
<button class='c-button c-button--warning is-active'>
  <!-- Не делайте этого -->
</button>
<button class='c-button c-button--warning' data-state='is-active'>
  <!-- Так-то лучше.
  Я удалил объявление класа,
  это гарантирует единственность состояния,
  и для тех, кто использует Sass, это сделает код чище.-->
</button>


Источник: к сожалению, не могу вспомнить, кто об этом писал, но его совет оказался весьма полезным.

18. Используйте префиксы has- или is- для состояния



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

Пример:
.activated {
  /* Не делайте этого. Я не совсем понимаю, о чём вы говорите? */
}
.is-activated {
  /* Да, вы оформляете состояние. */
}


Источник: оформление кода в Mobify

19. Используйте дефис в качестве префикса при сочетании нескольких состояний



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

Пример:
<button class="btn -color-red -size-large -shape-round"></button>


Источник: Бен Смифет

20. При объявлении селектора в HTML придерживайтесь одиночных кавычек вместо двойных



Это упрощает чтение документа.

Пример:
<button class="c-button">
  <!-- ПЛОХОЙ ПРИМЕР: в нём используются " вместо '. В этом крошечном примере это не играет особой роли, но когда дело касается сотни селекторов в HTML-файле, одиночные кавычки — лучшая идея. -->
</button>
<button class='c-button'>
  <!-- Хорошо!-->
</button>


Источник: я узнал это, когда работал с командой Predicsis

21. Не следуйте правилам



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

Я не говорю, что всё это пригодится и в вашем случае, поэтому мой наилучший совет:

1) Постарайтесь улучшать своё именование классов, 2) соблюдайте его последовательно для данного проекта, 3) но избегайте переусложнения.

Если правило вам не подходит, просто пропустите его

Наслаждайтесь!

Особая благодарность @HugoGiraudel, @kaelig и @gaetanbt за их отзывы.
Share post

Similar posts

Comments 114

    +18
    Хорошая инструкция. Всем кто только начинает, советую изучить ее и никогда так не делать.
      +3
      Не могли бы обосновать? Я не придираюсь, мне правда интересно какие советы вредные, и почему так не стоит делать. Например, мне очень понравилась идея с js- префиксом.
        +2
        Ух, ох. В целом страдает аргументация и всё очень спорно, странно. Ваши советы действительно сослужат новичкам медвежью услугу примени они их буквально хотя-бы на 50%.

        Приведу яркие примеры, чтобы не писать много.
        — Про BEM. У нас достаточно большой проект и в нём верстальщиков >10. Больше всех ненавидят единственного применившего BEM. Из за него приходится писать LESS код, где селектор даже в виде исходника не поддаётся чтению, а уж во что он превращается после сборки!
        — Какие кавычки брать, зависит от проекта.
        — camelCase или через разделитель. Это сугубо проектная договорённость. Лишь бы все действовали в рамках договорённости установленной в самом начале.
        — Сокращение это точно не зло, иногда без него селектор 3-4 уровня может превратиться в гигантское 100 символьное убожество.
        — Про способы именования классов, способы селектить. По моему опыту, чем больше различных наворотов на тэге — тем сложнее будет селектор. Чем проще — тем лучше, незыблемая истина.

        P.S.
        Странно, что я не нашёл рекомендации использовать именно 3 пробела вместо табуляции.
          +1
          Может два пробела?
            –1
            Лучше всего делать так, как принято на проекте. Может два, может три пробела, а может и табуляция.
            +1
            Проект проектом и тем не менее — во всех языках программирования/разметки де-факто есть предпочтительный стиль.
            В js это кэмел, в питоне подчеркивания, в css дефисы. Так делается в абсолютном большинстве случаев.
            Сделать в отдельно взятом проекте иначе можно, конечно, но смысл?
              –2

              Например, чтобы не писать в js mySuperPuperBlock(), в css .my-super-puper-block, а в инклудах /my/super/puper/block.

                +1
                А это не проблема, это норма. Потому что каждое из этих написаний будет органично в своем контексте.
                  +1

                  И вот из-за этой "нормы" программист не имеет простого способа переименовать компоненту, кроме редких случаев, когда IDE заточена под какой-либо фреймворк.

            0
            Есть хорошее правило для решения этой проблемы: классы — для стилизации, дата-атрибуты — для скриптов.
            +2
            Правило 11 с использованием префикса -js очень удобно в работе, использовав его вы точно будете знать какой класс не надо трогать.
              0
              Единственное бесспорно годное правило, с которым я согласен.
                –5

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

                  +6
                  Не всем требуется стрелять из пушки по воробьям.
                    –5

                    Ну да, некоторые привыкли с палкой за ними бегать. :-)

            +12
            20. При объявлении селектора в HTML придерживайтесь одиночных кавычек вместо двойных

            Почему?
              +4
              Присоединяюсь к вопросу, заранее не согласен с ответом.
                –10
                Автор же объясняет:
                но когда дело касается сотни селекторов в HTML-файле, одиночные кавычки — лучшая идея.
                  +4
                  Почему лучшая идея? Вообще лучше придерживаться одного стандарта с кавычками в HTML.
                    –4
                    Ну автор же даёт свои советы (видимо в его проектах это помогает), он же не призывает их использовать, о чём и пишет в последнем пункте. Если совет не подошёл, просто пропустите его, да и всё.
                      +1
                      А вот странный у меня вопрос, а не пофиг ли? Ну оно понятно когда стандартно хорошо, а когда не стандартно, должно же быть плохо? Но как то до сих пор не слышно баталий по этому поводу, никто не страдает, слез не пускает. Вложенный в html атрибут типа data-html="" кусок html с теми же двойными кавычками никак не ломает парсер браузера. никто эти кавычки не видит кроме как в исходном коде… да и даже если видит особо не замечает. Проблем как то ни с js ни с чем то еще вроде бы и нет…
                        0

                        Насколько я помню, одинарные кавычки и двойные — одинаково стандартные. Использование двойных не более, чем традиция.

                          +1
                          Хорошо, формально это традиция. Чем плоха эта традиция пока я так и не понял. То что «не традиция» — называется «дурным тоном». Так же как писать теги в ВЕРХНЕМ РЕГИСТРЕ. По спецификации HTML допускается вообще не использовать кавычки, но это так же дурной тон.
                            +1
                            Возможно, автор имел в виду, что одинарные кавычки занимают меньше места визуально, и потому легче воспринимаются глазом. Если это так — то я разделяю его мнение. В HTML, правда, так и использую двойные, а вот в JS только одинарные.
                              0

                              В monospaced-шрифте что ', что " занимают одинаковое место.
                              Я надеюсь на то, что не существует людей, которые пишут код в редакторах, где установлен не моноширинный шрифт...

                                +1
                                Визуально же. Т.е. больше отступы от соседних символов, легче выделяется содержимое…
                                  +1

                                  Да вот фиг знает… Лично для меня использование (в HTML) ' это плохо. Все связано с тем, что с "обоих сторон" кавычки стоят "широкие" символы (...='x...), и в случае использования ' все становится не таким единообразным, что ли…
                                  Ну а отделять содержимое мне помогает подсветка синтаксиса в IDE.

                              +1
                              Не всякая традиция — хороший тон (см. тж. http://css-live.ru/faq/zabluzhdeniya-razrabotchikov.html). Скорее уж бездумно отбрасывать годную возможность стандарта, потому что когда-то кто-то сказал, что это плохо, а проверить никто не удосужился — дурной тон:)

                              Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись — не потому, что «так положено», а потому, что это логичное техническое требование, прямо вытекающее из синтаксиса языка. У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.
                                0
                                Не всякая традиция — хороший тон
                                Я не говорил, что всякая традиция — хороший тон.
                                Скорее уж бездумно отбрасывать годную возможность стандарта...
                                У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.

                                Вы сами с собой беседуете? Я писал конкретно про кавычки. По теме: освежите в памяти басню «Лебедь, щука и рак».

                                Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись
                                Для любителей БЭМ это не проблема. Сделают новую тулзу, которая автоматом будет менять пробел на тройное нижнее подчеркивание… (полушутка)
                                  0
                                  Аргумент к традиции сам по себе очень слабый. И басня несколько мимо цели: направления движения одного воза с поклажей являются взаимоисключающими, но стиль кавычек для разных атрибутов — нет. Не шибко красиво, но работать будет.

                                  Более того, вполне могу представить себе экстравагантное соглашение, чтобы функциональные атрибуты (href, value, data-activated и т.п.) ограничивать двойными кавычками, а оформление (class) — одинарными. Чтобы принятая в команде IDE подсвечивала их по-разному и они сразу разделялись визуально. Признаюсь, при первом прочтении статьи я понял этот совет именно так:)

                                  Сделают новую тулзу, которая автоматом будет менять пробел на...

                                  Не сделают. Не получится отличить следующий класс от следующего атрибута (особенно если в ходу кастомные).
                              +2
                              Мне кажется что в HTML традиционно используются двойные кавычки т.к. это язык разметки текста в котором на английском языке довольно часто попадаются апострофы, для обозначения которых используются одинарные кавычки (напр. " She's great. Don't you think? ")
                              Поэтому чтобы не париться с постоянным экранированием апострофов — удобнее пользоваться двойными кавычками.

                              Визуально же одинарные кавычки меньше «рябят в глазах» когда их много, чем двойные. Думаю из этого и следует совет автора.
                                0
                                Для апострофа, который символ в тексте, есть специальный символ. Для кавычек в тексте, кстати, тоже (подробнее — habrahabr.ru/post/25531). Не надо путать символы для текста с символами для кода!
                          0
                          В пояснении к пункту:
                          > Это упрощает чтение документа.
                          Видимо, для автора так проще вычленить взглядом названия классов при беглом просмотре исходников.
                          0
                          В 19 примере часть кода утеряно или я что-то не понял? Объясните, пожалуйста, если все верно.
                            0
                            Мне кажется там не должно быть первой строки. Может скопировал неудачно.
                              +1
                              Да, вы правы, исправил.
                            0
                            Я тоже люблю одинарные кавычки. Во-первых, с ними чище, во-вторых, не нужен shift при написании.
                            Отсюда у меня два вопроса:
                            1. Почему все не используют одинарные кавычки (в качестве «первых кавычек»)?
                            2. Откуда пошла мода на двойные? Чем они кавычнее одинарных?
                              0
                              Потому что во всех учебниках и документации двойные.
                                +1
                                я, например, в JS пишу
                                var html = '<div class="test">';
                                
                                в связи с этим мне проще писать двойные. Тоже самое и с php. Если не ошибаюсь, где то были просчеты, что одинарные кавычки в php работают быстрее, чем двойные. Поэтому и начал обвертывать все в одинарные, что приводит к двойным внутри.
                                  +1
                                  Насколько я понимаю, php проводит обработку текста внутри двойных, именно по этому "\s" выведет пробел, а '\s' — \s. Но не думаю, что стоит приплетать php к этому посту, тем более я считаю, что стоит html писать вне тела php скрипта.
                                    0
                                    php включает парсер для строк в двойных кавычках. Приплетать сюда php можно. Есть смысл из-за его особенности.
                                    В нем при выводе html двойные кавычки уже заняты.

                                    <? $html .= "<div class='$variable'>Профиль</div>" ?>

                                    что лучше чем
                                    <? $html .= "<div class=\"$class\">Профиль</div>" ?>


                                    А как то еще изворачиваться через sprintf как то… глупо.
                                      0

                                      Ну, люди не только на PHP веб делают:)

                                        0
                                        Эта особенность не только у PHP. К примеру, ей обладают те же Perl и Ruby.
                                        Если пишешь на нескольких языках, то поневоле привыкаешь использовать правильные кавычки :)
                                          –5

                                          Было бы странно, если бы было иначе, ведь Рубин — законный наследник Жемчужины, А ГипертекстовыйПреПроцессор — его бастард.

                                          0
                                          В вашем примере лучше использовать конкатенацию. Хотя бы просто потому что беглого взгляда будет достаточно чтобы увидеть наличие переменной в строке. Не говоря о том что ваш вариант медленнее (хоть и не столь существенно)

                                            0
                                            Переменная огнем горит, если включена подсветка кода, что очень удобно. А когда нужно где то переменных от 10 вставить в html шаблон, конкатенация, мягко говоря, уменьшает читабельность в разы, добавляя еще один ряд кавычек с точками, по моим ощущениям.
                                              0
                                              Ха… а если посмотреть эти тесты, где конкатенация больше нескольких раз происходит, то выигрышь такой же небольшой выходит при разборе строки.
                                              https://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html
                                              Это 2012 год.
                                              А при наличие опкеша с 5.5 вообще пишут разницы просто никакой.
                                              +1
                                              ?><div class="<?=$class?>">Профиль</div><?php
                                              

                                              Думаю, не стоит напоминать, что есть другие альтернативные способы положить строку в переменную или вывести в тело ответа.
                                                0
                                                Не всегда он удобен. Мне почему то кажется что в вашем примере кое где не рабочее решение
                                                  0
                                                  Точнее говоря, разве этот вариант везде работает? Разве можно им вернуть результат через return?
                                              0

                                              Нет, "\s" не выведет пробел.

                                                0
                                                Да, Вы правы. Сказалось использование регулярных выражений. Лучше взять в качестве примера \t
                                                  0

                                                  Там это тоже не пробел, а любой пробельный символ.

                                                    0

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

                                                      +1

                                                      Где там? Вы целиком диалог посмотрите.

                                                        0

                                                        «Там», это там, где \t. Диалог я читал целиком, возможно выразился не совсем корректно. Имелась ввиду цепочка вида:


                                                        — Там это любой пробельный символ.
                                                        — Там это символ табуляции.
                                                          +1

                                                          Диалог не такой был. Мы разговаривали про «\s» в регулярных выражениях.

                                            –1
                                            Думаю, исторически так сложилось. Ещё с языка C (может и раньше) строки кавычились двойными, символы – одинарными. Однако, в JS символы являются строками и разницы нет.
                                              0

                                              А я вообще использую Emmet и структура блоков раскладывается сама :)

                                              +11
                                              Хорошая подборка советов, но 3 пункт вызывает недоумение.
                                              3. Не называйте класс по содержимому, если картинка нагляднее

                                              Это какой-то антипаттерн. Зачем смешивать модель и представление? Если картинка в будущем изменится, придется переименовывать все стили под новый контент?
                                                +2
                                                Есть некоторые отдельные случаи, когда автор будет прав.
                                                Например, в рейтинге использовать класс .star, а не что-то более абстрактное типа .point или .mark
                                                Хотя казалось бы — звездочки это чистой воды оформление и ничто не мешает завтра нарисовать там яблочки, сердечки или пальцы вверх.
                                                Но де-факто если сказать человеку «звездочка» — он мгновенно понимает, о чем идет речь.
                                                0
                                                Используйте префикс js-, если он используется только для JavaScript

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

                                                image

                                                  +3
                                                  довольно странно смотрится 20 пункт, когда в примерах статьи используются одинарные и двойные кавычки. В 6 примере вообще вперемешку одинарные и двойные кавычки. На сайте того же Predicsis используются двойные кавычки.
                                                    –1
                                                    Исправил в 6- и 20-ых пунктах. Но не думаю, что это так критично.
                                                      +10
                                                      Это очень показательно, что даже в десятке строк кода получилась смесь из одинарных и двойных кавычек.
                                                    +1
                                                    1. Декомпозируйте свои шаблоны и стили на максимально компактные модули, и вам не придется страдать и постоянно выдумывать что-то для поддержания порядка в проекте.
                                                      +1
                                                      Как разработчика, далекого от веба, меня всегда интересовало: а откуда пошла практика именовать селеторы в лисповой нотации «this-is-selector» вместо змеиной «this_is_selector»? Большинство текстовых редаторов воспринимают идентификатор с подчеркиваниями как одно слово, это довольно удобно.
                                                        0

                                                        Видимо пошло от имен CSS-свойств (z-index, border-left), которые пишутся в пишутся в шашлычном регистре.

                                                          0

                                                          КМК — удобство. Напечатать - можно одним нажатием на -, а чтобы напечатать _ нужно нажать Shift+-.

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

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

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

                                                          P.S. Про использование классов-пустышек с префиксом «js-» для манипулирования DOM-элементами посредством JavaScript чертовски верно подмечено!

                                                            +1
                                                            Да мёртвые они в большинстве. Я пытался с ними знакомиться в свое время.

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

                                                            Остальные… Читаешь, читаешь — вроде и улавливается какая-то логика, но чё с этим всем делать в реальности — непонятно. Вот у меня есть макет, как его верстать? Ни черта не ясно. OOCSS, SMACSS и MCSS в целом педалируют одну и ту же идею плюс-минус частные вариации. И она хоть и имеет определенную внутреннюю логику, но запутанная и сложно применимая в реальной практике. Автор MCSS, кстати, официально объявил, что рекомендует всем переходить на BEM. Atomic CSS вообще мертворожденная чушь.
                                                              0
                                                              Автор SMACSS тоже сказал что нужно просто использовать BEM: https://twitter.com/snookca/status/606908589295464449
                                                                +1
                                                                Автор MCSS, кстати, официально объявил, что рекомендует всем переходить на BEM.

                                                                Вы не могли бы рассказать подробнее, где и когда он такое заявил?
                                                                  +2
                                                                  https://habrahabr.ru/post/256109/#comment_8442829
                                                              +5
                                                              Попробуйте суффикс -like для лучшей переносимости кода: .h3-like, .h3-title

                                                              какой-то странный совет привязываться к h3

                                                              Всегда пишите название класса прямо в HTML-элементе, для которого нужно оформление:
                                                              <p class='paragraphly' /> 
                                                              

                                                              Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?

                                                              .c-header-logo

                                                              а если такое же лого лежит в футере или где-то в контенте, я уже не смогу переиспользовать класс, получается?

                                                              .guillotine {
                                                                /* О, сразу видно, что мы хотим стилизовать */
                                                              }
                                                              

                                                              wut?
                                                                +1
                                                                Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?

                                                                Смею предположить что имеються ввиду случаи не для текстовых блоков, например как для ссылок в меню и прочее
                                                                <nav class="menu">
                                                                <a class="menu-link" href="#">1</a>
                                                                </nav>
                                                                

                                                                вместо:
                                                                <nav class="menu">
                                                                <a href="#">1</a>
                                                                </nav>
                                                                
                                                                  +1
                                                                  Ну, с меню было бы все очевидно, но в примерах приведен именно параграф
                                                                    0
                                                                      –1
                                                                      А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?
                                                                      Вы не производите нормализацию пользовательского ввода? Не играйте с огнём.
                                                                      0
                                                                      «wut?»

                                                                      ну, там форма лого на нож гильотины похожа отдалённо
                                                                        +2
                                                                        а полоса навигации главного меню похожа на прямоугольник, а контентная часть в определенный момент времени похожа на квадрат.
                                                                          0
                                                                          и именно поэтому эти названия не говорящие, а «гильотина» сразу подсказывает, о каком элементе речь:)
                                                                        0
                                                                        В случае с .c-header-logo думаю можно сделать так:
                                                                        .c-header-logo, .c-footer-logo, .c-content-logo {… }
                                                                        +1
                                                                        Большинство вышеуказанных проблем решает нативно SASS/LESS.

                                                                        .block#id {
                                                                        .element {
                                                                        .model {
                                                                        /* some properties */
                                                                        }
                                                                        }
                                                                        }

                                                                        Выглядит читаемо и легко понять, где что находится. А ещё, кто-то должен сказать новичкам, что БЭМ — это всего лишь одно решение из многих и оно далеко не идеальное.

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

                                                                        .searchBlock { }
                                                                          +1

                                                                          Я тоже не понимаю этой проблемы. Если ты целый день ничего кроме CSS (и, может быть, лиспа, лол) не пишешь, то кебаб-кейс может и смотрится нормально. А когда надо переключаться с JS (а то и, упаси господь, c Java/C#, в меньшей степени PHP/Python/Ruby), то эта разнобоица как-то совсем ни к чему.

                                                                          +3
                                                                          > 5. Не используйте верблюжийРегистр
                                                                          > Это затрудняет чтение
                                                                          Получается, большинство тех, кто пишет на Java — мазохисты?
                                                                            0
                                                                            Да и в PHP вроде как не принято змеиным пользоваться.
                                                                              0

                                                                              В яве просто выбора нет, string-builder не является валидным идентификатором.

                                                                                +2

                                                                                Окей, окей, был неправ, string-builder является валидным идентификатором в Java.

                                                                                0
                                                                                не мазохисты, а придерживаются стандартов языка (как и в Javascript). И да, в некоторых случаях читабельность разбитых на визуальные блоки слов выше. Пробел был не зря придуман
                                                                                  0
                                                                                  Ну, в обосновании этого пункта ни слова про стандарты языка, там лишь безапелляционная фраза «Это затрудняет чтение». Я считаю, что это спорное утверждение и не более чем вопрос привычки.
                                                                                +1
                                                                                Эта особенность CSS — придумывать и помнить сотни способов для именования классов — просто убивает…
                                                                                Особенно после изучения пространства имен, например в php.
                                                                                0
                                                                                В 4 пункте в примере в css класс называется h3-like, а в html уже h3-title, это опечатка или так задумано и я что-то не понимаю?
                                                                                  0
                                                                                  Статья местами, а вообще даже чуть менее, чем полностью, смахивает на откровенный стеб. У меня даже домен оригинального поста не резолвится :)
                                                                                    0
                                                                                    С сайтом автора действительно какая-то беда приключилась. Но кеш Яндекса пока всё помнит.
                                                                                      0
                                                                                      Оригинал статьи переехал на новый домен bdavidxyz.com.
                                                                                    0
                                                                                    В №1 перестарался для примера. Кто пэшкам() задаёт классы? Я конечно понимаю в чем суть и пользуюсь этим, но не стоит параграфу задавать класс для стилизации. Если конечно вы не «ТОП-верстальщик», который ни разу не интегрировал верстку с движками.
                                                                                    • UFO just landed and posted this here
                                                                                        0
                                                                                        пункт 10.
                                                                                        а это вообще валидно?


                                                                                        Вообще да, запрещенных символов тут нет.
                                                                                        0
                                                                                        .some_class_name
                                                                                        мне кажется выглядит читабельней, чем
                                                                                        .some-class-name
                                                                                          +1
                                                                                          someClassName тоже читается нормально.
                                                                                          0
                                                                                          И после таких статей, пишем статьи, как наши страницы стали в три раза тяжелее…
                                                                                            0
                                                                                            Писать css руками в 21 веке — это деградация.
                                                                                              0
                                                                                              и ассемблер тоже деградация)
                                                                                                0
                                                                                                При чем здесь ассемблер?
                                                                                                  0
                                                                                                  А деградация причем?) Никуда css не девался и никакие препроцессоры его не убивали
                                                                                                    0
                                                                                                    Понятно что никуда не девался, просто я говорю о том что вообще его писать руками — это дурная практика тормозящая развитие человечества.
                                                                                                      0
                                                                                                      Как же вы стилизуете сайты без CSS? Пустыми картинками как в 90-е? Что вы используете вместо border-radius? SASS, Less, Stylus и т.п. — это тот же CSS, только с плюшками.
                                                                                              +3
                                                                                              11. Используйте префикс js-, если он используется только для JavaScript

                                                                                              Раньше использовал классы с префиксами как в статье, но всегда находил это решение неудобным так как часто ставило в замешательство при наличии 3 и более классов на теге, например так
                                                                                              <button class="button button_large js-button button_primary pull-right"></button>

                                                                                              В итоге перешел на data атрибуты, с ними сразу видно что на элементе есть JS обработчик
                                                                                              <button class="button button_large button_primary pull-right" data-js-button></button>


                                                                                              6. Пробуйте БЭМ
                                                                                              (двойной дефис) означает вариант элемента.

                                                                                              Вместо двойного дефиса удобнее использовать один символ подчёркивания
                                                                                              .my-element_modifier

                                                                                              Удобство в том, что выделение через ctrl+shift+left/right на дефисе останавливается, а на подчёркивание — нет. То же самое и с двойным кликом мыши, с подчёркиванием выделиться весь селектор, а без него — придётся делать дополнительные телодвижения.
                                                                                                +1
                                                                                                21. Не следуйте правилам

                                                                                                Скорей всего автор имел ввиду: «Не стоит слепо следовать всем этим правилам», потому что сейчас фраза несколько выпадает из контекста и кажется, что автор советует вообще отказаться от идеи следовать любым правилам (не только приведенным в статье) при работе с CSS/HTML, но скорей всего это не так.
                                                                                                  +1
                                                                                                  Имхо, скорее имелось в виду что-то вроде «всегда думайте своей головой и доверяйте своему опыту». Какие-то советы могут быть хороши в 90% или даже 98% случаев, но всегда есть ненулевая вероятность, что на конкретном проекте у конкретного читателя встретится то самое исключение, где разумнее будет сделать ровно наоборот:)
                                                                                                    0
                                                                                                    Пост теряет всякий смысл своим 21-ым пунктом. Логически получается: «Думайте своей головой» но тогда слишком много пустой воды с очень простым советом.
                                                                                                      0
                                                                                                      Ну почему. «Знайте 100500 вариантов, но применяйте их не бездумно, а к месту»)

                                                                                                  Only users with full accounts can post comments. Log in, please.