Frontender Magazine

Головокружительное погружение в БЭМ

«Что означают -- и __ в названиях ваших классов?» — один из самых часто задаваемых мне вопросов.

Ответом будет — спасибо БЭМ и Николасу Галлахеру


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

Важно отметить, что я использую систему именования основанную на БЭМ, но изменённую в соответствии с предложениями Николаса Галлахера. Система именования, освещаемая в текущем посте, это не оригинальный БЭМ, a улучшенная его версия, которая мне нравится больше. Тем не менее, в независимости от фактических изменений в обозначениях, улучшенная версия основана на тех же принципах БЭМ.

Система именования использует такой шаблон:

.block{}
.block__element{}
.block--modifier{}

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

.site-search{} /* Блок */
.site-search__field{} /* Элемент */
.site-search--full{} /* Модификатор */

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

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

.person{}
.person__hand{}
.person--female{}
.person--female__hand{}
.person__hand--left{}

Верхний блок это человек (.person), имеющий элементы, к примеру руки (.hand). Человек может быть разным, например женского пола (.female), и эта вариация, в свою очередь имеет свои элементы. Ещё раз, тоже самое, но записанное в «обычном» CSS:

.person{}
.hand{}
.female{}
.female-hand{}
.left-hand{}

Все эти классы имеют смысл, но выглядят несколько разобщёнными. Рассмотрим .female; к чему относится класс female? Что насчёт .hand? Может быть это дверная ручка или письменная? Используя БЭМ мы предоставляем разработчикам не только более подробную, но и более точную информацию; мы устанавливаем связи между элементами за счет одного только именования классов. Очень круто.

Давайте рассмотрим пример формы поиска на сайте ещё раз:

<form class="site-search  full">
    <input type="text" class="field">
    <input type="Submit" value ="Search" class="button">
</form>

Это обычные классы, по ним много не скажешь. Да, мы вполне можем так работать, но с БЭМ мы получим:

<form class="site-search  site-search--full">
    <input type="text" class="site-search__field">
    <input type="Submit" value ="Search" class="site-search__button">
</form>

Теперь видно, что у нас есть блок названный .site-search, у которого есть вложенный элемент .site-search__field. Также наглядно видно, что существует модификации блока .site-search имеющая свой собственный класс .site-search--full.

Давайте рассмотрим ещё один пример…

Если вы знакомы с OOCSS, то не возникнет трудностей и с абстракцией медиа объекта.

Обретая форму БЭМ, медиа объект выглядит так:

.media{}
.media__img{}
.media__img--rev{}
.media__body{}

Используя такой способ записи стилей, мы уже знаем, что .media__img и .media__body находят внутри .media и то, что .media__img--rev это небольшая модификация .media__img. И это информация полученная только по названиям селекторов!

Другим плюсом является ясность взаимосвязей внутри разметки. Рассмотрим пример с медиа объектом ещё раз:

<div class="media">
    <img src="logo.png" alt="Логотип «Рога и копыта»" class="img-rev">
    <div class="body">
        <h3 class="alpha">Добро пожаловать в компанию «Рога и копыта»</h3>
        <p class="lede">«Рога и копыта» — молодая, динамично развивающаяся компания</p>
    </div>
</div>

Из этого кода, мы никогда не сможем понять как классы .media и .alpha относятся к друг другу. Да и относятся ли? А что насчёт классов .body, .lede или .img-rev и .media? Из этого HTML кода невозможно представить, что есть компонент сам по себе, а что есть дополнительные элементы и опции. Если мы изменим код в соответствии с нотацией БЭМ:

<div class="media">
    <img src="logo.png" alt="Логотип «Рога и копыта»" class="media__img--rev">
    <div class="media__body">
        <h3 class="alpha">Добро пожаловать в компанию «Рога и копыта»</h3>
        <p class="lede">«Рога и копыта» — молодая, динамично развивающаяся компания</p>
    </div>
</div>

Теперь мы сразу видим, что .media — блок, а .media__img--rev элемент блока .media, этот элемент также имеет модификатор; ясно видно, что .media__body — неизменённый элемент блока .media. Вся картина взаимосвязей успешно складывается по именам классов. Это невероятно удобно и полезно.

Безобразный код

