5 posts tagged

вёрстка

Визуальная семантика, или чем разметка отличается от стилей

Иногда новички во фронтенде не понимают истинного предназначения разметки (HTML) и стилей (CSS). Однажды в комментариях к одной из публикаций Форвеба возник вопрос:

Что в 2017 лучше использовать для вёрстки таблиц, HTML-таблицы или CSS-гриды?

Что не так с этим вопросом? Давайте разберёмся.

Разметка — про семантику

С точки зрения компьютера текст это просто последовательность символов. HTML создан для того, чтобы дать компьютеру больше информации о структуре текста. Семантичная разметка — такая разметка, которая позволяет компьютеру исходную последовательность символов разобрать на смысловые единицы вроде секций, заголовков, списков, таблиц, форм.

Стили — про внешний вид

Голый текст это хорошо, но ещё лучше, когда его можно оформить — задать размер шрифта и интерлиньяж, ограничить ширину, выделить заголовки, покрасить ссылки в нужный цвет. За всю эту внешнюю красоту отвечают стили (CSS), и они чаще всего никак не влияют на семантику, то есть на смысл текста. Они лишь дают возможность изменить его внешний вид.
Хороший пример — CSS Zen Garden. Один и тот же HTML-документ, смысл которого не меняется, оформлен более чем двумястами разными способами.

Если разметка не отвечает за визуальное представление, что в HTML делают элементы вроде <i> или <strong>?

Дело в том, что эти элементы тоже несут смысл. Например, так определяется элемент <strong> в спецификации HTML:

Элемент <strong> означает важность, серьёзность или срочность его содержимого.

Заметьте, ни слова не сказано о выделении содержимого жирным начертанием шрифта. Жирное начертание для <b> и <strong>, фоновое выделение для <mark> и другое подобное оформление задаётся стандартыми стилями браузера (user-agent stylesheet). Эти стили никак не относятся к семантике разметки. Более того, в разных условиях одни и те же HTML-элементы могут быть визуально представлены по-разному (например, элементы форм на Windows и macOS). Несмотря на разный внешний вид, кнопки на Windows и кнопки на macOS несут один и тот же смысл.

Разделяйте семантику и представление

Вернёмся к вопросу из начала статьи:

Что в 2017 лучше использовать для вёрстки таблиц, HTML-таблицы или CSS-гриды?

Таблицы нужно размечать как таблицы, то есть тегами <table>, <td> и так далее. Как они будут выглядеть на экране у пользователя — дело ваше, вы полностью контролируете их внешний вид через стили. Ничего не мешает разметить HTML-таблицу и стилизовать её CSS-гридами или флексами.

Запомните: HTML — про семантику, CSS — про внешний вид.

Jul 25   css   html   вёрстка   фронтенд

Организация шрифтов в проекте

Старт любого проекта — ужасная рутина. Даже если у вас есть готовый стартовый шаблон (вроде моего), всё равно нужно писать под каждый проект свои базовые стили, добавлять нужные шрифты и так далее.

В этой заметке я расскажу вам, как облегчить себе жизнь с помощью простой техники организации шрифтов в проекте.

Каждую гарнитуру я храню в отдельной папке с названием, соответствующим имени гарнитуры. Внутри лежат файлы шрифтов, называемые по их начертанию:

/fonts/proxima-nova/regular.woff
/fonts/proxima-nova/bold.woff
/fonts/garamond/regular.woff
/fonts/garamond/italic.woff

Наглядно и понятно, и нет необходимости дублировать имя гарнитуры в названиях файлов. Подключать шрифты с такой структурой — одно удовольствие. Для начала сделаем универсальный код, который вставим в наш базовый шаблон:

// Name regular
@font-face
  font-family "Name"
  src url('/fonts/name/regular.woff') format('woff')
  font-style normal
  font-weight 400

// Name bold
@font-face
  font-family "Name"
  src url('/fonts/name/bold.woff') format('woff')
  font-style normal
  font-weight 800

// Далее в том же духе

Как только возникает необходимость подключить какой-то шрифт, просто закидываем его в папку /fonts, а в стилях заменяем все вхождения Name и name на название гарнитуры с прописной и со строчной буквы соответственно.

2016   вёрстка

Зачем нужен PostCSS

Когда я публикую в FW какой-либо материал о PostCSS, в комментариях сразу начинается срач в духе «да зачем вообще нужен этот PostCSS, есть же препроцессоры!», «PostCSS вообще лажа, не понимаю, почему вокруг него подняли такой шум». Все эти комментарии пишут люди, до конца не понимающие суть задач, которые должен решать PostCSS. Однако каждый из них спешит поделиться своим мнением и рассказать всему миру, что PostCSS — это какая-то ненужная дичь, которую нам пытаются тщательным образом впарить. В этой заметке я попробую «на пальцах» объяснить, чем PostCSS лучше препроцессоров и вообще зачем он нужен.

Также читайте моё интервью с Андреем Ситником, в котором мы поговорили об истории создания PostCSS, применении PostCSS в разработке и о планах проекта на будущее.

На самом деле всё довольно просто. Почему появились препроцессоры? Разработчикам не хватало возможностей, предусмотренных спецификацией CSS. Никто не любит выполнять рутинную работу, и верстальщики — не исключение. Препроцессоры дают нам замечательные возможности по ускорению и упрощению написания CSS: это переменные, вложенные блоки кода, инклуды, примеси и многое другое. Всё вроде бы круто, но проблема в том, что набор возможностей препроцессоров фактически перестал пополняться. Что год назад, что сейчас мы используем одни те же возможности препроцессоров. Развития никакого нет. Более того, все основные препроцессоры (Sass/Less/Stylus) по большему счёту ничем и не отличаются, кроме синтаксиса. Готов поспорить, что через год в препроцессорах не появится ничего принципиально нового.

