Как не надо писать шаблоны для bootstrap

Мало кто сейчас пишет дизайн сайта с нуля — зачем, если есть куча замечательных CSS фреймворков? Наиболее популярен среди них bootstrap. Тем не менее, всем хочется, чтобы сайт выглядел уникально, не так как у других — поэтому поверх часто втыкают(в меру возможностей) бесплатный или платный шаблон, либо свой UI кит.

О некоторых проблемах, которые(к сожалению) встречаются даже в платных шаблонах, не говоря уж о своих решениях, я и хочу поговорить. Текст ниже не претендует на уникальность, и вряд ли будет интересен опытным разработчикам, но может оказаться полезным для начинающих фронтендеров, верстальщиков и веб разработчиков широкого профиля. Итак, если вам всё ещё интересно, добро пожаловать!

У нас так исторически сложилось...


Как правило, если сайт разрабатывается в течении продолжительного времени, требования к его внешнему виду регулярно меняются. Если в добавок к этому на нём регулярно меняются программисты — то код(в нашем случае — css) превращается в кашу. Где-то классы бутстрапа, местами классы шаблона, всё это разбавлено костылями нескольких поколений верстальщиков и приправлено инлайн стилями. Попытки поменять что-то или добавить новое приводят к долгим магическим играм в «угадай, какие классы в какие места нужно поставить в этом html блоке!». Хочется всё выкинуть и переписать с нуля. Но я сюда, вообще-то, заглянул просто по быстрому добавить новые поля в форму, у меня по бэкенду задач хватает… Собственно, причину побудившую меня написать данную статью, мы и рассмотрим в первом примере.

Размер инпута


Итак, у нас есть стандартный вид элементов формы, который мы хотим немного изменить, например, уменьшить высоту. Какие есть способы это сделать так, чтобы инпуты соответствовали UI киту?

Можно вставить инлайн стили! Это же будет так весело — копировать потом всю эту портянку в каждый инпут!

Кто-то посмеётся, а я регулярно вижу такие решения. К счастью не в данном случае, но бывает. Что случится если мы так сделаем? Придётся копировать длинные описания стилей в каждый инпут, раздувая шаблон и делая его менее читабельным.

Напишем свой класс, в котором опишем нужные настройки высоты, и заодно изменим размер шрифта!

Да. Это именно он. «h40_px-16». Из названия класса же сразу понятно что он делает? Примерно такой я и встретил в форме, когда пытался понять, почему новые инпуты чуть толще чем нужно. Посмотрел код в том же шаблоне, и нашёл. Какие последствия нас ждут в данном случае? В принципе, ничего критичного. В каждом классе элементов формы, помимо «form-control» мы будем добавлять «h40_px-16». Нужно запомнить, или задокументировать. А если появится требование все элементы формы делать с зелёным фоном? Просто добавим ещё один класс, «b_g». А потом ещё один…

Расширим существующие классы для элементов формы?

Крайне редко вижу это решение, хотя мне кажется что оно на поверхности. И на мой взгляд — самое правильное. Это позволяет нам экономить на количестве классов, которые нужно указывать в элементе, но самое главное — это понижает количество недоумения у разработчиков, которые пытаются работать с этим кодом. Если требуемое изменение затрагивает все элементы такого типа, мы просто добавляем свой набор правил для «form-control», и все инпуты меняют свою высоту, шрифт, фон и т.д.

Нестандартное решение


В соответствии с UI китом, на сайт нужно добавить инновационное, ранее нигде не встречавшееся решение! И оно пишется с нуля. Серьёзно? Нет, я могу допустить такое, если вы используете pureCSS — хороший, но минималистичный фреймворк — и вам нужно реализовать, что-то, что в него не включено. Но если вы используете bootstrap — с крайне высокой вероятностью вам просто нужно перечитать документацию.

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

  1. Для начала он смотрит в документацию bootstrap, и копирует оттуда решение.
  2. Видя что визуально это не соответствует UI киту, он ищет документацию по используемому инновационному решению.
  3. Если этой документации нет(а её скорее всего нет) он ищет в коде примеры того, как это реализовано.
  4. Скопировав нужный класс «beijik» он видит, что бейдж теперь правильный, но синий, а ему нужен красный.
  5. Найдя css файл, в котором описаны классы для UI кита, он обнаруживает что красный цвет не закладывали, и вздыхая добавляет класс «beijik-red»