Одним из часто встречающихся аргументов против использования БЭМ является то, что он — уродлив; осмелюсь сказать, что если вы отказываетесь от использования кода, опираясь на то как он выглядит - вы просто не улавливаете сути. Если код тяжело читать и поддерживать и для этого нет достаточных оснований, то стоит задуматься, а стоит ли его использовать, но если код просто «выглядит странно», но если для этого есть веская причина, то стоит все взвесить, прежде чем от него отказываться

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

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

БЭМ’ить или не БЭМ’ить?

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

Тем не менее, при использовании БЭМ, важно помнить, что нет нужды использовать его повсюду, например:

.caps{ text-transform:uppercase; }

Этот CSS никогда не поместить в БЭМ методологию, это просто одиночное правило.

Еще один пример пример:

.site-logo{}

Это наш логотип; он может быть преобразован так:

.header{}
.header__logo{}

Но это необязательно. Фишка БЭМ’а в правильном распределении дочерних элементов. На самом деле не все вложенные элементы являются БЭМ элементами. В примере с шапкой сайта и логотипом, логотип находится в шапке, но это не мешает ему с легкостью оказаться в одной из колонок или в подвале сайта. Пространство имён БЭМ элемента может начаться в любом месте, поэтому будьте аккуратны и применяйте БЭМ только в тех местах, в которых он нужен.

Например:

<div class="content">
    <h1 class="content__headline">Можно предположить, что лемма проецирует…</h1>
</div>

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

Абсолютно всё готово к изменению под БЭМ. Рассмотрев пример с логотипом ещё раз, представьте, что вы хотите сделать праздничную версию логотипа для рождественского дизайна сайта. Мы можем сделать так:

.site-logo{}
.site-logo--xmas{}

Мы можем быстро создавать разные варианты, используя -- синтаксис модификатора.

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

Подведем итоги

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

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

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом Антону Немцеву в skype ravencry.

Harry Roberts
Автор:
Harry Roberts
Сaйт:
http://csswizardry.com/
Twitter:
@csswizardry
GitHub:
csswizardry
Владимир Старков
Переводчик:
Владимир Старков
Сaйт:
http://iamstarkov.com
Twitter:
@iamstarkov
GitHub:
iamstarkov

Комментарии (38 комментариев, если быть точным)

Автар пользователя
mistakster

Оригинальный синтаксис .block__element_mod-type_mod-value мне нравится больше. Знаки подчёркивания хорошо выглядят. Их проблема только в выделении по даблклику на слове. Я не видел ни одного редактора или IDE, который бы правильно установил выделения.

Поделюсь ссылкой ещё на одну статью про вёрстку независимыми блоками. БЭМ — это совсем не страшно. Да, больше букв, но зато меньше проблем с обслуживанием.

Кстати, в таких статьях, чаще всего, вообще не затрагивается вопрос БЭМ-ификации пользовательского контента. Мне нравится, когда и контент, написанный пользователем, оформляется с помощью простых селекторов. Тут без автоматических фильтров не обойтись. Но это совсем не проблема, я считаю. После WYSIWYG-редакторов разметку всё равно нужно валидировать. Markdown, Wiki, BBCode и другие разметки и так проходят пост-обработку. В этот цикл можно встроить добавление простых селекторов тегам. И нейминг у них можно организовать в стиле БЭМ.

Автар пользователя
omgovich

Допустимо ли использование подобных селекторов: «.person--female__hand»? Я не встречал ни в одной статье про концепцию незвисимых блоков. На сколько я знаю используются подобные каскадные конструкции: «.person--female .person__hand»

Автар пользователя
omgovich

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

Автар пользователя
SilentImp

Мои извинения. Разные интерпретаторы разметки на сервере и клиенте. Исправим и сведем поведение к единообразному.

Автар пользователя
Yvelious

Оригинальная BEM-методология нравится больше. Насколько я помню, модификатор не может отдельно существовать от модифицируемого блока или элемента. А в этих примерах может class="media__img--rev".

Автар пользователя
rohozhnikoff

Тогда это не модификатор. Это абстрактный класс (g-, i- префиксы в БЭМе).

Автар пользователя
tadatuta

