Comments 114
Хорошая инструкция. Всем кто только начинает, советую изучить ее и никогда так не делать.
UFO just landed and posted this here
Ух, ох. В целом страдает аргументация и всё очень спорно, странно. Ваши советы действительно сослужат новичкам медвежью услугу примени они их буквально хотя-бы на 50%.
Приведу яркие примеры, чтобы не писать много.
— Про BEM. У нас достаточно большой проект и в нём верстальщиков >10. Больше всех ненавидят единственного применившего BEM. Из за него приходится писать LESS код, где селектор даже в виде исходника не поддаётся чтению, а уж во что он превращается после сборки!
— Какие кавычки брать, зависит от проекта.
— camelCase или через разделитель. Это сугубо проектная договорённость. Лишь бы все действовали в рамках договорённости установленной в самом начале.
— Сокращение это точно не зло, иногда без него селектор 3-4 уровня может превратиться в гигантское 100 символьное убожество.
— Про способы именования классов, способы селектить. По моему опыту, чем больше различных наворотов на тэге — тем сложнее будет селектор. Чем проще — тем лучше, незыблемая истина.
P.S.
Странно, что я не нашёл рекомендации использовать именно 3 пробела вместо табуляции.
Приведу яркие примеры, чтобы не писать много.
— Про BEM. У нас достаточно большой проект и в нём верстальщиков >10. Больше всех ненавидят единственного применившего BEM. Из за него приходится писать LESS код, где селектор даже в виде исходника не поддаётся чтению, а уж во что он превращается после сборки!
— Какие кавычки брать, зависит от проекта.
— camelCase или через разделитель. Это сугубо проектная договорённость. Лишь бы все действовали в рамках договорённости установленной в самом начале.
— Сокращение это точно не зло, иногда без него селектор 3-4 уровня может превратиться в гигантское 100 символьное убожество.
— Про способы именования классов, способы селектить. По моему опыту, чем больше различных наворотов на тэге — тем сложнее будет селектор. Чем проще — тем лучше, незыблемая истина.
P.S.
Странно, что я не нашёл рекомендации использовать именно 3 пробела вместо табуляции.
Может два пробела?
Проект проектом и тем не менее — во всех языках программирования/разметки де-факто есть предпочтительный стиль.
В js это кэмел, в питоне подчеркивания, в css дефисы. Так делается в абсолютном большинстве случаев.
Сделать в отдельно взятом проекте иначе можно, конечно, но смысл?
В js это кэмел, в питоне подчеркивания, в css дефисы. Так делается в абсолютном большинстве случаев.
Сделать в отдельно взятом проекте иначе можно, конечно, но смысл?
Есть хорошее правило для решения этой проблемы: классы — для стилизации, дата-атрибуты — для скриптов.
Правило 11 с использованием префикса -js очень удобно в работе, использовав его вы точно будете знать какой класс не надо трогать.
20. При объявлении селектора в HTML придерживайтесь одиночных кавычек вместо двойных
Почему?
Присоединяюсь к вопросу, заранее не согласен с ответом.
Автор же объясняет:
но когда дело касается сотни селекторов в HTML-файле, одиночные кавычки — лучшая идея.
Почему лучшая идея? Вообще лучше придерживаться одного стандарта с кавычками в HTML.
Ну автор же даёт свои советы (видимо в его проектах это помогает), он же не призывает их использовать, о чём и пишет в последнем пункте. Если совет не подошёл, просто пропустите его, да и всё.
А вот странный у меня вопрос, а не пофиг ли? Ну оно понятно когда стандартно хорошо, а когда не стандартно, должно же быть плохо? Но как то до сих пор не слышно баталий по этому поводу, никто не страдает, слез не пускает. Вложенный в html атрибут типа data-html="" кусок html с теми же двойными кавычками никак не ломает парсер браузера. никто эти кавычки не видит кроме как в исходном коде… да и даже если видит особо не замечает. Проблем как то ни с js ни с чем то еще вроде бы и нет…
Насколько я помню, одинарные кавычки и двойные — одинаково стандартные. Использование двойных не более, чем традиция.
Хорошо, формально это традиция. Чем плоха эта традиция пока я так и не понял. То что «не традиция» — называется «дурным тоном». Так же как писать теги в ВЕРХНЕМ РЕГИСТРЕ. По спецификации HTML допускается вообще не использовать кавычки, но это так же дурной тон.
Возможно, автор имел в виду, что одинарные кавычки занимают меньше места визуально, и потому легче воспринимаются глазом. Если это так — то я разделяю его мнение. В HTML, правда, так и использую двойные, а вот в JS только одинарные.
Не всякая традиция — хороший тон (см. тж. http://css-live.ru/faq/zabluzhdeniya-razrabotchikov.html). Скорее уж бездумно отбрасывать годную возможность стандарта, потому что когда-то кто-то сказал, что это плохо, а проверить никто не удосужился — дурной тон:)
Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись — не потому, что «так положено», а потому, что это логичное техническое требование, прямо вытекающее из синтаксиса языка. У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.
Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись — не потому, что «так положено», а потому, что это логичное техническое требование, прямо вытекающее из синтаксиса языка. У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.
Не всякая традиция — хороший тонЯ не говорил, что всякая традиция — хороший тон.
Скорее уж бездумно отбрасывать годную возможность стандарта...
У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.
Вы сами с собой беседуете? Я писал конкретно про кавычки. По теме: освежите в памяти басню «Лебедь, щука и рак».
Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтисьДля любителей БЭМ это не проблема. Сделают новую тулзу, которая автоматом будет менять пробел на тройное нижнее подчеркивание… (полушутка)
Аргумент к традиции сам по себе очень слабый. И басня несколько мимо цели: направления движения одного воза с поклажей являются взаимоисключающими, но стиль кавычек для разных атрибутов — нет. Не шибко красиво, но работать будет.
Более того, вполне могу представить себе экстравагантное соглашение, чтобы функциональные атрибуты (
Не сделают. Не получится отличить следующий класс от следующего атрибута (особенно если в ходу кастомные).
Более того, вполне могу представить себе экстравагантное соглашение, чтобы функциональные атрибуты (
href, value, data-activated и т.п.) ограничивать двойными кавычками, а оформление (class) — одинарными. Чтобы принятая в команде IDE подсвечивала их по-разному и они сразу разделялись визуально. Признаюсь, при первом прочтении статьи я понял этот совет именно так:)Сделают новую тулзу, которая автоматом будет менять пробел на...
Не сделают. Не получится отличить следующий класс от следующего атрибута (особенно если в ходу кастомные).
Мне кажется что в HTML традиционно используются двойные кавычки т.к. это язык разметки текста в котором на английском языке довольно часто попадаются апострофы, для обозначения которых используются одинарные кавычки (напр. " She's great. Don't you think? ")
Поэтому чтобы не париться с постоянным экранированием апострофов — удобнее пользоваться двойными кавычками.
Визуально же одинарные кавычки меньше «рябят в глазах» когда их много, чем двойные. Думаю из этого и следует совет автора.
Поэтому чтобы не париться с постоянным экранированием апострофов — удобнее пользоваться двойными кавычками.
Визуально же одинарные кавычки меньше «рябят в глазах» когда их много, чем двойные. Думаю из этого и следует совет автора.
Для апострофа, который символ в тексте, есть специальный символ. Для кавычек в тексте, кстати, тоже (подробнее — habrahabr.ru/post/25531). Не надо путать символы для текста с символами для кода!
В пояснении к пункту:
> Это упрощает чтение документа.
Видимо, для автора так проще вычленить взглядом названия классов при беглом просмотре исходников.
> Это упрощает чтение документа.
Видимо, для автора так проще вычленить взглядом названия классов при беглом просмотре исходников.
В 19 примере часть кода утеряно или я что-то не понял? Объясните, пожалуйста, если все верно.
Я тоже люблю одинарные кавычки. Во-первых, с ними чище, во-вторых, не нужен shift при написании.
Отсюда у меня два вопроса:
1. Почему все не используют одинарные кавычки (в качестве «первых кавычек»)?
2. Откуда пошла мода на двойные? Чем они кавычнее одинарных?
Отсюда у меня два вопроса:
1. Почему все не используют одинарные кавычки (в качестве «первых кавычек»)?
2. Откуда пошла мода на двойные? Чем они кавычнее одинарных?
Потому что во всех учебниках и документации двойные.
я, например, в JS пишу
var html = '<div class="test">';
Насколько я понимаю, php проводит обработку текста внутри двойных, именно по этому "\s" выведет пробел, а '\s' — \s. Но не думаю, что стоит приплетать php к этому посту, тем более я считаю, что стоит html писать вне тела php скрипта.
php включает парсер для строк в двойных кавычках. Приплетать сюда php можно. Есть смысл из-за его особенности.
В нем при выводе html двойные кавычки уже заняты.
что лучше чем
А как то еще изворачиваться через sprintf как то… глупо.
В нем при выводе html двойные кавычки уже заняты.
<? $html .= "<div class='$variable'>Профиль</div>" ?>что лучше чем
<? $html .= "<div class=\"$class\">Профиль</div>" ?>А как то еще изворачиваться через sprintf как то… глупо.
Ну, люди не только на PHP веб делают:)
Эта особенность не только у PHP. К примеру, ей обладают те же Perl и Ruby.
Если пишешь на нескольких языках, то поневоле привыкаешь использовать правильные кавычки :)
Если пишешь на нескольких языках, то поневоле привыкаешь использовать правильные кавычки :)
В вашем примере лучше использовать конкатенацию. Хотя бы просто потому что беглого взгляда будет достаточно чтобы увидеть наличие переменной в строке. Не говоря о том что ваш вариант медленнее (хоть и не столь существенно)
Переменная огнем горит, если включена подсветка кода, что очень удобно. А когда нужно где то переменных от 10 вставить в html шаблон, конкатенация, мягко говоря, уменьшает читабельность в разы, добавляя еще один ряд кавычек с точками, по моим ощущениям.
Ха… а если посмотреть эти тесты, где конкатенация больше нескольких раз происходит, то выигрышь такой же небольшой выходит при разборе строки.
https://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html
Это 2012 год.
А при наличие опкеша с 5.5 вообще пишут разницы просто никакой.
https://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html
Это 2012 год.
А при наличие опкеша с 5.5 вообще пишут разницы просто никакой.
?><div class="<?=$class?>">Профиль</div><?php
Думаю, не стоит напоминать, что есть другие альтернативные способы положить строку в переменную или вывести в тело ответа.
Нет, "\s" не выведет пробел.
Думаю, исторически так сложилось. Ещё с языка C (может и раньше) строки кавычились двойными, символы – одинарными. Однако, в JS символы являются строками и разницы нет.
А я вообще использую Emmet и структура блоков раскладывается сама :)
Хорошая подборка советов, но 3 пункт вызывает недоумение.
Это какой-то антипаттерн. Зачем смешивать модель и представление? Если картинка в будущем изменится, придется переименовывать все стили под новый контент?
3. Не называйте класс по содержимому, если картинка нагляднее
Это какой-то антипаттерн. Зачем смешивать модель и представление? Если картинка в будущем изменится, придется переименовывать все стили под новый контент?
Есть некоторые отдельные случаи, когда автор будет прав.
Например, в рейтинге использовать класс .star, а не что-то более абстрактное типа .point или .mark
Хотя казалось бы — звездочки это чистой воды оформление и ничто не мешает завтра нарисовать там яблочки, сердечки или пальцы вверх.
Но де-факто если сказать человеку «звездочка» — он мгновенно понимает, о чем идет речь.
Например, в рейтинге использовать класс .star, а не что-то более абстрактное типа .point или .mark
Хотя казалось бы — звездочки это чистой воды оформление и ничто не мешает завтра нарисовать там яблочки, сердечки или пальцы вверх.
Но де-факто если сказать человеку «звездочка» — он мгновенно понимает, о чем идет речь.
Используйте префикс js-, если он используется только для JavaScript
В принципе, лучше чем без префикса, но можно использовать и свои атрибуты как в ангуляре.
Да и еще firefox показывает есть ли событие на элементе, помогает при чистке, по мне удобнее чем в хроме
довольно странно смотрится 20 пункт, когда в примерах статьи используются одинарные и двойные кавычки. В 6 примере вообще вперемешку одинарные и двойные кавычки. На сайте того же Predicsis используются двойные кавычки.
- Декомпозируйте свои шаблоны и стили на максимально компактные модули, и вам не придется страдать и постоянно выдумывать что-то для поддержания порядка в проекте.
Как разработчика, далекого от веба, меня всегда интересовало: а откуда пошла практика именовать селеторы в лисповой нотации «this-is-selector» вместо змеиной «this_is_selector»? Большинство текстовых редаторов воспринимают идентификатор с подчеркиваниями как одно слово, это довольно удобно.
Не БЭМом единым жив фронтендер. Есть множество различных методологий организации стилей. Каждая из них, как и БЭМ имеет свои плюсы и минусы, и хороши они в разных проектах. На проекте среднего уровня для меня лучшим выбором оказалась MCSS.
Будет полезно ознакомиться с каждой из них хотя бы поверхностно.
А вот остальные пункты из списка даже как-то противоречат конвенции БЭМ, ибо в данной методологии свои правила именования классов элементов блока, классов-модификаторов.
P.S. Про использование классов-пустышек с префиксом «js-» для манипулирования DOM-элементами посредством JavaScript чертовски верно подмечено!
Будет полезно ознакомиться с каждой из них хотя бы поверхностно.
А вот остальные пункты из списка даже как-то противоречат конвенции БЭМ, ибо в данной методологии свои правила именования классов элементов блока, классов-модификаторов.
P.S. Про использование классов-пустышек с префиксом «js-» для манипулирования DOM-элементами посредством JavaScript чертовски верно подмечено!
Да мёртвые они в большинстве. Я пытался с ними знакомиться в свое время.
BEM вот сразу понятен — ну во всяком случае базовые принципы и с какой стороны к нему подходить. А нюансы уже обкатываются на практике. Кроме того, BEM имеет слабую внутреннюю связность и потому гораздо терпимее прочих относится к смешению подходов.
Остальные… Читаешь, читаешь — вроде и улавливается какая-то логика, но чё с этим всем делать в реальности — непонятно. Вот у меня есть макет, как его верстать? Ни черта не ясно. OOCSS, SMACSS и MCSS в целом педалируют одну и ту же идею плюс-минус частные вариации. И она хоть и имеет определенную внутреннюю логику, но запутанная и сложно применимая в реальной практике. Автор MCSS, кстати, официально объявил, что рекомендует всем переходить на BEM. Atomic CSS вообще мертворожденная чушь.
BEM вот сразу понятен — ну во всяком случае базовые принципы и с какой стороны к нему подходить. А нюансы уже обкатываются на практике. Кроме того, BEM имеет слабую внутреннюю связность и потому гораздо терпимее прочих относится к смешению подходов.
Остальные… Читаешь, читаешь — вроде и улавливается какая-то логика, но чё с этим всем делать в реальности — непонятно. Вот у меня есть макет, как его верстать? Ни черта не ясно. OOCSS, SMACSS и MCSS в целом педалируют одну и ту же идею плюс-минус частные вариации. И она хоть и имеет определенную внутреннюю логику, но запутанная и сложно применимая в реальной практике. Автор MCSS, кстати, официально объявил, что рекомендует всем переходить на BEM. Atomic CSS вообще мертворожденная чушь.
Попробуйте суффикс -like для лучшей переносимости кода: .h3-like, .h3-title
какой-то странный совет привязываться к h3
Всегда пишите название класса прямо в HTML-элементе, для которого нужно оформление:<p class='paragraphly' />
Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?
.c-header-logo
а если такое же лого лежит в футере или где-то в контенте, я уже не смогу переиспользовать класс, получается?
.guillotine { /* О, сразу видно, что мы хотим стилизовать */ }
wut?
Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?
Смею предположить что имеються ввиду случаи не для текстовых блоков, например как для ссылок в меню и прочее
<nav class="menu">
<a class="menu-link" href="#">1</a>
</nav>
вместо:
<nav class="menu">
<a href="#">1</a>
</nav>
«wut?»
ну, там форма лого на нож гильотины похожа отдалённо
ну, там форма лого на нож гильотины похожа отдалённо
В случае с .c-header-logo думаю можно сделать так:
.c-header-logo, .c-footer-logo, .c-content-logo {… }
.c-header-logo, .c-footer-logo, .c-content-logo {… }
UFO just landed and posted this here
> 5. Не используйте верблюжийРегистр
> Это затрудняет чтение
Получается, большинство тех, кто пишет на Java — мазохисты?
> Это затрудняет чтение
Получается, большинство тех, кто пишет на Java — мазохисты?
Эта особенность CSS — придумывать и помнить сотни способов для именования классов — просто убивает…
Особенно после изучения пространства имен, например в php.
Особенно после изучения пространства имен, например в php.
В CSS тоже будут пространства имен.
В 4 пункте в примере в css класс называется h3-like, а в html уже h3-title, это опечатка или так задумано и я что-то не понимаю?
UFO just landed and posted this here
С сайтом автора действительно какая-то беда приключилась. Но кеш Яндекса пока всё помнит.
Оригинал статьи переехал на новый домен bdavidxyz.com.
В №1 перестарался для примера. Кто пэшкам() задаёт классы? Я конечно понимаю в чем суть и пользуюсь этим, но не стоит параграфу задавать класс для стилизации. Если конечно вы не «ТОП-верстальщик», который ни разу не интегрировал верстку с движками.
UFO just landed and posted this here
.some_class_name
мне кажется выглядит читабельней, чем
.some-class-name
мне кажется выглядит читабельней, чем
.some-class-name
И после таких статей, пишем статьи, как наши страницы стали в три раза тяжелее…
Писать css руками в 21 веке — это деградация.
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 на дефисе останавливается, а на подчёркивание — нет. То же самое и с двойным кликом мыши, с подчёркиванием выделиться весь селектор, а без него — придётся делать дополнительные телодвижения.
21. Не следуйте правилам
Скорей всего автор имел ввиду: «Не стоит слепо следовать всем этим правилам», потому что сейчас фраза несколько выпадает из контекста и кажется, что автор советует вообще отказаться от идеи следовать любым правилам (не только приведенным в статье) при работе с CSS/HTML, но скорей всего это не так.
Имхо, скорее имелось в виду что-то вроде «всегда думайте своей головой и доверяйте своему опыту». Какие-то советы могут быть хороши в 90% или даже 98% случаев, но всегда есть ненулевая вероятность, что на конкретном проекте у конкретного читателя встретится то самое исключение, где разумнее будет сделать ровно наоборот:)
Пост теряет всякий смысл своим 21-ым пунктом. Логически получается: «Думайте своей головой» но тогда слишком много пустой воды с очень простым советом.
Sign up to leave a comment.
Как называть css-классы