Поначалу для компиляции sass-файлов в css я использовал сторонние программы, вроде Koala. Через какое-то время она стала жутко тормозить и грузить комп и чем больше отслеживаемых файлов, тем больше эти тормоза. После этого я попробовал поработать через Grunt, но там не очень удобно добавлять каталоги, да и когда их много для отслеживания, тоже возникает большая нагрузка.

В итоге я поменял сам подход к sass-компиляции. Вместо того, чтобы отслеживать сразу кучу каталогов и файлов, достаточно отслеживать только те, с которым идет работа прямо сейчас.

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

Почти все руководства по Flexbox стараются вместить в себя описание всех его свойств и возможностей. Это приводит к тому, что вебмастеру довольно сложно соориентироваться какие свойства правильно использовать.

Flexbox — мощная штука, которая охватывает достаточно большой пласт задач, но на практике требуется буквально несколько основных его возможностей. В 90% случаев Flexbox используется как замена float-модели блоков, то есть там, где требуется расположить несколько блоков рядом. Плюсом Flexbox будет и то, что его возможности позволяют легко строить адаптивные сетки, вертикальное выравнивание, произвольный порядок и т.п.

На сегодняшний день можно сказать, что flex полноценно поддерживают все современные браузеры, включая и IE11.

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

На днях запустил UniCSS.Builder — это генератор html с использованием классов UniCSS в онлайн-режиме. Генератор мне хотелось сделать уже давно, но вот только сейчас получилась готовая реализация. Особая благодарность Юре, который уже традиционно выручил с js-кодом и полезными обсуждениями.

На примерах я покажу разницу в верстке между css-фреймворком UiKit и UniCSS для некоторых блоков. При этом сразу отмечу, что UiKit очень хороший фреймворк, во всяком случае многократно лучше распиаренного бутстрапа или Foundation (это вообще — тихий ужас...). Я лишь хочу показать различия в методике верстки. А UiKit я выбрал именно потому что это хороший фреймворк с которым приятно работать.

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

Смысл этой затеи в том, чтобы автоматизировать компиляцию less-файлов. Работать должно так: сохранили любой less-файл, сам запускается компилятор и на выходе получается готовый css-файл. Сейчас я расскажу про вариант, который может использоваться любым вебмастером, но самое главное, что он универсальный и подходит и для других целей, например компиляция SCSS.

Перед началом, давайте определимся с основными понятиями.

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

Классы UniCSS состоят из простых css-правил. Этот фреймворк не задает UI сайта. Его задача — перенести верстку с уровня css-файла в html-код.

Смотрите. Обычно мы делаем так (простой пример):

<div class="my-top">
...
</div>
 
.my-top { 
    margin-top: 20px;
    padding: 10px;
    color: #FFF;
    background-color: #888;
}

C помощью UniCSS будет уже так:

<div class="mar20-t pad10 t-white bg-gray500">
...
</div>

То есть мы написали тот же самый код, только в HTML в виде самостоятельных классов. Если проанализировать работу верстальщика, то это постоянное переключение между css и html файлами. Здесь же мы работаем только с html. Вы удивитесь, сколько это экономит времени и насколько упрощает работу!

В данном примере .my-topкакой-то «технический» класс, не содержащий уникальных стилей. Отступы, фон, текст, ширина и прочие примитивы. При использовании UniCSS уже не требуется создавать отдельный класс блока. CSS-код будет гораздо (многократно!) меньше.

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

В процессе работы с Landing Page Framework постоянно возникало желание как-то унифицировать используемые css-классы. Проблема именования классов до боли знакома каждому верстальщику. Любой, даже самый примитивный, чисто «технический» блок, потребует своего уникального класса, чтобы указать стили, даже если это всего одна строчка кода.

Избыток классов порождает проблему идентификации: чем top-headerотличается от top-head2? Это знает только верстальщик.

Чтобы навести хоть какой-то порядок, стали придумывать различные методики: самая известная (хотя и очень спорная) BEM. Такой подход решает исключительно одну проблему — имя класса получает хоть какую-то осмысленность и вносит ясность для другого верстальщика, которому придется разбираться в коде в будущем.

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

Адаптивность на сайтах на сегодняшний момент, как правило, решается единственным способом:

• выстраиваем колонки для обычных разрешений (например более 960px);
• для средних разрешений колонки становятся «резиновыми»;
• для малых экранов сбрасываем float, после чего все ячейки следуют одна под другой.

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

Способ достаточно простой, поэтому получил широкое распространение. Вместе с тем, очевидно, что в нем существуют большие ограничения, связанные с тем, что модель поведения блоков сетки фиксирована и не предполагает более сложной организации, например для средних экранов сделать не только резиновую ширину, но и расположить ячейки попарно «1-2» и «3-4».

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