У оригинального формата модификаторов есть несколько плюсов: 1. Можно выразить модификаторы в терминах что модифицируем и в какое значение. Скажем, у нас есть логотип, который бывает разных размеров и с разной темой (новогодний, к 8 марта и т.д.): logo_size_big, logo_size_small и logo_theme_new-year, logo_theme_8march. 2. Модификаторы можно передать с помощью xml или json (например, и { block: 'blockName', mods: { modName: 'modVal' }}). 3. Отсюда вытекает и дополнительное удобство при работе с модификаторами из js: мы можем получить текущее значение нужного модификатора вместо того, чтобы проверять начилие из списка (да и не всегда этот список есть заранее). 4. При разнесении файлов по файловой системе, разные значения одного и того же модификатора удобно класть в общую папку. 5. Если когда-нибудь вы захотите применить у себя на проекте bem tools (http://ru.bem.info/tools/bem/), такая нотация будет работать из коробки.

Автар пользователя
LostSenSS

mistakster, да с выделением в редакторах проблема :/ Вебшторм, например, разбивает слово по дефисам.

Omgovich, Yvelious, да, тоже очень удивили эти моменты. Противоречат же самой сути системы.

Автар пользователя
MrFranke

А если добавить немного LESS-a в эту систему, то писать стили будет очень удобно:

.header{ &__logo{} }

Автар пользователя
jmas

Сам метод БЭМ достаточно противоречив.

Авторы, которые восхваляют данный стиль именования CSS классов зачастую оперируют такими абстрактными понятиями, как изящный, прозрачный и так далее. Понять какой код изящней, а какой нет - пожалуй можно только увидев код, на порядок изящней текущего. И что я скажу: мне кажется, что код записанный традиционными классами + оперируя традиционным наследованием выглядит гораздо изящней, чем код написанный с применением БЭМ.

Конечно же это мое субъективное мнение.

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

Хорошо, но это не проблема лежит не в плоскости классов - это проблема лежит в плоскости понимания программистом контекста.

Да и допустим, чем не понятна следующая конструкция:

.person .hand {}

.person .female{}

.person .female-hand{}

.person .left-hand{}

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

Я склоняюсь к использованию lessCss, который призван решать подобные проблемы, а не пробовать заставить программистов тащить контекст в каждом селекторе.

Автар пользователя
kizu

@jmas БЭМ решает в том числе (или, может, и в первую очередь) и проблему независимости стилей — если вложить руку мужчины в руку женщины, то при написании стилей каскадом обе руки станут женскими — так как и к мужской руке применятся соответствующие стили.

Автар пользователя
jmas

``` html

```

.a .b { } .c .b { }

html <div class="a"> <div class="b of-a"></div> <div class="c"> <div class="b of-c"></div> </div> </div>

.a .b.of-a { } .c .b.of-c { }

Почему нельзя разруливать таким образом?

Автар пользователя
tadatuta

@jmas еще важный момент — БЭМ не только про CSS, он весь проект целиком: js, шаблоны и даже серверный код.

Автар пользователя
jmas

@tadatuta Я готов поддержать дискуссию, так как хочу вывести истину. Привязываться к классам в JS? А как насчет привязки к [data-param], так мы вообще избавляемся в JS от CSS-зависимостей.

Насчет шаблонов ничего не слышал - подскажите в чем суть.

Автар пользователя
kizu

Почему нельзя разруливать таким образом?

Потому что в этом случае вы и получаете лишние классы, только вместо одного длинного вы получаете два класса: и короткий и длинный :)

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

Автар пользователя
jmas

@kizu Хорошо, что мешает изначально писать:

html <div class="something-list"> <div class="item of-something"></div> </div>

Подчеркиваю, изначально.

Я понял, что суть БЭМ - просто заставить людей писать изначально длинные имена, описывающие контекст, но сама запись получается совсем не-элегантная, ИМХО.

Автар пользователя
tadatuta

@jmas Немного из рубрики «Срываем покровы». На самом деле БЭМ полне может обходится вообще без классов. Например, опираясь на кастомные теги. Основные идеи БЭМа в том, что: 1. Блоки не зависят друг от друга 2. Блоки реализуют некую объектную модель, а-ля ООП, с наследованием, миксинами, до- и переопределением свойств (эти свойства блоков проявляются консистентно как для css, так и для js, шаблонов и серверного кода) 3. Блоки первичны, технологии вторичны (css, js, шаблоны, документация, картинки и пр. лежат в одной папке, при реиспользовании блока не нужно собирать его потраха по всей файловой системе) 4. Реализация блоков в любой технологии позволяет общаться в общих терминах. js-разработчик, говоря о блоке my-awesome-block будет говорить именно о том самом блоке, о котором знает и верстальщик и бекендер

