Вводная часть
У CSS есть несколько базовых проблем, которые позволяют очень быстро отстрелить себе ногу при неправильном использовании:
- Глобальный неймспейс – в серверном программировании все что написано в файле, в файле и остается. Все же что написано в css и js засирает глобальное пространство имен со всеми вытекающими. В JS эту проблему сейчас побороли всякими модульными системами, а вот с css сложнее. В идеальном мире это должен починить Shadow DOM и настоящие Web Components, но пока их нет единственный способ с этим бороться – следовать какой-то системе именований селекторов, которая по возможности уменьшает и исключает возможные конфликты.
-
Каскадность – если на один элемент может сработать несколько правил, то они все и сработают последовательно. Если есть элемент
h1.title
, на него сработают все правила для теговh1
и все правила для класса.title
. Так как весь html состоит из тегов, то правил которые применяются на теги без классов будут работать на все вообще.
Соответственно назначать или переназначать стили у тегов – это примерно то же самое, что править прототипы объектов в JS, чем в свое время печально славился Prototype.js
. Эти стили унаследует вообще все объекты и если их потом захочется поменять, то результат будет такой же, как если ты решил в прототипе объекта поменять результаты какого-то метода, который используют все дети этого объекта. Вероятность что-то сломать почти 100%.
- Вложенные селекторы. Можно написать селекторы
.nav .item {...}
и.menu .item
и.item
в зависимости от места вывода будет показываться по-разному. Все хорошо пока тебе не нужно поместить блок menu внутрь блока nav. Тогда сайдэффекты становятся совершенно непредсказуемые. По сути аналог вложенных селекторов из программирования – это функция которая в зависимости от места где её вызывают, выдает разный результат. Например в одном местеsum(2,2)
может возвращать3
, а в другом5
.
Зачем нужны методологии
Хорошая методология занимает предотвращением этих проблем. Покажу как это делает БЭМએ, но CSS Modules, Polymer или всякие решения с инлайновыми стилями для Реакта тоже решают именно их, только другим способом.
Как именование классов по БЭМએу помогает решать эти проблемы:
- БЭМએ запрещает применять стили на теги, максимум ресет. На id тоже нельзя, потому что такие элементы нельзя на странице использовать 2 раза, а сколько раз он тебе понадобится ты не всегда знаешь заранее. Все стили можно применять только к классам.
- БЭМએ создает для всех компонентов глобальный неймспейс – все классы которые относятся к компоненту начинаются с одного префикса. Это позволяет исправить второй пример таким образом:
.nav__item
,.menu__item
. Если один вложить в другой не будет конфликта правил. - Под каждый компонент в БЭМએ создается своя папка – это защищает тебя от конфликтов в именах компонентов и при правильном использовании дает гарантию, что в глобальном неймспейсе будет только один компонент с таким префиксом.
- В БЭМએ есть только один вид вложенных селекторов: модификатор > элемент. Оба начинаются с одного префикса, оба живут в одном файле, оба никак не влияют на другие компоненты.
Что делает Bootstrap
Bootstrap нарушает КАЖДОЕ из этих правил:
- Bootstrap переназначает стили тэгов.
- Bootstrap в куче случаев меняет способ отображения элемента в зависимости от того, кто его родители. Хорошо хоть сейчас делает это через
>
, а не просто так. Но вот https://github.com/twbs/bootstrap/blob/master/less/button-groups.less такие штуки все равно сильно уменьшают предсказуемость и усложняют редизайн. - Bootstrap загрязняет глобальный неймспейс сотнями классов с очень generic именами:
.table
,.dropdown
,.row
,.left
, и т. д. Которые надо все помнить и ни в коем случае не использовать самому.
При таком подходе отстреливание себе ноги становится только вопросом времени.
Когда Boostrap можно использовать
Чтобы не отстрелить себе ногу Bootstrap’ом и получить от него пользу нужно чтобы проект соответствовал ряду требований:
- На проекте много страниц.
- Страницы собираются из простых базовых элементов. Базовый – это кнопка или таблица. Сложный – это пост в фейсбуке или комментарий к нему, они состоят из нескольких тегов и их нужно переносить и реиспользовать все вместе.
- Нет мест, где изменение и эксперименты с дизайном могут сильно повышать/понижать конверсию или другие важные метрики. Как корзина или страница товара в интернет магазине.
- Никогда не будет глобального редизайна.
- Типизация страниц окупается скоростью их внедрения.
Еще можно для прототипов и быстрого старта, чтобы потом выкинуть. Для остальных случаев это боль скорее.
Примеры ситуаций когда 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 оно будет просто работать.