2. Проблема
Требования к верстке постоянно растут, а вместе с ними и
себестоимость проекта:
• адаптивность: был один дизайн, а стало N;
• кроссбраузерный CSS3;
• улучшенная типографика.
На что обратить внимание в технологическом
процессе, чтобы сократить издержки?
2 / 30
3. Главная беда дизайна
«Дизайн сайта — набор страниц»
адаптивный дизайн только усугубляет проблему:
• на уровнe CMS: единая контентная область, WYSIWYG.
• на уровнe дизайнера: главная и рабочая страницы и т.д.
• на уровне клиента: сделайте точно так, как я хочу.
Дизайн сайта — система компонентов
CMS — часто ограничивающий фактор
3 / 30
4. Работа с дизайнерами
Реализация адаптивного дизайна будет проще, если:
• мыслить в контексте всего сайта, а не отдельной страницы;
• мыслить элементами, образующими визуальный язык;
• понимать технологические ограничения;
• использовать сетки и вертикальный ритм;
• минимизировать количество и варианты блоков;
• понимать, что pixel-perfect дизайн невозможен.
Звучит банально, но менять стереотипы тяжело.
4 / 30
6. Типографская сетка
В обычном дизайне полезна, в адаптивном — необходима:
• различные виды сеток (%, px) для адаптивных вариантов;
• различная размерность сеток для адаптивных вариантов;
• не больше двух-трех сеток на медиа-вариант;
• сетки для всего сайта, а не для отдельных страниц;
• несложно реализуется CSS-препроцессором.
Результат формализованное горизонтальное
позиционирование блоков в различных
адаптивных вариантах.
6 / 30
8. Сетка: % или px?
• пиксельные сетки технологичнее и проще;
• фиксированные адаптивные варианты
менее затратны в реализации;
• процентные сетки универсальные, но
сложнее: размеры вложенных элементов,
ошибки округления и и.д.
• процентные сетки необходимы на
небольших мобильных разрешениях.
8 / 30
10. Вертикальный ритм
Единый шаг для вертикальных размеров элементов:
• вертикальные отступы;
• вертикальный размер изображений и блоков;
• элементы переменной высоты — в контейнер;
• выбор шага определяет baseline для основного шрифта;
• легко реализуется CSS-препроцессором.
Результат улучшение внешнего вида страницы,
системность в выборе размеров, возможность
варьирования на этапе разработки.
10 / 30
11. Дизайн: антипаттерны
Основные проблемы адаптивной верстки — на этапе дизайна:
• «над этим я не думал, разберемся при верстке»;
• подгонка сетки к уже отрисованному дизайну;
• единая сетка для всех блоков с массой исключений;
• нарушение порядка блоков в различных вариантах;
• расчет на ограниченный размер контента;
• избыточный второстепенный контент в начале страницы
на мобильном устройстве;
• избыточное использование таблиц и сложных
интерактивных элементов.
11 / 30
12. Роль верстальщика
Верстальщик необходим, но в новых условиях должен
эволюционировать:
• «страничная» CMS — неизбежная верстка контента;
• верстка шаблонов страниц;
• верстка компонентов, в т.ч. типовых контентных блоков;
• клиентский JavaScript;
• минимальное участие в клиентском контенте за счет
использования типовых контентных блоков.
Верстальщик → Развитие CMS → Frontend-developer
12 / 30
13. Прототипирование верстки
Master page – минимальный статический прототип для простых
сайтов:
• одна страница со всеми интерфейсными компонентами;
• HTML с минимальной (php,node...)-шаблонизацией;
• можно использовать как style guide;
• упрощает выявление конфликтов между компонентами;
• упрощает тестирование на мобильных устройствах.
• поощряет минимализм (хотя иногда уже поздно)
13 / 30
14. Структура CSS-классов
• БЭМ1 — большие проекты, набор общих блоков;
• у нас — небольшие проекты с сильно отличающимся
дизайном, используем сильно упрощенный вариант.
Главное: независимость блоков друг от друга и их
структурирование внутри проекта.
• префиксная система имен классов;
• упрощенная концепция блок-элемент-модификатор.
1
http://ru.bem.info/method/
14 / 30
15. Префиксная система имен
namespace-...-block-element-subelement-...--modificator
• модификатор всегда используется с основным классом
• модификатор не разбивается на пару «свойство-значение»
• разработчик может вводить промежуточные пространства
имен, отсутствие конфликтов между ними — на его совести;
Результат стандартизируем имена классов, исключаем
конфликты между своими и чужими классами.
15 / 30
16. Структура блоков верстки
Используем наиболее подходящую семантическую основу,
большая часть стилизации с помощью классов стандартной
структуры.
<class="app-menu">
<ul>
<li class="menu-item"><a href="#">...</a></li>
<li class="menu-item menu-item--sel"><a href="#">...</a></li>
</ul>
</div>
Результат семантическая верстка, стандартная структура
блоков.
16 / 30
17. Генерируемый код
Генерация кода необходима при разработке клиентской части:
• генерация CSS из более высокоуровневого кода;
• минимизация количества и объема CSS-файлов;
• структурирование и оптимизация JavaScript-кода
средствами AMD/RequireJS2 и т.д.
Результат снижение затрат на поддержку и развитие
старых проектов, повышение качества новых.
2
http://requirejs.org
17 / 30
18. Простейшая генерация кода
К любому проекту можно добавить генерацию кода, есть много
модных инструментов, но проще всего — make:
www/css/%.css: src/less/%.less
lessc $< > >@
Для существующего проекта просто переносим CSS-файлы в
src/less/ и получаем преимущества в виде переменных,
макросов и т.д.
Результат сокращаем код, постепенно рефакторим CSS,
если надо — приводим в чувство JavaScript
18 / 30
19. Выбор CSS-препроцессора
• основные претенденты: SASS, LESS, Stylus;
• SASS — логично, если решение на Ruby;
• Compass – полезно, даже если не использовать SASS;
• Любой CSS-файл – валидный исходник на LESS;
• LESS распространеннее, Stylus функциональнее из
коробки;
Мы выбрали LESS, Stylus тоже хороший выбор.
19 / 30
20. Особенности LESS
• полная синтаксическая совместимость с CSS;
• вложенные пространства имен, удобноj для библиотек;
• нет условий и циклов, но есть pattern matching и рекурсия;
• динамическое формирование имен классов, хотя из
документации это неочевидно.
Главное не генерировать избыточный CSS, в клиентском
коде максимально используем определение
классов, а не макросов.
20 / 30
21. LESS-фреймворк
• тривиальная часть — CSS3, шрифты и т.д.
• инициализация верстки: reset или normalize, чаще второе;
• медиа-варианты и версии для браузеров без Media Query;
• генерация сеток, средства отладки;
• базовые настройки отображения элементов форм;
• всевозможные костыли для IE.
Результат типовые решения для всех проектов, упрощение
поддержки, снижение порога вхождения для
разработчиков.
21 / 30
22. Файлы проекта
• правила CSS группируются в файлы произвольно;
• фреймворк подключается одним @import;
• каждому результирующему CSS-файлу соответствует
корневой less-файл, подключающий фреймворк и другие
less-файлы;
• корневых файлов может быть несколько: под разные
разрешения, разные версии IE и т.д
Результат правила можно группировать покомпонентно,
строить библиотеки компонент и т.д.
22 / 30
23. Медиа-варианты
@boot-media-variants: 9; // количество диапазонов;
...
@boot-media-3-name: tablet; // определение диапазона;
@boot-media-3-min: no; // есть стандартные, но
@boot-media-3-max: 767px; // можно переопределить
@boot-media-3-ie: no; // если необходимо.
...
#media { // стандартный namespace
.for(all) {
// общие правила
}
.for(tablet) {
// правила для планшета
}
} // результат можно вывести в отдельные файлы или общий файл
Результат покомпонентное определение вариантов, генерация
вариантов в оптимальном порядке и варианта без MQ.
23 / 30
24. Элементы форм
• в разных проектах выглядят совершенно по-разному;
• при этом общие проблемы взаимного позиционирования,
размеров и т.д;
• проблема использования готовых решений типа Bootstrap
– геометрия и внешний вид неразделимы.
Решение: • базовыe классы – позиционирование;
• стандартные макросы – геометрия;
• оформление – свое в каждом проекте.
• оформление и размеры – модификаторы.
24 / 30
25. Поддержка IE
// В файлах компонент.
#ie {
.for(7) { /* правила для IE7 */ }
.for(lt9) { /* правила для IE8 */ }
}
// В результирующем файле
#boot > .classes(ie, 7);
Также с осторожностью используем некоторые полифиллы, в
частности PIE3 (CSS3) и boxsizing4 (border-box).
3
http://css3pie.com
4
http://github.com/Schepp/box-sizing-polyfill
25 / 30
27. Инициализация блока
Глобально используем normalize, внутри отдельного блока
выполняем по необходимости reset для семантической базы
блока:
.app-menu {
#boot > .reset(ul, left); // локальный reset
#boot > .rhythm(15px, margin, 1, 0); // baseline для 15px
// margin-top в 1 шаг
.app-menu-item {
// padding в 1 шаг и корректировка для border
#boot > .rhythm(padding,1,1,1px,1px);
border: solid 1px #ccc;
}
}
27 / 30
28. Инициализация верстки
1 определяем основной размер шрифта и вертикальный шаг;
2 переопределяем настройки типографики если нужно;
3 определяем диапазоны медиа-вариантов;
4 конфигурируем сетки в различных медиа-вариантах;
5 верстаем нестилизованные блоки с классами блоков и
ячеек сетки;
6 проверяем раскладку в различных разрешениях,
контролируем границы блоков;
7 дальше разбираемся со стилизацией каждого блока.
28 / 30
29. Итого
Что необходимо сделать, чтобы технологический процесс был
адекватен современным требованиям к верстке?
• работать с дизайнерами: компонентный подход,
стандартные паттерны, технологические ограничения;
• стандартизировать структуру разметки и CSS-классов;
• использовать адаптивные типографские сетки;
• внедрить генерацию клиентского кода вообще и
CSS-препроцессор в частности;
• реализовать набор типовых решений с помощью
CSS-препроцессора.
29 / 30