Про шаблоны в БЭМ-терминах можно подробно прочитать тут: http://ru.bem.info/articles/bemhtml-rationale/

Автар пользователя
kizu

@jmas Во-первых, я не вижу чем item of-something элегантнее something__item. Если же эта сущность может существовать и без something, то это должен быть блок, но если эта часть каким-то образом модифицируется от something, то железобетоннее смиксовать это дело так: item something__item.

Мультиклассы типа .b.of-c имеют несколько проблем: 1. Не работают в IE6, но это не существенно для большинства сайтов, конечно же. 2. В нормальных браузерах работают медленнее, чем селектор по одному классу, это не так существенно для маленьких сайтов, но всё же. 3. Самое главное — это мешает миксованию. Что, если мы захотим сделать один блок-микс из a и c, а элементом будет микс из b и d? Тут без явного прописывания зависимости конкретного элемента от конкретного блока не получится. Я сходу сейчас конкретный пример такого конфликта не приведу, но на моей практике подобные случаи были частенько.

Автар пользователя
jmas

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

Хорошо, есть такие вещи как lessCss или промежуточные процессоры, которые перегоняют "расширенный CSS" в валидный и браузероугодный CSS.

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

Автар пользователя
kizu

Less и ему подобные не решают эту проблему (хотя я бы тут поспорил с тем, что это проблема — написание длинных классов может быть упрощено тысячей способов, начиная от фильтра в Emmet, который там есть из коробки, заканчивая любыми кастомными рещениями).

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

Использование вложенности для препроцессоров часто добавляют лишних проблем — как с читаемостью кода, так и с его нахождением. Частично эту проблему решают source maps, но не целиком (поиском и грепом сложнее будет найти нужный селектор).

Ещё раз: я не вижу проблемы в длинных именах классов и даже работая над промо-страницами и «домашними сайтами для котиков» я всегда видел только плюсы от БЭМ-нотации и АНБ-подхода. Все отступления от них сразу же вызывали те или иные проблемы с поддержкой. Да, они могут быть незначительны, вроде переименования классов или изменения структуры CSS, но они будут. К длинным классам легко привыкнуть, при этом если не нравятся конкретный синтаксис, то его легко подогнать под себя — хотя использовать кемелкейс для названий блоков, а элементы писать через дефис, это не важно.

Автар пользователя
slaffko1

Я так понимаю использование препроцессоров при с БЭМ теряет эффективность. Т.е. нельзя использовать вложенные классы

Автар пользователя
iamstarkov

Суть препроцессоров не в вложенных селекторах, а в облегчении рутины и тут они выполняют свою миссию вполне хорошо, и также они вполне отлично уживаются с БЭМ.

PS. Каскад не следует использовать безотносительно БЭМ и препроцессоров в любом случае

Автар пользователя
panych

Почему нельзя использовать data атрибуты для модификаторов: <h1 class="title" data-color="grey">? Есть же доступ как из js, так из css.

Автар пользователя
iamstarkov

кто сказал, что нельзя? можно.

почему это не предложено в концепции, это уже другая история, имеющая некоторые причины: 1. на момент создания методологии не существовало дата-аттрибутов; 2. селектор дата-аттрибута вкупе с исходным классом (.block__elem[data-modName=modVal]) приведут к большей специфичности чем селектор по одному классу-модификатору (.block__elem_modName_modVal), что может вызвать проблемы.

Автар пользователя
Yvelious

А что там со скоростью рендеринга дата-атрибутов относительно классов?

Автар пользователя
MrFranke

Не думаю это самая актуальная проблема для современных браузеров.

18 декабря 2013 г., 14:22 пользователь Stas Levyshev < notifications@github.com> написал:

А что там со скоростью рендеринга дата-атрибутов относительно классов?

Reply to this email directly or view it on GitHubhttps://github.com/FrontenderMagazine/MindBEMding/issues/1#issuecomment-30830675 .

Отправлено с Dendy

Автар пользователя
panych

@matmuchrapna вторая причина не критична: обычно модификатор и так должен перекрывать дефолтные стили. Зато доступ в js из коробки есть (jQuery тут помогает). Пока вижу только плюсы.

Автар пользователя
iamstarkov

обычно модификатор и так должен перекрывать дефолтные стили

