⚠️ Обращайте внимание на даты.
Этот блог больше не ведётся с 17 января 2023, и на тот момент с написания этой страницы (15.09.2014) прошло 8 лет.
Если вы знаете об этом сайте с момента его создания (то был июнь 2013), то видели предыдущие дизайны. Они варьировались по сложности, но в итоге их последовательность приблизительно описывает мой путь по полю front-end, полному обломков. На чём я остановился сейчас, вы видите перед глазами. Ну… на данный момент. К моменту прочтения этого материала кем-нибудь я уже в очередной раз могу всё переписать. Кто знает, если не знаю даже я?
Front-end…
Мне стоит пояснить, что это, да? Про клиент-серверную архитектуру, надеюсь, рассказывать не надо, есть служба на удалённом узле, клиент занимается только обработкой получаемых от сервера данных с участием пользователя. Аналогичное разделение существует при разработке веб-приложений: часть кода обрабатывает только сервер (это back-end), часть только клиент (это front-end). Типичная связка: PHP/MySQL в back-end, HTML/CSS/JS в front-end. У меня, впрочем, всё чуть смешнее. У меня Jekyll/Liquid/YAML/Markdown в back-end и HTML/Sass в front-end. Это до сборки. После сборки back-end исчезает, сервер с ним больше не работает, а Sass становится нормальным CSS.
Этот сайт не всегда был таким
Так было не всегда. Первая версия этого сайта была основана на WordPress. Известная штука, которую сложно описывать, когда больше ею не пользуешься. Это нынче самый популярный движок для сайтов, насколько я знаю. На нём делают почти всё (даже то, для чего он не предназначен), и тому, наверное, есть причина? Ну, для него полно хостингов, плагины ставятся из его же интерфейса, плагинов много, есть механизмы автообновления. Чем мне всё это не угодило?
Какое-то время мне этого хватало, но потом я столкнулся с двумя проблемами.
- Изготовление тем для WordPress это катастрофа, в которую без поллитры влезать страшно. Поэтому, если я хотел сколько-нибудь уникальный дизайн для сайта, я не мог его просто взять и написать самостоятельно. Мне нужно было либо взять фреймворк, либо адаптировать готовую тему. Я… взял лучшее из двух подходов, и адаптировал шаблон на фреймворке под свои нужды. Это получилось очень быстро, заняло от силы 2-3 дня. Хотя, как оказалось, это не предел.
- Безопасность. WordPress – излюбленная цель для атак новоиспечённых и тёртых хакеров всех сортов и калибров, причём среди них немало “черношляпников” (тех, кто предпочтёт эксплуатировать взломанный узел в личных целях, нежели сообщит об уязвимости, рассчитывая на вознаграждение). Возможность взлома легко закрывается (с эффективностью, близкой к 100%) аутентификацией с двойным дном: по паролю и по одноразовому коду (Authy). Но остаются интересные истории с pingback (который стоит выключить), спам в комментариях (с которым воюет плагин) и потенциальные необнаруженные уязвимости в рантайме (любой плагин может создать новый вектор атаки).
Более мелкие причины: необходимость периодически обновляться (с недавних пор это делается автоматически), своенравный TinyMCE (редактор, который мне испортил код многих постов) и большая зависимость от хостинга – внести много мелких изменений быстро было нельзя, принципиально, сервер не успевал обрабатывать мои запросы с той скоростью, с какой они у меня возникали.
И где программирование?
Это я рассказываю о том, как я наткнулся на Sass, с которого эта тема началась. До него совсем чуть-чуть: я перевёл свой сайт на Jekyll, который генерирует просто HTML-странички, которые можно загрузить на любой хостинг. После перехода мне пришлось писать себе шаблон самостоятельно, для Jekyll их мало (потому что структура сайта сильно варьируется), но и пишутся они очень просто. Первый был написан на том же Bootstrap. Потом, в версии Jekyll 2.0, появился Sass. И началось самое интересное.
Sass я тогда уже видел не впервые. Поскольку я работаю с Rails, а там Sass используется как основной язык для стилей, представление о том, что это, у меня уже было. Но разрабатывать полновесный дизайн с помощью Sass мне не приходилось, поэтому я начал изучать возможности.
Почему мне не понравился Bootstrap, если им можно пользоваться почти безболезненно? Он весьма толстый (мой CSS в разы компактнее, включая Pygments и FontAwesome) и из-за него разметка выглядит очень страшно: классы там, классы сям. Он хорошо годится, чтобы навалять прототип интерфейса. Но если хотите, чтобы интерфейс выглядел не только прилично, но и более-менее уникально, вам придётся задействовать что-то посерьёзнее или копаться в его исходниках. Я выбрал Sass и прибамбасы. И не пожалел.
Что такое CSS? (зайдём издалека)
Язык описания стилей в вебе. Считается некоторыми языком программирования, но это скользкая тема: он действительно задаёт некую программу представления HTML-разметки, но структура программы и её результат довольно сильно ограничены. Пример кода:
Ок, пример как пример. Довольно примитивный, но уже тут видны некоторые дыры:
- Нельзя ссылаться на одни блоки из других. То есть, если вы хотите извлечь часть описания некий кусочек, который включать в несколько других мест – нет, не получится. Способы обхода… существуют, можно вытащить этот блок повыше и перечислить через запятую, на что он распространяется.
- Только константы. Вы не можете вытащить куда-нибудь наверх цвет и растащить его по всему стилю, где вам он требуется.
- Никаких вычислений. Вы не можете ничего подсчитать в CSS. Вся математика, что у вас есть в распоряжении – разные единицы измерения. Больше ничего.
…а Sass…
Все означенные пункты устраняет. И добавляет новых реализаций уже существующих в CSS. В общем, удобная штука. Причём в сторону “переиспользуемости” (reusability, везде какие-то странные слова), то есть возможности писать код для использования во многих проектах, сделано столько шагов, что библиотеки возникли почти незамедлительно. Примеры сходу – Compass и Bourbon. Здесь я пользуюсь последним. Вот как мог бы выглядеть пример выше в Sass:
Это примитивный пример, поэтому фич здесь видно мало. Но сходу можно увидеть:
- Блоки (селекторы с описанием) можно вкладывать друг в друга, с возможностью ссылаться на “предка” через
&
- Переменные (HELL YEAH)
- Цвета можно вычислять (
transparentize
это функция, делает существующий цвет полупрозрачным на означенную величину;rgba
же в CSS это просто способ указания константного цвета с прозрачностью) - Отсутствие
{ }
и;
, блок определяется по отступу слева (одинаковый отступ у строк подряд – один блок, как в HAML и Python)
На счёт последнего: это синтаксис Sass, есть альтернативный: Sassy CSS, или SCSS, характерен тем, что является надмножеством CSS: т. е. корректный CSS-файл также корректен в SCSS. Но мне он не нравится и я им не пользуюсь.
Первое, что мне захотелось сделать: вытащить часто используемые цвета в единое место и иногда их менять. Тут я вспомнил о проекте base16, на котором собрано много 16-цветных тем для подсветки синтаксиса. Я начал с них: придумал 16 названий переменных ($theme0X
, X
заменить на 0
-F
) и импортировал темы из base16. Результат мне местами дико понравился, но глаз зацепился за одну из тем. Grayscale. Но зацепился не потому, что она круто смотрелась, а потому, что она состояла из оттенков одного и того же цвета, разной яркости. Разумеется, стало интересно, а что будет… если сделать базовый цвет настраиваемым, зафиксировать оттенок и насыщенность, а программно подбирать яркость? И вообще реально ли это?
В сущности, все темы base16 следовали одному принципу: первые 8 цветов были одним и тем же, но разной яркости и по порядку. Остальные цвета - акцентные, и должны, согласно задумке, быть хорошо различимы на фоне каждого из первых восьми (кроме разве что средних, 3 и 4, нумеруя с нуля). Таким образом, можно развернуть порядок первых восьми цветов, и из светлой цветовой схемы получить тёмную, и наоборот. Поэтому задача выглядела более чем реальной, если палитру сайта ограничить 16 цветами…
…и она оказалась мне по силам. Результат уже на этом этапе начал мне сносить крышу, и я уже с трудом заставлял себя остановиться. В итоге я вспомнил о виденном давным-давно инструменте: Color Scheme Designer, а ныне Paletton. Больше всего мне там нравилось работать с режимом “adjacent”, который берёт цвета, находящиеся на некотором расстоянии (в градусах) по цветовому колесу. Я воспроизвёл этот принцип в Sass, и несколько дней провёл просто за тем, что менял цвета и наблюдал за реакцией. Я был в отпуске в это время, можно было страдать фигнёй.
И получилось из этого примерно то, что мы сейчас видим в списке тем в исходниках моего сайта. Впечатляющий список в base16, на фоне которого “миксеры” (лежащие рядом) не кажутся чем-то примечательным, но основная мощь именно в них.
Так как сейчас раскрашивается сайт?
Я достаточно долго пользовался собственноручно написанным генератором near-mixer
(это ссылка!) для раскрашивания сайта, и сейчас включен он же. При кажущемся иногда невероятным результате, он работает очень просто.
- На вход принимаются два параметра:
$sample
– цвет-образец$variation
– вариация, смещение по колесу цветов в градусах
- Первые 8 цветов (монотонки) заполняются, как оттенки цвета-образца
$sample
разной яркости - Оттенок смещается на
$variation
, условно, “вправо”, берутся первые два акцентных цвета яркостью выше средней - Оттенок ещё раз смещается на
$variation
“вправо”, берутся ещё два цвета - Оттенок смещается трижды “влево”: возвращается к монотонкам и ещё на 1 шаг, берутся ещё 2 цвета с другой стороны по колесу
- Оттенок смещается ещё раз влево: берутся последние два цвета чуть дальше по колесу
Итого получается 16 цветов: 8 оттенков по яркости от $sample
, и при $variation
в 30
градусов (как сейчас) берутся акцентные цвета относительно образца на -60
, -30
, 30
и 60
градусов, по два цвета разной яркости. “Многацифр!”
Сейчас часть этих цветов направляется для градиентика в фоне (за него спасибо вот этим крутым парням), кое-что идёт на цвета для ссылок и заголовков, практически всё остальное применяется только в подсветке синтаксиса. Да, она тоже опирается на CSS, и то, что с помощью Sass её можно заставить выглядеть прилично при любой цветовой гамме моего сайта – это крайне круто, достаточно указать ей переменные цветовой гаммы сайта. Система сейчас, впрочем, работает настолько хитро, что всему сайту и отдельно синтаксису можно назначить разные стили. “Крутода?”
Это всё можно применить не только в Jekyll. Но в Jekyll (и любом другом генераторе статики, на самом деле) это наиболее просто сделать, не отвлекаясь на тонкости движка. Я уже начал применять похожий подход на работе, работает очень неплохо и даёт красивые результаты.
CAUTION: миксеры написаны совершенно ужасающим Sass, которым писать нехорошо, но по причине незнания языка я не могу лучше; по мере совершенствования собственных навыков я буду части сайта переписывать.