Если мыслить в плоскости препроцессоров, то мы достигли вершины возможностей. Но PostCSS кардинально отличается от препроцессоров. Нельзя сравнивать PostCSS и препроцессоры, рассматривая PostCSS как ещё один препроцессор.

Что такое PostCSS? Это парсер. Просто парсер стилей. Он ничего не делает кроме того, что получает на входе написанные вами стили и разбирает их на составляющие, а затем собирает обратно. Вот между этими двумя этапами вклиниваются плагины для PostCSS, которые и выполняют всю полезную работу.

PostCSS создан для того, чтобы преобразовывать стили нужным нам образом. Преобразованием стилей занимаются плагины. Плагин берёт разобранный на составляющие код, который ему передал PostCSS, и как-то его обрабатывает. Самый простой пример, знакомый всем — это Автопрефиксер. Он получает на входе ваши стили, ищет в них плохо поддерживаемые свойства. Как только он находит такое свойство — скажем, display: flex; — он идёт на caniuse.com и ищет информацию о том, какие браузеры понимают это свойство только с префиксами. Если вы изначально указали в настройках, что вам нужно поддерживать эти браузеры, он добавляет в ваши стили то же самое свойство display: flex, но уже с нужными префиксами. Далее он обратно передаёт модифицированный код в PostCSS, и тот собирает его обратно в обычный CSS. Такова суть работы плагинов.

Если препроцессоры предоставляют нам строго ограниченный набор возможностей, то PostCSS даёт полную свободу. Вы можете использовать как готовые плагины (которых, к слову, уже довольно много), так и свои собственные. Написать плагин не составит труда, если вы программируете на JavaScript.

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

С PostCSS отпадает смысл использовать препроцессоры. Если вам требуется вложенность — подключите нужный плагин и сможете её использовать. Переменные, циклы, инклуды — всё это уже реализовано и доступно для использования прямо сейчас. Но всё это не так интересно, ведь это уже пройденный с препроцессорами этап. PostCSS предоставляет нам гораздо более интересные возможности. Например, чтобы не инлайнить картинки в CSS вручную, можно лишь указать путь к картинке, и плагин для PostCSS сам заинлайнит её. Но это всё мелочи. С помощью CSS-модулей PostCSS позволяет добиться полной изоляции стилей для каждого компонента на странице. Если без этого плагина вы не могли использовать два одинаковых класса на странице для стилизации разных компонентов, то с этим плагином можно благополучно забыть о проблеме конфликта имён классов. Хорошее применение такой плагин может найти и в вёрстке встраиваемых виджетов, подключаемых на разных сайтах. Это позволит избежать конфликтов стилей виджета со стилями сайта.

Короче говоря, на PostCSS можно самому написать свой препроцессор с блекджеком и куртизанками кучей новых фич. Возможности ограничены лишь вашей фантазией. Благодаря большому количеству плагинов можно даже не писать ничего своего, а сразу использовать готовое. На PostCSS можно делать всё — от модульных минификаторов до CSS на русском.

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

2015   css   вёрстка   постцсс   препроцессоры

Индикаторы правильности заполнения полей формы на CSS

Недавно наткнулся на интересную технику, позволяющую проверять правильность заполнения полей прямо в CSS.

С приходом HTML5 валидация данных на стороне клиента превратилась в довольно простую задачу, которую приятно решать. Всё благодаря атрибутам required, pattern, maxlength (maxlength доступен и в HTML4), а также благодаря новым типам полей ввода (например, email, url).

Новые возможности появились не только в HTML. С помощью CSS можно стилизовать разные состояния поля ввода: поле с неправильно введёнными данными и поле с правильно введёнными данными. Происходит это с помощью псевдоклассов :valid и :invalid.

Сразу рабочий пример:

В этом примере также демонстрируется возможность скрытия кнопки регистрации, пока все поля не будут заполнены правильно.

Поддержка браузерами — IE10+.

2015   css   html   вёрстка

Правильное выравнивание по ширине контейнера

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

Между тем, если вам не нужно поддерживать IE9-, вы можете использовать прекрасное решение на флексбоксе. И сразу кодпен с решением:

Немного комментариев. В данном случае в одной строке сетки может размещаться максимум три элемента — пусть это число будет числом n, запомните его. Зададим контейнеру следующие свойства:

.grid {
  display: flex;
  justify-content: space-between;
}

Казалось бы, задача решена — элементы выравниваются по ширине. Однако если в последней строке элементов будет меньше, чем нужно для её полного заполнения — например, только два блока с шириной в 33%, то эти два блока тоже будут выровнены по ширине, что не очень красиво.

Чтобы блоки в последней строке выравнивались по левому краю, добавим в самый конец контейнера n–1 (помните? n — максимальное количество элементов в одной строке сетки) пустых элементов. Этим элементам зададим следующие стили:

/* Псевдоселектор :empty автоматически выберет пустые элементы */
.grid__item:empty {
  flex: 0 0 33%; /* ширина наименьшего модуля сетки */
  height: 0; /* убедимся в том, что пустые элементы не будет видно в любом случае */
}

На экране этих блоков видно не будет, но браузер будет считать их за полноценные элементы сетки, и если в последней строке останется два видимых элемента, то один из двух пустых блоков подставится в эту же строку и займёт третьего элемента. Этакий элемент-фантом. Таким образом даже при недостатке видимых элементов последняя строка сетки всегда будет заполнена, а значит видимые элементы будут выравниваться по левому краю, что нам и требовалось.

2015   вёрстка   сетки   флексбокс