Comments 61
В ссылки раздела по БЭМ стоит добавить еще и http://getbem.com
Зачем? Беминфо поддерживает большое количество яндексоидов, а гетбем — всего два, причем последнее крупное обновление было больше 3-х месяцев назад.
Спасибо за уточнение, не о знал об этом. Просто getbem мне кажется более лаконичным и удобным.
UFO just landed and posted this here
Спасибо, что собрали в одном месте.
Спасибо, очень полезная информация. Особенно для тех, кто только начинает программировать с помощью css.
Думаю, что слово «программировать» немного неуместно.
Виноват, согласен.
UFO just landed and posted this here
SASS, LESS пробовал. Они скорее в некоторой мере упрощают написание кода и помогают легче взаимодействовать с тем же PHP либо другими средствами. Да в них есть циклы, уловия, переменные, функции. При правильном подходе заменяют некоторую часть JS. Но не думаю что это прям программирование. Хотя есть много чего схожего.
Пожалуй, самая популярная сейчас методология вмиреЯндексе. Название означает «Блок, элемент, модификатор».
Fixed.
Вы подозреваете автора в предвзятости? Он, в общем-то, прав, BEM действительно невероятно популярен в мире.
Хорошо, я согласен пересмотреть свою точку зрения. Только давайте разберёмся, какие топовые мировые ресурсы сделаны по этой методологии?
«Невероятно популярен» — это не «про это пишут статейки с кучей лайков для профильной аудитории», а «на этом работает Твиттер и Фейсбук».
«Невероятно популярен» — это не «про это пишут статейки с кучей лайков для профильной аудитории», а «на этом работает Твиттер и Фейсбук».
Вот вам пример из разметки твиттера =)
А вообще, БЭМ — очень общая система, позволяющая значительно упростить поддержку кода, поэтому используется сейчас в том или ином виде очень широко.
Картинка
А вообще, БЭМ — очень общая система, позволяющая значительно упростить поддержку кода, поэтому используется сейчас в том или ином виде очень широко.
Все хорошие верстальщики верстают так, без всяких соглашений, статей и прочего. Еще до появления БЕМ в яндексе. Собственно, как он по вашему появился то? Яндексу спасибо, за популязацию метода среди тех верстальщиков которые так не делали. С таким же успехом это мог быть и Гугол, и Твиттер и кто угодно, кто звучит авторитетно.
>> Собственно, как он по вашему появился то?
Насколько я знаю (возможно, ошибаюсь), методология «вёрстки независимыми блоками» была сформулирована именно в Яндексе (Виталием vithar Харисовым). А уже на её основе построили БЭМ.
Насколько я знаю (возможно, ошибаюсь), методология «вёрстки независимыми блоками» была сформулирована именно в Яндексе (Виталием vithar Харисовым). А уже на её основе построили БЭМ.
История создания БЭМ: ru.bem.info/method/history
По поводу «Все хорошие верстальщики верстают так, без всяких соглашений, статей и прочего». В 2005 это было не так.
Сейчас каждый школьник знает, что Земля круглая, а когда-то это знание стоило жизни.
По поводу «Все хорошие верстальщики верстают так, без всяких соглашений, статей и прочего». В 2005 это было не так.
Сейчас каждый школьник знает, что Земля круглая, а когда-то это знание стоило жизни.
Однако автор статьи считает это плохой практикой (каждый раз, когда в стилях появляется id селектор, где-то в мире грустит котенок). Используйте классы и будет вам счастье.
Надо было раскрыть тему, хотя бы поверхностно
По поводу написания css в целом и использование id в css в честности есть очень хорошее руководство: http://cssguidelin.es/
Описанные в статье способы организации css-кода там так-же рассматриваются.
Описанные в статье способы организации css-кода там так-же рассматриваются.
Спасибо за ссылку, но я её конкретизирую — cssguidelin.es/#ids-in-css.
Как я понял из нее, самая большая проблема использования id в css — селектор становится СЛИШКОМ специализированным и уже ничем не перебить установленные таким образом свойства.
Так же я слышал, что и в html использовать id тоже плохо. Правда, ни разу не получал ответа почему. Раз уж пошла такая пьянка, не просвятите?
Как я понял из нее, самая большая проблема использования id в css — селектор становится СЛИШКОМ специализированным и уже ничем не перебить установленные таким образом свойства.
Так же я слышал, что и в html использовать id тоже плохо. Правда, ни разу не получал ответа почему. Раз уж пошла такая пьянка, не просвятите?
Так же я слышал, что и в html использовать id тоже плохо. Правда, ни разу не получал ответа почему. Раз уж пошла такая пьянка, не просвятите?
Первый раз такое слышу. А как тогда заставить работать anchor в пределах страницы? А javascript? :)
На сколько я понимаю вопрос, «плохо» не просто использовать id, а использовать его не по назначению. Если в css-файле появился селектор с id, это не катастрофа, это сигнал о том, что глобальная модель css-правил не оптимальна.
На сколько мне известно, использование id или class влияет на поиск элемента в DOM и соответственно на производительность. Так как предполагается, что id уникален в пределах документа, то при поиске по id, браузер останавливает поиск как только находит нужный элемент, а при поиск по классу он производит поиск пока не проверит все элементы в DOM, даже если нужный элемент был единственный, и найден в самом начале. Поэтому использовать нужно и то и другое, в зависимости от ситуации.
Проведите простой эксперимент: сделайте на одной странице несколько элементов с одним id и примените к этому id какой-нибудь стиль. Результат не шокирует, но спойлерить не буду.
Проведите простой эксперимент: ознакомьтесь со спецификацией и не занимайтесь тем, что ей настолько сильно противоречит.
Ваш совет равносилен предложению снять с автомобиля три колеса из четырех и на основании этого утверждать, что использование колес в автомобиле в принципе — крайне плохая практика.
Ваш совет равносилен предложению снять с автомобиля три колеса из четырех и на основании этого утверждать, что использование колес в автомобиле в принципе — крайне плохая практика.
А вы, как я погляжу, любитель развести спор на пустом месте, да? Мой комментарий вообще никаким боком не относится к допустимости или недопустимости использования id в css. Вот вообще. Никак. Абсолютно. На 146%.
Мой комментарий был ответом — и только ответом — на комментарий VitaliiDel, озвучившего предположение о том, что браузер обрабатывает стили для id только для первого найденного элемента с соответствующим id. Я предложил провести элементарный эксперимент для того, чтобы убедиться, что это не так, и браузер обработает все элементы с соответствующим id, сколько бы их не было, будь это хоть трижды нарушением каких бы то ни было спецификаций.
Мой комментарий был ответом — и только ответом — на комментарий VitaliiDel, озвучившего предположение о том, что браузер обрабатывает стили для id только для первого найденного элемента с соответствующим id. Я предложил провести элементарный эксперимент для того, чтобы убедиться, что это не так, и браузер обработает все элементы с соответствующим id, сколько бы их не было, будь это хоть трижды нарушением каких бы то ни было спецификаций.
Мне кажется, обзору крайне не хватает RSCSS.
С примерами кода было бы лучше.
Спасибо за статью, как раз стоит задача организации css кода.
а за пример
отдельное спасибо, не знал, что так можно =)
а за пример
.block {
&-element {...}
}
отдельное спасибо, не знал, что так можно =)
потом замучаешься в ide искать нужную css-ку, особенно если приходится поддерживать чужой код и его много
Для этого существую map-файлы
Ну вообще в БЕМ достаточно точно определена файловая структура, так, что зная css класс можно легко найти и файл где этот класс описан
это в идеальном мире достаточно точно определена файловая структура, а бывает что человек просто увидел возможность писать код так и пишет, а следующий за ним разработчик испытывает массу неудобств, когда не может обычным поиском в проекте найти нужный кусок кода
Если вы выбираете какою-либо методологию для разработки проекта, то все кто этот проект пилят, сначала знакомятся с ней, а уже потом начинают работать над проектом. В принципе в этом главный плюс любой методологии — единый стиль для всех.
Добавьте к этому код-ревью(чтобы избежать отклонений от методологии) и вы получите ваш «идеальный мир».
Добавьте к этому код-ревью(чтобы избежать отклонений от методологии) и вы получите ваш «идеальный мир».
вы встречали такие проекты в своей практике, т.е. не проекты где вы в одиночку пилите интернет магазин, а проекты где над кодом поработало много разных людей, у которых разные методологии в голове были и вот вам такой проект достался в наследство? у одного 5 лет назад была методология ХРЕН, у второго БЭМ и вы получили ХРЕН-БЭМ, умаешься там искать нужные селекторы
UFO just landed and posted this here
Постоянно ловлю себя на мысли, что сталкиваюсь с проблемами которые легко можно бы было решить используя БЭМ. Но от него отталкивает как раз то, что БЭМ фактически убивает каскадность.
Сам использую нечто похожее на SMACSS.
А вот за атомарный CCS ни раз хотелось уже убить.
Сам использую нечто похожее на SMACSS.
А вот за атомарный CCS ни раз хотелось уже убить.
Каскадность сильно мешается при изменении html-разметки. Считайте, что БЭМ привносит каскадность в понятиях «блок-элемент», без привязки к HTML.
Например,
b-article, b-article-title, b-article-content, b-article-controls и т.д. Каскадность видна невооружённым глазом, однако изменение html-разметки, в данном случае, никак не повлияет (конечно, при сохранении нужных имён классов).
Например,
b-article, b-article-title, b-article-content, b-article-controls и т.д. Каскадность видна невооружённым глазом, однако изменение html-разметки, в данном случае, никак не повлияет (конечно, при сохранении нужных имён классов).
Иногда атомарный css очень в тему. Допустим, есть классы иконок ico-accept, ico-decline… Чтобы добавить иконку в коде просто делаешь блок с этим классом. Но в каждом случае еще нужно задать размер иконки. Приходится добавлять еще класс, селектор в стили, и там прописывать размер. Либо сделать проще — один раз определить набор классов size-16, size-18, size-20… и тогда иконки можно полностью определять в html.
<div class="ico-accept size-16" ></div> Очень упрощает жизнь.
А я вот не согласен, что это атомарный стиль. Да он называется КАК атомарный. Да он содержит одно правило КАК атомарный. Но его смысл иной. Сделать иконку подходящей под левую панель. Вот и назвать его надо ico-leftpanel
И если завтра всем этим иконкам понадобиться еще и отступ слева, мы смело добавим в этот стиль margin и он не перестанет соответствовать названию.
Все дело в том, что в данном случае стиль несет адаптационное изменение, и только то, что случайным образом оно пока одно, делает его похожим на атомарный.
И если завтра всем этим иконкам понадобиться еще и отступ слева, мы смело добавим в этот стиль margin и он не перестанет соответствовать названию.
Все дело в том, что в данном случае стиль несет адаптационное изменение, и только то, что случайным образом оно пока одно, делает его похожим на атомарный.
Если мне понадобится добавить специальные отступы для иконок панели, я естественно добавлю класс left-panel и пропишу его там. Классы size-16 и т.д. всегда строго содержат размер и ничего больше. В этом суть атомарности. Просто, чаще всего не нужно ничего, кроме иконки и размера.
В этом случае атрибут style всегда к вашим услугам. Чем хуже его использование чем использование атомарных классов?
Вот чем лучше:
Содержимое атрибута всегда соответствует своему содержимому, в то время как в классе size-16 может быть задано черт знает что.
Не надо возиться с двумя файлами.
Стиль применяется мгновенно.
А минусы есть?
Вот чем лучше:
Содержимое атрибута всегда соответствует своему содержимому, в то время как в классе size-16 может быть задано черт знает что.
Не надо возиться с двумя файлами.
Стиль применяется мгновенно.
А минусы есть?
Вот и назвать его надо ico-leftpanel
Вот только завтра приходит дизайнер и переносит вашу левую панель на право, а ваши иконки по прежнему содержат в себе leftPanel
А то что завтра придет дизайнер и изменит размер с 16 на 20, а у вас так и останется класс size-16 вас значит не волнует?
Подразумевается, что заменят size-16 на size-20 в html. Если кто-то в классе size-16 напишет 20px, ему можно смело отрывать руки: )
Точно так же заменим класс на правильный ;)
Вопрос был задан с целью навести на мысль, что для size-16 замена класса как бы исподволь предполагается, а для ico-leftpanel замена класса по умолчанию запрещена. После чего мне задается пишется нечто вроде «Твой класс плохой потому, что я сказал, что не буду его менять и поэтому не буду его менять. Видишь — я не могу его заменить.»
Вопрос был задан с целью навести на мысль, что для size-16 замена класса как бы исподволь предполагается, а для ico-leftpanel замена класса по умолчанию запрещена. После чего мне задается пишется нечто вроде «Твой класс плохой потому, что я сказал, что не буду его менять и поэтому не буду его менять. Видишь — я не могу его заменить.»
Похоже, БЭМ претендует на нечто большее, чем просто организация CSS. Со своими библиотеками это больше Transform View паттерн. Видимо, противоположное популярным сейчас фреймворкам вроде Angular, Backbone и др.
Про MCSS и читал, и видео докладов на конференциях смотрел — но не понимаю.
Вроде бы и логично рассказывает, и какая-то нить прослеживается, но как доходит до практики — ступор. Что делать, как верстать, почему мне это должно быть удобно?
Неинтуитивная система.
БЭМ как-то сразу понятен — ну, во всяком случае основы. И сразу примерно понятно куда двигаться и что делать.
Конечно, со временем всплывают нюансы и тонкие моменты, но это уже дело техники.
Вроде бы и логично рассказывает, и какая-то нить прослеживается, но как доходит до практики — ступор. Что делать, как верстать, почему мне это должно быть удобно?
Неинтуитивная система.
БЭМ как-то сразу понятен — ну, во всяком случае основы. И сразу примерно понятно куда двигаться и что делать.
Конечно, со временем всплывают нюансы и тонкие моменты, но это уже дело техники.
Sign up to leave a comment.
Способы организации CSS-кода