всё верно, покуда у тебя не возникнет потребность перекрыть модификатор селектором из одного класса на другом уровне переопределения. Допустим, ты подключил библиотеку блоков со всеми их модификаторами в начало таблицы стилей, а затем хочешь переопределить этот блок на какой-то определённой странице — в этом случае ты не сможешь использовать в переопределении селектор из одного класса, так как специфичность селектора модификаторов будет ставить тебе палки в колёса.

В итоге, специфичность — зло и предложенная модель для модификаторов это бомба замедленного действия для самого себя

Автар пользователя
panych

В голову пока пришло два примера: 1. <button class="btn">Click me! <i class="btn__ic lib-ic" data-icon="info"></i></button>

Здесь вроде все не так плохо. Все, что будет в .lib-ic[data-icon="info"] в теории не должно пересекаться с .btn__ic. 1.

<div class="gal"> <div class="gal__col lib-col" data-pos="left"></div> <div class="gal__col lib-col" data-pos="right"></div> </div>

Тут уже в разы хуже: скорее всего нужно будет перекрывать стили.

Так же всплыла другая проблема - конфликт модификаторов. Непонятно к какому блоку отноститься data-pos. Можно, конечно, писать как-то так: data-lib-col-pos, но тогда выигрыша сравнительно "классической" записи почти нет.

Еще одна проблема с этим подходом - меньшая производительность селекторов.

Автар пользователя
iamstarkov

Здесь вроде все не так плохо. Все, что будет в .lib-ic[data-icon="info"] в теории не должно пересекаться с .btn__ic.

увеличилась специфичность — что-нибудь взорвётся

а второй аргумент я не понял

Автар пользователя
iamstarkov

Зато доступ в js из коробки есть (jQuery тут помогает). Пока вижу только плюсы.

Попробуй i-bem, ещё захочешь =)

Автар пользователя
nikbelikov

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

Автар пользователя
OlegZavrazhin

Удобство БЭМ (на русский манер) очевидно. Но есть вопрос, именно в контексте данного решения: может ли блок содержать в себе другие блоки, но относящиеся к своему родительскому? Если да, так им присваивать названия?

Автар пользователя
mistakster

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

Например, есть список.

<ul class="products"> <li class="products__item"> <div class="product">...</div> </li> </ul>

Элементы, которые относятся к блоку products, задают расположение блоков product, но не их оформление. Так товары могут в одном месте располагаться плитками, в другом — в одну колонку. А вот само оформление товара уже описывается в product. Прелесть БЭМ в том, что я могу блок поместить куда угодно (в разумных пределах, конечно) и он не должен ломаться от этого.

Я не исключаю вариант, когда products__item и product можно разместить на одном DOM-узле. Сам так делаю регулярно. Но, как показывает практика, удобнее в поддержке оказываются решения, где элементы и блоки разнесены по разным DOM-узлам. Мы в компании начали активно использовать CSS-свойство all: initial для обнуления стилей блока. Из-за этого, совместное использование становится очень затруднительным — блок обнуляет стили элемента, приходится поднимать специфичность селектора элемента и т.п.

Автар пользователя
OlegZavrazhin

Я немного не так выразился наверное, сейчас на примере.

<header class="header"> <div class="header-top"> <div class="header-top__logo"></div> <ul class="header-top__menu"></ul> </div> <div class="header-bottom"> <div class="header-bottom__phone"></div> <ul class="header-bottom__menu"></ul> </div> </header>

Вот header-top и header-bottom - это блоки внутри блока или элементы этого блока?

Автар пользователя
mistakster

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

Автар пользователя
panych

Вот header-top и header-bottom - это блоки внутри блока или элементы этого блока?

По вашей записи получается, что отдельные блоки.

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

``` jade // jade header.header div.header__top div.header__logo div.header__top-menu ul.top-menu // или ul.header-top-menu если хочется логически привязать к хедеру

div.header__bottom div.header__phone div.header__bottom-menu ul.navigation ```

Автар пользователя
mydack

Пролапатив весь топ выдачи гугла по БЭМ, не смог полюбить его и тем более понять. Помогите мне, пожалуйста. Насколько я понял одной из целей БЭМ, создание независимых блоков. Значит ли это, что для блока с текстом нужно задавать все стили для текста. Его начертание, цвет, размер, чтобы блок был поистине независимым?