Вводная часть

У CSS есть несколько базовых проблем, которые позволяют очень быстро отстрелить себе ногу при неправильном использовании:

  1. Глобальный неймспейс – в серверном программировании все что написано в файле, в файле и остается. Все же что написано в css и js засирает глобальное пространство имен со всеми вытекающими. В JS эту проблему сейчас побороли всякими модульными системами, а вот с css сложнее. В идеальном мире это должен починить Shadow DOM и настоящие Web Components, но пока их нет единственный способ с этим бороться – следовать какой-то системе именований селекторов, которая по возможности уменьшает и исключает возможные конфликты.

  2. Каскадность – если на один элемент может сработать несколько правил, то они все и сработают последовательно. Если есть элемент h1.title, на него сработают все правила для тегов h1 и все правила для класса .title. Так как весь html состоит из тегов, то правил которые применяются на теги без классов будут работать на все вообще.

Соответственно назначать или переназначать стили у тегов – это примерно то же самое, что править прототипы объектов в JS, чем в свое время печально славился Prototype.js. Эти стили унаследует вообще все объекты и если их потом захочется поменять, то результат будет такой же, как если ты решил в прототипе объекта поменять результаты какого-то метода, который используют все дети этого объекта. Вероятность что-то сломать почти 100%.

  1. Вложенные селекторы. Можно написать селекторы .nav .item {...} и .menu .item и .item в зависимости от места вывода будет показываться по-разному. Все хорошо пока тебе не нужно поместить блок menu внутрь блока nav. Тогда сайдэффекты становятся совершенно непредсказуемые. По сути аналог вложенных селекторов из программирования – это функция которая в зависимости от места где её вызывают, выдает разный результат. Например в одном месте sum(2,2) может возвращать 3, а в другом 5.

Зачем нужны методологии

Хорошая методология занимает предотвращением этих проблем. Покажу как это делает БЭМ, но CSS Modules, Polymer или всякие решения с инлайновыми стилями для Реакта тоже решают именно их, только другим способом.

Как именование классов по БЭМу помогает решать эти проблемы:

  1. БЭМ запрещает применять стили на теги, максимум ресет. На id тоже нельзя, потому что такие элементы нельзя на странице использовать 2 раза, а сколько раз он тебе понадобится ты не всегда знаешь заранее. Все стили можно применять только к классам.
  2. БЭМ создает для всех компонентов глобальный неймспейс – все классы которые относятся к компоненту начинаются с одного префикса. Это позволяет исправить второй пример таким образом: .nav__item, .menu__item. Если один вложить в другой не будет конфликта правил.
  3. Под каждый компонент в БЭМ создается своя папка – это защищает тебя от конфликтов в именах компонентов и при правильном использовании дает гарантию, что в глобальном неймспейсе будет только один компонент с таким префиксом.
  4. В БЭМ есть только один вид вложенных селекторов: модификатор > элемент. Оба начинаются с одного префикса, оба живут в одном файле, оба никак не влияют на другие компоненты.

Что делает Bootstrap

Bootstrap нарушает КАЖДОЕ из этих правил:

  1. Bootstrap переназначает стили тэгов.
  2. Bootstrap в куче случаев меняет способ отображения элемента в зависимости от того, кто его родители. Хорошо хоть сейчас делает это через >, а не просто так. Но вот https://github.com/twbs/bootstrap/blob/master/less/button-groups.less такие штуки все равно сильно уменьшают предсказуемость и усложняют редизайн.
  3. Bootstrap загрязняет глобальный неймспейс сотнями классов с очень generic именами: .table, .dropdown, .row, .left, и т. д. Которые надо все помнить и ни в коем случае не использовать самому.

При таком подходе отстреливание себе ноги становится только вопросом времени.

Когда Boostrap можно использовать

Чтобы не отстрелить себе ногу Bootstrap’ом и получить от него пользу нужно чтобы проект соответствовал ряду требований:

  1. На проекте много страниц.
  2. Страницы собираются из простых базовых элементов. Базовый – это кнопка или таблица. Сложный – это пост в фейсбуке или комментарий к нему, они состоят из нескольких тегов и их нужно переносить и реиспользовать все вместе.
  3. Нет мест, где изменение и эксперименты с дизайном могут сильно повышать/понижать конверсию или другие важные метрики. Как корзина или страница товара в интернет магазине.
  4. Никогда не будет глобального редизайна.
  5. Типизация страниц окупается скоростью их внедрения.

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

