4 posts tagged

css

Почему CSS-модули не могут заменить БЭМ

Часто слышу, как разработчики говорят «БЭМ не нужен, ведь есть CSS-модули». Это не так.

Корень этого заблуждения кроется в том, что люди воспринимают БЭМ как CSS-методологию. На самом деле БЭМ это набор универсальных принципов, которые можно применять независимо от используемых технологий, будь то CSS, Sass, HTML, JavaScript или React. БЭМ решает множество задач, в число которых входят именование CSS-классов, подход к разделению интерфейса на независимые части и изоляция стилей для этих независимых частей.

CSS-модули это инструмент, который решает только проблему изоляции стилей. Все остальные проблемы остаются нерешёнными: вам всё ещё нужны какие-то правила для разделения интерфейса на независимые части и всё ещё нужно придумывать названия классов. Поэтому CSS-модули можно и нужно применять вместе с БЭМом.

Эволюция выглядит так:

/* Классический БЭМ с длинными именами классов для обеспечения изоляции */

.shop-cart-button {}
.shop-cart-button_size_small {}
.shop-cart-button_size_large {}


/* CSS-модули с неограниченной свободой творчества в именах классов */

.button {}
.small {}
.large {}
/* или */
.button {}
.is-small {}
.is-large {}
/* или */
.button {}
.size-small {}
.size-large {}


/* БЭМ и CSS-модули */

.button {}
.button_size_small {}
.button_size_large {}

Сразу отвечу на вопрос «а чем плох пример с классами .button, .small и .large?». Он плох тем, что классы .small и .large сами по себе не несут информации о том, к чему они относятся. Нельзя понять, стилизуют ли они отдельный элемент или описывают состояние существующего элемента. Также такие названия классов рано или поздно снова приведут вас к проблеме уникальности имён. Например, вы пишете стили для модального окна. Вам нужно стилизовать полупрозрачный оверлей поверх страницы и само модальное окно. Оба этих элемента могут быть в двух состояниях: виден или скрыт. Кажется, что класс .visible отлично подходит, но проблема в том, что для оверлея и для окна этот класс должен содержать разные стили. Можно придумать костыль в виде селекторов .overlay.visible и .window.visible, но это именно костыль, потому что вы увеличиваете специфичность. С БЭМом всё просто и без ненужного роста специфичности: .overlay_visible и .window_visible.

Oct 8   css   css-модули   БЭМ   вёрстка

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

Иногда новички во фронтенде не понимают истинного предназначения разметки (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 — про внешний вид.

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

Зачем нужен 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 с определённым набором плагинов способен справиться с огромным количеством задач, которые раньше мы решали с помощью препроцессоров, онлайн-сервисов, консольных утилит и вообще вручную.

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

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

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

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

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

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

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

2015   css   html   вёрстка