А теперь сравним это с ситуацией, когда для собственной реализации бэйджей был переопределён класс badge, а цветовая реализация была описана в документации:

  1. Для начала он смотрит в документацию bootstrap, и копирует оттуда решение.
  2. В документации находит, как добавить красный цвет: badge-red

Здесь мы рассмотрели пример, когда требуется не только изменить готовое решение, но и расширить его, поскольку нас не устраивает функционал из коробки(бейджи в bootstrap3 не имеют настраиваемого цвета). При этом всё равно наилучшим вариантом решения остаётся переопределить имеющийся класс, и только после этого — добавлять свои.

Конечно, приведённые мною примеры достаточно рафинированы, но я реально сталкивался с ситуацией, когда я искал решение вначале в документации по bootstrap, потом в документации по используемому на сайте шаблону для него (благо, к нему была документация), потом искал по css файлам где и как стандартное поведение было переопределено и как реализован аналог — а в итоге писал свои стили, чтобы вернуть(!) возможности которые были изначально.

Если вы не стремитесь доставлять вашим коллегам боль и желаете ускорить работу команды в целом, при создании собственных стилей для сайта придерживайтесь следующих правил:

  • Проверить, как реализован нужный функционал в используемом фреймворке(Вы же помните — скорее всего он там есть).
  • Найти, какие классы нужно переопределить для того, чтобы привести внешний вид к желаемому.
  • Если функционал не реализован, или реализован не полностью — согласуйте с коллегами удобный способ расширения функционала, и постарайтесь задокументировать его на будущее.
  • Если функционал нужен не везде, а только на конкретной странице — вынесите его в отдельный файл и подключайте\собирайте его для неё(не надо инлайн стилей, пожалуйста)

Послесловие


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

Комментарии 5

    0

    В целом статья хорошая и на своём слое предлагает верные решения. Пара ремарок не про фреймворк, а про рабочий процесс.


    А если появится требование все элементы формы делать с зелёным фоном? Просто добавим ещё один класс, «b_g».

    Попробуем понять, откуда появилась такая проблема и попробуем бороться не симптомами, а с причиной. Например: разработчикам мало дали времени на создание ui kit, либо он проработан плохо, либо изменения приходится вносить часто, а главное БЫСТРО, потому что НЕ ВРЕМЕНИ ОБЪЯСНЯТЬ НАДО БЫСТРО НАКОДИТЬ!!1 И уже работаем с причиной, чтобы снова не оказаться в той же самой ситуации.


    И вот, одному из разработчиков, который не участвовал в создании этих бейджей, потребовалось добавить их где-либо на сайте.

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

      0
      Я с вами совершенно согласен в плане того, что причины проблем могут быть разные. Конкретно в нашем случае — проект за последние пару лет эволюционировал с третьего бустстрапа+платный шаблон до четвёртого бутстрапа, к которому сейчас рисуется UI кит. За это время над визуальной частью работал один опытный верстальщик (вначале), потом я по остаточному принципу, поскольку нужно было предоставить хоть какие-то интерфейсы к моему бэкенду, и наконец, сейчас в команде появился дизайнер, а на фронте сменилось уже три начинающих разработчика. Изначально не было ни кодревью, ни проработанного код-стайла — результаты сейчас приходится разгребать)
      0
      Я не являюсь профессиональным фронтенд-разработчиком

      Так может не нужно учить? А то почитает какой-то джуниор, и начнет везде использовать бутстрап и методы создания стилей как описано в статье.
        0
        Я знаю html, css и js на уровне среднего фулстака, поскольку это смежные с моей зоны ответственности. Я не призываю использовать бутстрап, он взят в качестве наиболее распространённого примера, я всего лишь высказал своё мнение по поводу того, как переопределять внешний вид визуальных элементов более аккуратным способом. Если у вас есть конкретные замечания — может стоит ими поделиться? Я не сопротивляюсь новым знаниям, и с удовольствием выслушаю аргументированное мнение.
        +2
        Бутстрап сильно вводит людей в заблуждение тем, что якобы предлагает темизацию посредством своего функционала. Это иллюзия.
        Если нужно кастомизировать бутстрап, то нужно обязательно выкачивать исходники. По другому к этой штуке лучше подходить. Вы все равно сделаете промах со своим классом, потому что не видите тех сквозных значений отступов, которые bootstrap использует для разных элементов. Здесь перекроете, там не перекрылось — и начинается!

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.