Примеры ситуаций когда Bootstrap НЕ подходит

1. Большие интернет-магазины и новостные сайты

У интернет-магазина есть главный KPI – конверсия в покупки. Покупки очень сильно зависят от дизайна страницы товара и корзины/процесса оформления заказа. Изменение конверсии во многом зависят от дизайна, прибавка на полпроцента может тебе позволить удвоить размер команды фронтендеров.

Тут ты дизайнера не запинаешь в гайды. Наоборот ему нужно давать максимум возможностей для экспериментов и изменений, брать эти варианты и гонять 50 сплит-тестов одновременно. С разными отступами, размерами шрифтов, кастомными элементами и прочим.

Если делать такое на Бутстрапе без использования какой-нибудь методологии, то очень просто незаметно сломать что-то в какой-то невидимой сейчас части сайта или в каком-то редком состоянии текущей страницы. Ну и процесс подгонки по большей части будет состоять из борьбы с Бутстрапом и его локальными переназначениями.

Примеры:

http://www.amazon.com/ – тысячи страниц, сотни сплиттестов, постоянный ползучий редизайн.
http://www.gog.com/ – мало стандартных элементов и много кастомных под этот сайт.
http://www.nytimes.com/ – очень много сложных компонентов и исключений. Несколько ключевых экранов от дизайна которых зависят KPI. Сюда же большинство сайтов больших СМИ.
http://arzamas.academy/ – так, до кучи.

2. Сайты со сложными реиспользуемыми в разных местах компонентами

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

А вот вызвать проблемы, когда ты вставляешь этот элемент в какое-то новое место можно довольно легко.

Самый простой вариант взять сложный компонент в котором используется .form-control или label и поместить его в какую-нибудь форму с модификаторами. Куча разнообразный сайдэффектов обеспечена: https://github.com/twbs/bootstrap/blob/master/less/forms.less

Также много интересного можно получить если ты хочешь сделать выпадающий компонент (как непрочитанные сообщения в фейсбуке) и разместить его в закрытом состоянии в шапке, рядом с кнопкой которая его открывает: https://github.com/twbs/bootstrap/blob/master/less/navbar.less

Примеры:

https://mail.yandex.ru/ – мало стандартных контролов, куча кастумных контролов, много исключений, поддержка легаси.
http://trello.com/ – много сложных компонентов, не очень много стандартных бутстраповских. Для http://try.discourse.org/ польза тоже весьма относительная будет.

3. Сайты с большим количеством типов страниц, которым может потребоваться редизайн

Сюда хорошо подходят те же интернет-магазины, большие онлайновые журналы/газеты, городские порталы.

Допустим ты решил поменять кегль у заголовков на каком-нибудь http://www.e1.ru . Ты переназначил стили h1 и h2. Ну ой, теперь тебе надо протыкаться по 100+ типам страниц и убедиться что у тебя не сломалось ничего: Ничего не вылазит за границы блоков.

При этом помня что еще https://github.com/twbs/bootstrap/blob/master/less/jumbotron.less и другие переназначатели и что изменения базовых стилей их скорее всего поломает.

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

Примеры:

https://www.kickstarter.com/ – за последние пару лет сайт как минимум дважды глобально передизайнивали, не считаю отдельных локальных экспериментов.

4. Промосайты и лэндинги

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

Как пример: http://um.mos.ru/promo/gosudarstvennyy_istoricheskiy_muzey/

5. Игры в браузерах

No comments.

Резюме

Да, у Бутстрапа есть своя зона применения. Но она точно не 80% сайтов. К 20-30% он подходит хорошо. Еще на столько же его можно натянуть, с весьма вероятными потенциальными проблемами. В остальных случаях сразу нет.

ну и надо всегда помнить, что проект обычно начинается как что-то простое и предсказуемое, а потом в процессе мутирует во что-то совсем другое. В случае с Bootstrap это будет большой проблемой, в случае с BEM или CSS Modules оно будет просто работать.

Print Friendly, PDF & Email

Опубликовано Вадим В. Костерин

ст. преп. кафедры ЦЭиИТ. Автор более 130 научных и учебно-методических работ. Лауреат ВДНХ (серебряная медаль).

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *