Мало кто сейчас пишет дизайн сайта с нуля — зачем, если есть куча замечательных 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 как правило когда добавляю какой-то новый функционал — мне удобнее сразу настроить и фронт и бэк, а потом уже отдать на причёсывание дизайна. Если у вас в команде налажены процессы, описаны правила хорошего кода, составлены гайдлайны для всех разработчиков и всё проходит через код-ревью — вы можете просто посмеяться над этой статьёй, я не буду против. Если же статья окажется кому-то полезной — значит я не зря излагал свои сумбурные мысли.