Расскажу про одну методику, которая позволяет достаточно быстро перевести макет страницы в HTML-код прототипа.

Например у нас есть лендинг. Как правило на первом этапе происходит сбор информации, а потом рисуется графический прототип. Это может быть обычный Ворд, или гугл-документы, но часто это сервис wireframe.cc. Мне он очень нравится, поскольку не содержит ничего лишнего и прост для работы. Ну и бесплатный, что тоже важно.

Иногда работу в wireframe.cc выполняет сам копирайтер. Там он не только пишет тексты, но и размечает блоки, которые по его мнению можно скомбинировать определённым образом. Когда всё готово, этот макет получает html-верстальщик, который должен перенести тексты (это простое копирование) и разверстать блоки, только уже в HTML-код.

Здесь есть очень важный момент — первая версия вёрстки должна повторять макет wireframe.cc (это может быть любой другой сервис — я привожу его только как пример). То есть не нужно верстать в цвете, задавать все изображения, настраивать отступы: нет — это будет тоже черновой вариант, но только выполненный в html-коде.

Читать дальше...

Сегодня выложил релиз Berry 3.0, доступный по адресу https://maxsite.org/berry. Подготовка версии заняла примерно 2 месяца. В этот раз подход к разработке был изменён — вначале была готова документация, и только сейчас вышел полноценный релиз версии (почти на месяц позже). Сейчас у Berry хорошая документация: это и справочник классов, и примеры, и общие описания. Есть отдельный раздел «Блоки», который предназначен не только как пример возможностей Berry CSS, но и для копирования готового html-кода в свои шаблоны.

Третья версия сильно отличается от всех предыдущих. Можно сказать, что она продолжает развитие UniCSS, где была своя типографика. Вообще Berry я выделил из UniCSS, поскольку предполагал использование утилитарных классов с любым другим css-фреймворком. Основная надежда была на Bootstrap, поскольку его разработчики готовили 5-ю версию, которая, как я предполагал будет уже использовать современные CSS-наработки. После выхода первой альфы Bootstrap, я понял, что он «застрял» на идеях пятилетней давности и ждать от него чего-то большего уже не стоит. Это и стало толчком к созданию новой версии Berry, которая уже будет содержать и полноценную типографику, и js-компоненты.

Читать дальше...

Думаю, что каждый вебмастер слышал о концепции Material Design от Google. В целом она рассчитана на разработчиков мобильных приложений, но может частично применяться и для обычных сайтов. В первую очередь речь идёт о подборе цветовой палитры.

Влияние Material Design нашло своё отражение в css-фреймворках, правда в ограниченном объёме.

Я хочу рассказать о Material Design с этой точки зрения, поскольку будущая Berry 3 будет поддерживать его цветовую схему полностью. Начнём с описания того, как обычно создаётся сайт.

Читать дальше...

Те кто читает меня в телеграмм-канале знают, что я сейчас плотно занят переделкой Berry CSS. Да и на сайте я делал анонс. Переделка очень большая, затрагиваются все основные модули, но главное, я решил, что вначале будет документация, а уже потом будет публичная версия (значительно позже).

Поэтому, желающие могут ознакомиться с ранней версией документации, которая идёт в комплекте с версией Berry — alpha 7. Скачать версию Berry не получится, поскольку это закрытый репозиторий, но желающие могут вытянуть css-файл из документации, чтобы поиграться при желании.

Также я хочу немного остановиться на основных изменениях и новых возможностях css-фреймворка.

Читать дальше...

CSS-переменные всё больше используются при вёрстке, поскольку это довольно удобный инструмент, упрощающий работу. Если не оглядываться на IE11, то css-переменные хорошо поддерживаются браузерами. Во всяком случае все современные версии без проблем.

Концепция css-переменных очень проста, но судя по многочисленным публикациям, она создаёт определённое непонимание на уровне «а зачем они вообще нужны?». Как правило верстка выполняется с помощью препроцессоров (в первую очередь Sass). Но поскольку там уже есть свои переменные, то становится непонятно, зачем ещё создавать их на уровне CSS.

Ответ кроется в понимании того, для кого именно создаются css-переменные и какое у них будет назначение.

Читать дальше...

Начну с истории. :-) Первая версии Bootsrtap'а была мало привлекательна. Вторая версия уже предлагала готовую типографику и ряд компонентов. С учётом сумасшедшего пиара со стороны Твиттера (это их разработка), Bootsrtap стал самым популярным css-фреймворком. Третья версия стала доделкой второй — чтобы было понятно — это 2013 год. Нельзя сказать, что код Bootsrtap'а идеальный — там очень много «косяков» и архитектурных просчётов, но это всё нивелировалось хорошей документацией и, опять же, сумасшедшим пиаром.

Многие решили, что Bootsrtap 3 станет последней версией и всё к этому и шло, поскольку команда поддерживала только эту версию, а обещания выпустить следующую тонули в многочисленных альфа-версиях (4-я версия всё-таки вышла в 2018 году). Проблема состояла в том, что веб-вёрстка динамично развивающая отрасль и уже пошли серьёзные подвижки в HTML 5, CSS 3, а также развитие браузеров. То есть Bootsrtap 3 просто перестал нормально отвечать современных запросам. Скажем отсутствие поддержки единиц REM, хотя они уже полностью поддерживались в IE11, а частично в 9 и 10 версии.

За этот период, как раз и появились многочисленные css-фреймворки, которые пытались следовать идеологии Bootsrtap'а, но при этом поддерживают свой код в актуальном состоянии.

Читать дальше...

Расскажу немного о Tailwind CSS, поскольку этот фреймворк позиционируется как утилитарный и мне интересен в сравнении и моими UniCSS и Berry CSS.

У Tailwind высокая популярность — почти 25 тысяч звёзд на гитхабе. На мой взгляд это очень круто — ребята хорошо вложились в раскрутку. :-)

Важный момент в том, что Tailwind написан на JS, то есть там нет css-кода как такового. Его идея в том, чтобы подключать нужные компоненты как js-модули, которые в свою очередь генерируют нужный css-код. Наверное именно поэтому его используют в js-фреймворках на node.js - сборка получается скопом, как там и принято.

Если абстрагироваться от самого сборщика, то идея генерировать css-классы ровно такая же, как и в моём UniCSS (и Berry). Я это реализован в конце 2014 года на Less (потом перешел на Sass), а Tailwind появился на 3 года позже со сборщиком на JS. В нём используется тот же самый подход, когда верстальщик сам указывает какие именно классы ему нужны.

Читать дальше...