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. Не называйте класс по содержимому, если картинка нагляднее
Скажем, лого шапки на самом деле выглядит так:
Тогда не называйте его 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 за их отзывы.
Комментарии (113)
CCgames
13.06.2016 23:06+1220. При объявлении селектора в HTML придерживайтесь одиночных кавычек вместо двойных
Почему?
psywalker
13.06.2016 23:31-10Автор же объясняет:
но когда дело касается сотни селекторов в HTML-файле, одиночные кавычки — лучшая идея.
Andchir
13.06.2016 23:45+4Почему лучшая идея? Вообще лучше придерживаться одного стандарта с кавычками в HTML.
psywalker
14.06.2016 00:11-4Ну автор же даёт свои советы (видимо в его проектах это помогает), он же не призывает их использовать, о чём и пишет в последнем пункте. Если совет не подошёл, просто пропустите его, да и всё.
Alexufo
14.06.2016 00:23+1А вот странный у меня вопрос, а не пофиг ли? Ну оно понятно когда стандартно хорошо, а когда не стандартно, должно же быть плохо? Но как то до сих пор не слышно баталий по этому поводу, никто не страдает, слез не пускает. Вложенный в html атрибут типа data-html="" кусок html с теми же двойными кавычками никак не ломает парсер браузера. никто эти кавычки не видит кроме как в исходном коде… да и даже если видит особо не замечает. Проблем как то ни с js ни с чем то еще вроде бы и нет…
bolk
14.06.2016 08:33Насколько я помню, одинарные кавычки и двойные — одинаково стандартные. Использование двойных не более, чем традиция.
Andchir
14.06.2016 10:04+1Хорошо, формально это традиция. Чем плоха эта традиция пока я так и не понял. То что «не традиция» — называется «дурным тоном». Так же как писать теги в ВЕРХНЕМ РЕГИСТРЕ. По спецификации HTML допускается вообще не использовать кавычки, но это так же дурной тон.
psykeonfarm
14.06.2016 13:00+1Возможно, автор имел в виду, что одинарные кавычки занимают меньше места визуально, и потому легче воспринимаются глазом. Если это так — то я разделяю его мнение. В HTML, правда, так и использую двойные, а вот в JS только одинарные.
POPSuL
17.06.2016 14:26В monospaced-шрифте что
', что"занимают одинаковое место.
Я надеюсь на то, что не существует людей, которые пишут код в редакторах, где установлен не моноширинный шрифт...
SelenIT3
17.06.2016 14:31+1Визуально же. Т.е. больше отступы от соседних символов, легче выделяется содержимое…
POPSuL
17.06.2016 16:03+1Да вот фиг знает… Лично для меня использование (в HTML)
'это плохо. Все связано с тем, что с "обоих сторон" кавычки стоят "широкие" символы (...='x...), и в случае использования'все становится не таким единообразным, что ли…
Ну а отделять содержимое мне помогает подсветка синтаксиса в IDE.
SelenIT3
14.06.2016 21:08+1Не всякая традиция — хороший тон (см. тж. http://css-live.ru/faq/zabluzhdeniya-razrabotchikov.html). Скорее уж бездумно отбрасывать годную возможность стандарта, потому что когда-то кто-то сказал, что это плохо, а проверить никто не удосужился — дурной тон:)
Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись — не потому, что «так положено», а потому, что это логичное техническое требование, прямо вытекающее из синтаксиса языка. У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.Andchir
15.06.2016 22:28Не всякая традиция — хороший тон
Я не говорил, что всякая традиция — хороший тон.
Скорее уж бездумно отбрасывать годную возможность стандарта...
У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.
Вы сами с собой беседуете? Я писал конкретно про кавычки. По теме: освежите в памяти басню «Лебедь, щука и рак».
Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись
Для любителей БЭМ это не проблема. Сделают новую тулзу, которая автоматом будет менять пробел на тройное нижнее подчеркивание… (полушутка)SelenIT3
16.06.2016 11:16Аргумент к традиции сам по себе очень слабый. И басня несколько мимо цели: направления движения одного воза с поклажей являются взаимоисключающими, но стиль кавычек для разных атрибутов — нет. Не шибко красиво, но работать будет.
Более того, вполне могу представить себе экстравагантное соглашение, чтобы функциональные атрибуты (href,value,data-activatedи т.п.) ограничивать двойными кавычками, а оформление (class) — одинарными. Чтобы принятая в команде IDE подсвечивала их по-разному и они сразу разделялись визуально. Признаюсь, при первом прочтении статьи я понял этот совет именно так:)
Сделают новую тулзу, которая автоматом будет менять пробел на...
Не сделают. Не получится отличить следующий класс от следующего атрибута (особенно если в ходу кастомные).
YemSalat
14.06.2016 12:59+2Мне кажется что в HTML традиционно используются двойные кавычки т.к. это язык разметки текста в котором на английском языке довольно часто попадаются апострофы, для обозначения которых используются одинарные кавычки (напр. " She's great. Don't you think? ")
Поэтому чтобы не париться с постоянным экранированием апострофов — удобнее пользоваться двойными кавычками.
Визуально же одинарные кавычки меньше «рябят в глазах» когда их много, чем двойные. Думаю из этого и следует совет автора.SelenIT3
14.06.2016 20:40Для апострофа, который символ в тексте, есть специальный символ. Для кавычек в тексте, кстати, тоже (подробнее — habrahabr.ru/post/25531). Не надо путать символы для текста с символами для кода!
Vadiok
14.06.2016 12:59В пояснении к пункту:
> Это упрощает чтение документа.
Видимо, для автора так проще вычленить взглядом названия классов при беглом просмотре исходников.
ilyaplot
13.06.2016 23:07В 19 примере часть кода утеряно или я что-то не понял? Объясните, пожалуйста, если все верно.
Habra-Mikhail
13.06.2016 23:29Мне кажется там не должно быть первой строки. Может скопировал неудачно.
Carduelis
13.06.2016 23:08Я тоже люблю одинарные кавычки. Во-первых, с ними чище, во-вторых, не нужен shift при написании.
Отсюда у меня два вопроса:
1. Почему все не используют одинарные кавычки (в качестве «первых кавычек»)?
2. Откуда пошла мода на двойные? Чем они кавычнее одинарных?CCgames
13.06.2016 23:10+1я, например, в JS пишу
в связи с этим мне проще писать двойные. Тоже самое и с php. Если не ошибаюсь, где то были просчеты, что одинарные кавычки в php работают быстрее, чем двойные. Поэтому и начал обвертывать все в одинарные, что приводит к двойным внутри.var html = '<div class="test">';ilyaplot
13.06.2016 23:16+1Насколько я понимаю, php проводит обработку текста внутри двойных, именно по этому "\s" выведет пробел, а '\s' — \s. Но не думаю, что стоит приплетать php к этому посту, тем более я считаю, что стоит html писать вне тела php скрипта.
Alexufo
13.06.2016 23:25php включает парсер для строк в двойных кавычках. Приплетать сюда php можно. Есть смысл из-за его особенности.
В нем при выводе html двойные кавычки уже заняты.
<? $html .= "<div class='$variable'>Профиль</div>" ?>
что лучше чем
<? $html .= "<div class=\"$class\">Профиль</div>" ?>
А как то еще изворачиваться через sprintf как то… глупо.
ertaquo
14.06.2016 08:44Эта особенность не только у PHP. К примеру, ей обладают те же Perl и Ruby.
Если пишешь на нескольких языках, то поневоле привыкаешь использовать правильные кавычки :)
vintage
14.06.2016 08:58-5Было бы странно, если бы было иначе, ведь Рубин — законный наследник Жемчужины, А ГипертекстовыйПреПроцессор — его бастард.
parmactep
14.06.2016 15:14В вашем примере лучше использовать конкатенацию. Хотя бы просто потому что беглого взгляда будет достаточно чтобы увидеть наличие переменной в строке. Не говоря о том что ваш вариант медленнее (хоть и не столь существенно)
Alexufo
14.06.2016 15:42Переменная огнем горит, если включена подсветка кода, что очень удобно. А когда нужно где то переменных от 10 вставить в html шаблон, конкатенация, мягко говоря, уменьшает читабельность в разы, добавляя еще один ряд кавычек с точками, по моим ощущениям.
Alexufo
14.06.2016 15:47Ха… а если посмотреть эти тесты, где конкатенация больше нескольких раз происходит, то выигрышь такой же небольшой выходит при разборе строки.
https://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html
Это 2012 год.
А при наличие опкеша с 5.5 вообще пишут разницы просто никакой.
ilyaplot
15.06.2016 12:17+1?><div class="<?=$class?>">Профиль</div><?php
Думаю, не стоит напоминать, что есть другие альтернативные способы положить строку в переменную или вывести в тело ответа.
yarg
14.06.2016 07:50-1Думаю, исторически так сложилось. Ещё с языка C (может и раньше) строки кавычились двойными, символы – одинарными. Однако, в JS символы являются строками и разницы нет.
Smi1e
13.06.2016 23:12+11Хорошая подборка советов, но 3 пункт вызывает недоумение.
3. Не называйте класс по содержимому, если картинка нагляднее
Это какой-то антипаттерн. Зачем смешивать модель и представление? Если картинка в будущем изменится, придется переименовывать все стили под новый контент?
dom1n1k
14.06.2016 19:28+2Есть некоторые отдельные случаи, когда автор будет прав.
Например, в рейтинге использовать класс .star, а не что-то более абстрактное типа .point или .mark
Хотя казалось бы — звездочки это чистой воды оформление и ничто не мешает завтра нарисовать там яблочки, сердечки или пальцы вверх.
Но де-факто если сказать человеку «звездочка» — он мгновенно понимает, о чем идет речь.
Alexufo
13.06.2016 23:17Используйте префикс js-, если он используется только для JavaScript
В принципе, лучше чем без префикса, но можно использовать и свои атрибуты как в ангуляре.
Да и еще firefox показывает есть ли событие на элементе, помогает при чистке, по мне удобнее чем в хроме
ambalus
13.06.2016 23:28+3довольно странно смотрится 20 пункт, когда в примерах статьи используются одинарные и двойные кавычки. В 6 примере вообще вперемешку одинарные и двойные кавычки. На сайте того же Predicsis используются двойные кавычки.
i360u
14.06.2016 06:56+1- Декомпозируйте свои шаблоны и стили на максимально компактные модули, и вам не придется страдать и постоянно выдумывать что-то для поддержания порядка в проекте.
eyeofhell
14.06.2016 09:34+1Как разработчика, далекого от веба, меня всегда интересовало: а откуда пошла практика именовать селеторы в лисповой нотации «this-is-selector» вместо змеиной «this_is_selector»? Большинство текстовых редаторов воспринимают идентификатор с подчеркиваниями как одно слово, это довольно удобно.
k12th
14.06.2016 10:58Видимо пошло от имен CSS-свойств (
z-index,border-left), которые пишутся в пишутся в шашлычном регистре.
POPSuL
17.06.2016 14:33КМК — удобство. Напечатать
-можно одним нажатием на-, а чтобы напечатать_нужно нажатьShift+-.
bashkos
14.06.2016 09:41+1Не БЭМом единым жив фронтендер. Есть множество различных методологий организации стилей. Каждая из них, как и БЭМ имеет свои плюсы и минусы, и хороши они в разных проектах. На проекте среднего уровня для меня лучшим выбором оказалась MCSS.
Будет полезно ознакомиться с каждой из них хотя бы поверхностно.
А вот остальные пункты из списка даже как-то противоречат конвенции БЭМ, ибо в данной методологии свои правила именования классов элементов блока, классов-модификаторов.
P.S. Про использование классов-пустышек с префиксом «js-» для манипулирования DOM-элементами посредством JavaScript чертовски верно подмечено!
dom1n1k
14.06.2016 19:40+1Да мёртвые они в большинстве. Я пытался с ними знакомиться в свое время.
BEM вот сразу понятен — ну во всяком случае базовые принципы и с какой стороны к нему подходить. А нюансы уже обкатываются на практике. Кроме того, BEM имеет слабую внутреннюю связность и потому гораздо терпимее прочих относится к смешению подходов.
Остальные… Читаешь, читаешь — вроде и улавливается какая-то логика, но чё с этим всем делать в реальности — непонятно. Вот у меня есть макет, как его верстать? Ни черта не ясно. OOCSS, SMACSS и MCSS в целом педалируют одну и ту же идею плюс-минус частные вариации. И она хоть и имеет определенную внутреннюю логику, но запутанная и сложно применимая в реальной практике. Автор MCSS, кстати, официально объявил, что рекомендует всем переходить на BEM. Atomic CSS вообще мертворожденная чушь.
Delka
15.06.2016 12:26Автор SMACSS тоже сказал что нужно просто использовать BEM: https://twitter.com/snookca/status/606908589295464449
derSmoll
14.06.2016 09:45+5Попробуйте суффикс -like для лучшей переносимости кода: .h3-like, .h3-title
какой-то странный совет привязываться к h3
Всегда пишите название класса прямо в HTML-элементе, для которого нужно оформление:
<p class='paragraphly' />
Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?
.c-header-logo
а если такое же лого лежит в футере или где-то в контенте, я уже не смогу переиспользовать класс, получается?
.guillotine { /* О, сразу видно, что мы хотим стилизовать */ }
wut?hermit931
14.06.2016 12:26+1Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?
Смею предположить что имеються ввиду случаи не для текстовых блоков, например как для ссылок в меню и прочее
<nav class="menu"> <a class="menu-link" href="#">1</a> </nav>
вместо:
<nav class="menu"> <a href="#">1</a> </nav>vintage
14.06.2016 20:24-1А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?
Вы не производите нормализацию пользовательского ввода? Не играйте с огнём.
skyline405
14.06.2016 13:02В случае с .c-header-logo думаю можно сделать так:
.c-header-logo, .c-footer-logo, .c-content-logo {… }
DaturInnoxia
14.06.2016 13:02+1Большинство вышеуказанных проблем решает нативно SASS/LESS.
.block#id {
.element {
.model {
/* some properties */
}
}
}
Выглядит читаемо и легко понять, где что находится. А ещё, кто-то должен сказать новичкам, что БЭМ — это всего лишь одно решение из многих и оно далеко не идеальное.
По поводу «Не используйте верблюжийРегистр» — не используйте длинные имена классов и будет вам счастье, напротив очень удобно даблкликом его выделять в редакторе кода. Всё выглядит абсолютно читаемо:
.searchBlock { }k12th
14.06.2016 13:34+1Я тоже не понимаю этой проблемы. Если ты целый день ничего кроме CSS (и, может быть, лиспа, лол) не пишешь, то кебаб-кейс может и смотрится нормально. А когда надо переключаться с JS (а то и, упаси господь, c Java/C#, в меньшей степени PHP/Python/Ruby), то эта разнобоица как-то совсем ни к чему.
ivan19631224
14.06.2016 13:02+3> 5. Не используйте верблюжийРегистр
> Это затрудняет чтение
Получается, большинство тех, кто пишет на Java — мазохисты?
asci
15.06.2016 11:37не мазохисты, а придерживаются стандартов языка (как и в Javascript). И да, в некоторых случаях читабельность разбитых на визуальные блоки слов выше. Пробел был не зря придуман
ivan19631224
15.06.2016 12:05Ну, в обосновании этого пункта ни слова про стандарты языка, там лишь безапелляционная фраза «Это затрудняет чтение». Я считаю, что это спорное утверждение и не более чем вопрос привычки.
novrm
14.06.2016 13:02+1Эта особенность CSS — придумывать и помнить сотни способов для именования классов — просто убивает…
Особенно после изучения пространства имен, например в php.
hacke151
14.06.2016 13:02В 4 пункте в примере в css класс называется h3-like, а в html уже h3-title, это опечатка или так задумано и я что-то не понимаю?
virpool
14.06.2016 21:13Статья
местами, а вообще даже чуть менее, чем полностью, смахивает на откровенный стеб. У меня даже домен оригинального поста не резолвится :)SelenIT3
14.06.2016 21:28С сайтом автора действительно какая-то беда приключилась. Но кеш Яндекса пока всё помнит.
ViktorBurakov
14.06.2016 13:02В №1 перестарался для примера. Кто пэшкам() задаёт классы? Я конечно понимаю в чем суть и пользуюсь этим, но не стоит параграфу задавать класс для стилизации. Если конечно вы не «ТОП-верстальщик», который ни разу не интегрировал верстку с движками.
Sulin
14.06.2016 13:02+1Пункт 1.
почти в 100% случаев текстовые блоки будут вставляться через админку, через визуальный редактор, давая класс тегу нужно будет в визуальном редакторе открывать код и давать классы вручную всем тегам p или изменить код самого редактора что бы он сам давал класс всем тегам p. Крайне сомневаюсь в таком совете пораждающем куча неудобств только из-за прихоти давания класса тегу а не обращаться в css по самому тегу. Другое дело что для текстового блока должен быть отдельный родительский див с классом а не давать стили по тегу глобально.
Пункт 3.
название класс должно описывать сам элемент. если это логотип, то не имеет значения нарисовано на картинке круг или треугольник или ещё что. рисунок никак не должен влиять на название класса элемента.
пункт 10.
а это вообще валидно?
Lizard-108
14.06.2016 18:48Писать css руками в 21 веке — это деградация.
Alexufo
15.06.2016 12:27и ассемблер тоже деградация)
Lizard-108
15.06.2016 12:28При чем здесь ассемблер?
Alexufo
15.06.2016 12:30А деградация причем?) Никуда css не девался и никакие препроцессоры его не убивали
Lizard-108
15.06.2016 12:32Понятно что никуда не девался, просто я говорю о том что вообще его писать руками — это дурная практика тормозящая развитие человечества.
Aingis
15.06.2016 15:03Как же вы стилизуете сайты без CSS? Пустыми картинками как в 90-е? Что вы используете вместо border-radius? SASS, Less, Stylus и т.п. — это тот же CSS, только с плюшками.
psykeonfarm
14.06.2016 19:03+311. Используйте префикс 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 на дефисе останавливается, а на подчёркивание — нет. То же самое и с двойным кликом мыши, с подчёркиванием выделиться весь селектор, а без него — придётся делать дополнительные телодвижения.
jMas
15.06.2016 11:49+121. Не следуйте правилам
Скорей всего автор имел ввиду: «Не стоит слепо следовать всем этим правилам», потому что сейчас фраза несколько выпадает из контекста и кажется, что автор советует вообще отказаться от идеи следовать любым правилам (не только приведенным в статье) при работе с CSS/HTML, но скорей всего это не так.SelenIT3
15.06.2016 14:24+1Имхо, скорее имелось в виду что-то вроде «всегда думайте своей головой и доверяйте своему опыту». Какие-то советы могут быть хороши в 90% или даже 98% случаев, но всегда есть ненулевая вероятность, что на конкретном проекте у конкретного читателя встретится то самое исключение, где разумнее будет сделать ровно наоборот:)
Evgeny42
Хорошая инструкция. Всем кто только начинает, советую изучить ее и никогда так не делать.
vlreshet
Не могли бы обосновать? Я не придираюсь, мне правда интересно какие советы вредные, и почему так не стоит делать. Например, мне очень понравилась идея с js- префиксом.
s_berez
Ух, ох. В целом страдает аргументация и всё очень спорно, странно. Ваши советы действительно сослужат новичкам медвежью услугу примени они их буквально хотя-бы на 50%.
Приведу яркие примеры, чтобы не писать много.
— Про BEM. У нас достаточно большой проект и в нём верстальщиков >10. Больше всех ненавидят единственного применившего BEM. Из за него приходится писать LESS код, где селектор даже в виде исходника не поддаётся чтению, а уж во что он превращается после сборки!
— Какие кавычки брать, зависит от проекта.
— camelCase или через разделитель. Это сугубо проектная договорённость. Лишь бы все действовали в рамках договорённости установленной в самом начале.
— Сокращение это точно не зло, иногда без него селектор 3-4 уровня может превратиться в гигантское 100 символьное убожество.
— Про способы именования классов, способы селектить. По моему опыту, чем больше различных наворотов на тэге — тем сложнее будет селектор. Чем проще — тем лучше, незыблемая истина.
P.S.
Странно, что я не нашёл рекомендации использовать именно 3 пробела вместо табуляции.
reactoranime
Может два пробела?
s_berez
Лучше всего делать так, как принято на проекте. Может два, может три пробела, а может и табуляция.
dom1n1k
Проект проектом и тем не менее — во всех языках программирования/разметки де-факто есть предпочтительный стиль.
В js это кэмел, в питоне подчеркивания, в css дефисы. Так делается в абсолютном большинстве случаев.
Сделать в отдельно взятом проекте иначе можно, конечно, но смысл?
vintage
Например, чтобы не писать в js
mySuperPuperBlock(), в css.my-super-puper-block, а в инклудах/my/super/puper/block.dom1n1k
А это не проблема, это норма. Потому что каждое из этих написаний будет органично в своем контексте.
vintage
И вот из-за этой "нормы" программист не имеет простого способа переименовать компоненту, кроме редких случаев, когда IDE заточена под какой-либо фреймворк.
stcherenkov
Есть хорошее правило для решения этой проблемы: классы — для стилизации, дата-атрибуты — для скриптов.
Fetur
Правило 11 с использованием префикса -js очень удобно в работе, использовав его вы точно будете знать какой класс не надо трогать.
s_berez
Единственное бесспорно годное правило, с которым я согласен.
vintage
А я бы поспорил. Если вы до сих пор ищите элементы в доме по селекторам, вместо того, чтобы рендерить дом из дерева компонент, то ваша архитектура безбожно устарела. :-)
vlreshet
Не всем требуется стрелять из пушки по воробьям.
vintage
Ну да, некоторые привыкли с палкой за ними бегать. :-)