Intent to Prototype: CSS Gap Decoration

Ранее я писал о предложении по добавлению в CSS возможности стилизации gap-ов во flexbox и grid. И вот, команда Microsoft Edge начала разработку прототипа этих функций в Blink (движок в Chromium браузерах). Подробнее с предложением можно ознакомиться в черновике спецификации и эксплейнере.

Другие движки (Webkit и Gecko) пока явно не проявили заинтересованность, но если обкатка прототипа пройдёт успешно, эту спецификацию доработают и примут в CSSWG, а там и другие движки подтянутся. Предложение на самом деле очень полезное и нужное.

Роли-контейнеры: region

Продолжаю рассказывать про ARIA-роли. region — это область с контентом, которая имеет особое значение в рамках страницы, которое определено автором. Элемент с этой ролью попадает в список ориентиров, поэтому пользователи вспомогательных технологий смогут быстро добраться к этому участку страницы. При этом region должен использоваться для группировки контента, назначение которого не попадает ни под один из существующих ориентиров (banner, navigation, contentinfo, complementary, main, search или form).

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

- область с основным описанием продукта и формой добавления в корзину в интернет-магазине
- область с Call-To-Action формой на сайте услуг
- разные по функционалу панели в админке
- область с чатом возле основного плеера на стриминговом сервисе

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

<div role="region" aria-labelledby="r1">
  <h2 id="r1">Важная область</h2>
  <!-- контент -->
</div>

Если к встроенному в HTML элементу <section> привязать заголовок, то элемент получит встроенную роль region. Исходя из первого правила ARIA, лучше использовать именно такой вариант.

<section aria-labelledby="r1">
  <h2 id="r1">Важная область</h2>
  <!-- контент -->
</section>

К region можно быстро переключиться через список ориентиров или горячие клавиши. В этом смысле заголовки решает похожую задачу. Но region добавляет дополнительную семантику, скринридеры озвучат границы и название области. При помощи aria-roledenoscription можно дать роли более конкретное название. Подробнее об использовании region можно прочитать в технике ARIA20.

Go Make Things

Хочу поделиться проектом под названием Go Make Things. Его автор, Крис Фердинанди, практически каждый день пишет небольшие заметки о том, как делать более простой, быстрый и устойчивый веб. Архив заметок доступен на сайте, также можно подписаться на email-рассылку.

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

Заметки затрагивают темы HTML, CSS, Vanilla JS, доступности, производительности, архитектуры, веб-компонентов, статических сайтов и т.д. Если вам нравится то, о чём я пишу в этом канале, то вам, с большой вероятностью, понравится и то, о чём пишет Крис.

Отказаться от зависимостей и не умереть

В 435-м выпуске Веб-стандартов обсуждали ванильный дауншифтинг. Поводом для этого послужил запуск сайта Plain Vanilla. На этом сайте демонстрируются подходы к созданию компонентов, стилизации, роутингу, модульности, деплою, тестированию и менеджменту состояния с использованием стандартных HTML, CSS, JavaScript и Web API. Без фреймворков, сборщиков, библиотек и прочих инструментов. Проект интересен как минимум тем, что показывает возможности современного веба. Полезно для тех разработчиков, которые много работают в экосистемах фреймворков и мало смотрят за их пределы. Несмотря на ряд спорных моментов, идея классная.

Одно из замечаний к таким проектам обычно звучит так: “круто, автор сделал todo app на vanilla, а как насчёт полноценного приложения”? Тут мне вспомнился доклад “Отказаться от зависимостей и не умереть” Ильи Черторыльского с конференции Frontendconf. Он в качестве эксперимента поставил себе задачу разработать полноценное приложение в React-стиле без использования зависимостей и посмотреть, насколько современные возможности далеко продвинулись.

Говоря о технических деталях:

- Используется VSCode с плагином для подсветки теговых шаблонных литералов
- Нет node_modules, package.json, package-lock.json, сторонних пакетов и этапа сборки, весь код в папке public
- React-подобная структура component/container с корневым компонентом App и монтированием в точке входа index.js
- Простая типизация при помощи instanceof и подсказки IntelliSense
- Стандартные браузерные ES-модули import/export
- <noscript type="importmap"> для алиасов путей к модулям
- jsconfig.json для настройки алиасов в VSCode для перехода к файлу по клику (оказывается, такой файл существует для обычного JS, по аналогии с tsconfig.json)
- Роутинг на веб-компонентах и History API
- Импорт стилей через Import Attributes (import style from 'style.css' assert { type: 'css' };). Это уже практически стандарт (Stage 3) с той лишь разницей, что синтаксис с assert заменили на with
- Работа с объектом CSSStyleSheet() и adoptedStylesheet. Илья сказал, что это только для ShadowRoot, но на самом деле можно использовать и для Document
- В качестве компонентной модели используются веб-компоненты, в частности Custom Elements и Shadow DOM с классом-обёрткой для более удобного DX (реализован простой DOM diffing, привязки обработчиков событий, ref, storage и т.д.)
- DOMParser для парсинга шаблонов и точечного обновления DOM
- Element Internals, Form-associated Custom Elements и Constraint Validation API для работы веб-компонентов с формами и валидацией
- <dialog> для создания модальных компонентов
- Intl API для локализации дат

В итоге удалось создать приложение внутреннего корпоративного портала для разработчиков. Достаточно большая структура, около сотни компонентов, модалки, формы, авторизация. Получившийся проект дорабатывали как опытные синьоры, так и стажёр. В итоге все разобрались с кодом и смогли реализовать поставленные задачи. По словам Ильи, переход на такой подход удался 50/50, потому что остальная часть проектов в компании написана на React, UIKit сделаны под React и портировать всё это долго и лениво.

Я считаю его опыт успешным. Илья за трое выходных разработал тонкую обёртку над браузерными API и на этом смог построить полноценное работающее приложение без сторонних библиотек и сборщиков. Код читаем, написан в React-стиле, работает достаточно быстро, разработчикам понятно. Это говорит о том, что эксперимент можно считать успешным. Иными словами, на нативных технологиях можно разработать приложение, но не без нюансов, конечно.

Размер DOM

Обычно разработчики не задумываются о количестве элементов в DOM и используют столько, сколько нужно. А иногда используют сильно больше, чем нужно. На многих проектах в DevTools можно увидеть “ёлочку”:

<div>
  <div>
    <div>
      <div>
        <div>
          <div>
            <div>
              <!-- контент -->  
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Предполагаю, что это происходит из-за ограничений фреймворков, когда у компонента мог быть только один корневой элемент. И, конечно, этим корневым элементом выступал <div>. При глубокой вложенности компонентов появлялась “ёлочка”. В современных версиях фреймворков эти ограничения уже не актуальны, но много проектов написано на старых версиях.

Чем плоха такая “ёлочка” и большое количество элементов в DOM? Тем, что это влияет на производительность. На каждый HTML-элемент браузеры создают объект DOM, у которого большое количество свойств, методов, вложенных объектов и связей с другими объектами. Значения всех свойств и связи нужно просчитать. Также браузеры вычисляют значения всех CSS-свойств и положение на экране для отрисовки. Оптимизация работы с DOM происходит постоянно, поэтому все расчёты происходят очень быстро. Тем не менее, чем больше элементов DOM, тем:

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

Поэтому следует избегать “ёлочки” и большого количества элементов в DOM. Google Lighthouse выдаст предупреждение “избегайте чрезмерного размера DOM”, если:

- в документе более 1400 элементов
- есть элементы с глубиной вложенности более 32 уровней
- есть элементы, у которых более 60 дочерних элементов

На эти цифры и стоит опираться. Говоря об общем количестве элементов, стоит придерживаться принципа чем меньше, тем лучше.

Как уменьшить количество элементов:

- фрагменты в React <></>
- виртуализация большого набора данных (отображение только той части списка или таблицы, которая видна на экране)
- разбиение большого количества данных на страницы (пагинация), при этом не более 60 элементов набора данных на страницу
- фильтрация, поиск и группировка большого количества данных для уменьшения выборки
- альтернативные решения вместо бесконечных лент, ленивой дозагрузки и формирования большого набора данных на одной странице
- динамическая генерация интерфейса (модальные окна, тултипы), но осторожно, потому что генерировать сложные интерфейсы на лету тоже не очень производительно
- раскладка контента по областям при помощи CSS Grid вместо дополнительных контейнеров и обёрток
- адаптивный дизайн, чтобы избегать отдельных скрытых частей интерфейса для разных экранов

State of CSS 2024

Стартовал ежегодный опрос State of CSS 2024 о состоянии CSS. Этот опрос важен, поскольку разработчики спецификаций и браузеров смотрят на результаты и делают выводы. Поэтому призываю всех выделить время и пройти этот опрос. Также пошарьте с коллегами, пусть тоже пройдут.

Не делайте сайты как SPA

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

Когда я делал этот сайт, это была обычная вёрстка, интегрированная в WordPress. Клиент решил обновить сайт и обратился к веб-студии. Они разработали новый контентный сайт в виде SPA… Сайт из 5 страниц с текстом, картинками, видео и парочкой интерактивных элементов сделан как SPA. Кажется, что в индустрии стало нормой забивать гвозди микроскопом, а разработчиков с микроскопом в руках это особо не заботит.

Что плохого в SPA для сайтов?

- Контент состоит из <div id="app"></div>. Получается, что на контентном сайте изначально нет контента. Краулеры, парсеры и прочие сканеры страниц ничего не видят. Google умеет обрабатывать такие сайты, но задействует специальный механизм, который работает дольше и хуже. С другими поисковиками ситуация сложнее. В итоге наработанные ранее позиции сайта в выдаче будут потеряны.

- Контент завязан на JavaScript. Если по тем или иным причинам JavaScript недоступен, сайт вы не увидите. Золотое правило веб-разработки: HTML для контента и структуры, CSS для внешнего вида, JavaScript для интерактивности. Использование JavaScript для контента добавляет больше проблем, чем даёт плюсов. Переходы между страницами без перезагрузки не стоят того.

- Плохие метрики Core Web Vitals. Конкретно у нового сайта First Contentful Paint 2.1-2.9c, Largest Contentful Paint 7.5-8.2c. То есть усреднённый пользователь видит сайт только через 2-3 секунды, а изображение на станице через 8 секунд. И это на небольшой странице. Core Web Vitals влияют на SEO и восприятие пользователей. А в будущем у сайта начнутся проблемы с производительностью, когда маркетологи добавят туда скрипты для аналитики и рекламы.

- Лишняя сложность. Для вывода статического контента зачем-то нужен условный React, хуки, JSX, для переключения страниц нужен отдельный пакет с роутером и его настройка, для стилей нужен пакет с хитрой обработкой под капотом, для работы всего этого нужен сборщик с сложной конфигурацией. И весь этот оверхед для вывода статического контента.

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

- Работа в браузере. При SPA-подходе основная логика выполняется у клиента на устройстве. Это в свою очередь нагружает процессор, забивает основной поток выполнения, влияет на потребление батареи и т.д. Зачем выполнять лишний код, если можно просто отдать готовый контент?

Мой посыл: не делайте контентные сайты как SPA. Отдавайте предпочтение Static Site Generation (SSG) или Server Side Rendering (SSR). Генерируйте и отдавайте с сервера готовый HTML, подключайте внешний CSS и сверху точечно добавляйте JS для интерактивных компонентов. Это во всех смыслах работает лучше и быстрее. А SPA оставьте для комплексных приложений со сложным интерфейсом и взаимодействиями.

⬆️

Забыл упомянуть про проблемы с доступностью. В SPA необходимо дополнительно управлять заголовком <noscript>, следить за положением фокуса на странице, и реализовывать механизм оповещения о перерисовке страницы. Лишняя сложность и код.

You don't know HTML: <search>

Элемент <search> — это относительно новый элемент HTML, который, как легко догадаться, предназначен для разметки поиска. Это семантический контейнер с блочным отображением (display: block) и встроенной ролью search.

Согласно спецификации WAI-ARIA, роль search — это ориентир для набора объектов пользовательского интерфейса, которые реализуют функциональность поиска. Яркий пример — это форма с полем для ввода поискового запроса и кнопкой поиска.

<search>
  <form action="/search" method="get">
    <label for="q">Поиск:</label>
    <input type="search" id="q" name="q" autocomplete="off">
    <button aria-label="Найти">🔍</button>
  </form>
</search>

Кроме формы поиска в <search> можно помещать набор элементов управления для фильтрации результатов. Например, фильтр в интернет-магазине или элементы управления для фильтрации таблицы в реальном времени. Всё, что как-то влияет на набор данных на странице или осуществляет глобальный поиска по сайту.

Элемент <search> уже поддерживается во всех современных браузерах. В более старых браузерах можно использовать эквивалент <div role="search"> до более широкой поддержки <search>. Или же можно использовать <search>, но подстраховаться следующим образом:

<search role="search">
  <!-- средства поиска -->
</search>

В CSS при этом важно не забыть указать:

search {
  display: block;
}

#ydkhtml

Placeholder

У некоторых текстовых полей ввода есть возможность указать атрибут placeholder. Часто этот атрибут используется не по назначению. Основная задумка этого атрибута — предоставить пользователю короткую подсказку с образцом данных или ожидаемым форматом ввода, когда в поле нет заранее предустановленного значения (value).

Вот примеры правильного (✅) и неправильного (❌) использования атрибута:

<!-- ❌ Замена лейбла -->
<input 
  type="text"
  id="name"
  name="name"
  placeholder="Имя"
> 

<!-- ✅ Пример данных -->
<label for="name">
  Ваше имя:
</label>
<input
  type="text"
  id="name"
  name="name"
  placeholder="Алексей"
>

<!-- ... -->

<!-- ❌ Дублирование лейбла -->
<label for="email">
  Email:
</label>
<input
  type="email"
  id="email"
  name="email"
  placeholder="Email"
> 

<!-- ✅ Пример данных -->
<label for="email">
  Email:
</label>
<input
  type="email"
  id="email"
  name="email"
  placeholder="john.doe@mail.com"
> 

<!-- ... -->

<!-- ❌ Призыв к действию -->
<label for="birthdate">
  Дата рождения:
</label>
<input
  type="text"
  id="birthdate"
  name="birthdate"
  placeholder="Введите дату рождения"
> 

<!-- ✅ Ожидаемый формат -->
<label for="birthdate">
  Дата рождения:
</label>
<input
  type="text"
  id="birthdate"
  name="birthdate"
  placeholder="ДД.ММ.ГГГГ"
> 

<!-- ... -->

<!-- ❌ Маска -->
<label for="name">
  Телефон:
</label>
<input
  type="tel"
  id="phone"
  name="phone"
  placeholder="+375 (__) ___-__-__"
> 

<!-- ✅ Пример данных -->
<label for="name">
  Телефон:
</label>
<input
  type="tel"
  id="phone"
  name="phone"
  placeholder="+375 (12) 345-67-89"
> 

<!-- ... -->

<!-- ❌ Инструкция -->
<label for="passnum">
  Номер паспорта:
</label>
<input
  type="text"
  id="passnum"
  name="passnum"
  placeholder="2 буквы и 7 цифр с предпоследней страницы паспорта"
> 

<!-- ✅ Пример данных -->
<label for="passnum">
  Номер паспорта:
</label>
<input
  type="text"
  id="passnum"
  name="passnum"
  placeholder="AH1234567"
  aria-describedby="info"
> 
<p id="info">2 буквы и 7 цифр с предпоследней страницы паспорта</p>

Таким образом, placeholder не должен:

- Заменять лейбл
- Дублировать лейбл
- Призывать к действию
- Быть маской ввода
- Предоставлять инструкцию

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

input::placeholder {
  /* Стили текста placeholder */
}

input:placeholder-shown {
  /* Стили input, когда виден placeholder */
}

Автор выложил бесплатно свою книгу на сервис. При совершении "покупки" я вижу это. Сервис предлагает мне подписаться на еженедельные и ежемесячные маркетинговые рассылки.

Подробно расписано, что к чему, и есть два чекбокса, подтверждающих моё согласие на подписку. Во-первых, чекбоксы проставлены по умолчанию, но это ладно. Во-вторых, их нельзя снять! Нажатие ни к чему не приводит! То есть это выбор без выбора. Зачем тогда, спрашивается? Неужели круто, когда пользователь принудительно подписывается на то, что ему не нужно, а потом специально отписывается и кидает e-mail в спам-список?

Новые CSS-функции

Адам Аргайл, деврел Chrome, поделился в своём блоге списком новых CSS-функций, которые находятся в работе у CSSWG. Список достаточно внушительный и интересный. Предлагаю краткий обзор всех функций.

- random() — генерация случайного значения из диапазона
- random-item() — выбор случайного значения из списка
- sibling-count() — количество дочерних элементов
- sibling-index() — позиция дочернего элемента
- progress() — позиция значения в диапазоне в виде числа
- media-progress() — позиция медиа-выражения в диапазоне в виде числа
- container-progress() — позиция контейнерного выражения в диапазоне в виде числа
- mix() — интерполяция двух значений
- calc-mix() — интерполяция двух чисел, размеров или процентов
- cross-fade() — смешивание двух изображений
- transform-mix() — интерполяция двух значений со списками трансформаций
- first-valid() — выбор первого поддерживаемого браузером значения
- toggle() — циклический выбор одного значения из списка
- calc-size() — вычисление внутреннего значения, например auto-высоты по контенту

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

VI конференция по цифровой доступности стартует 4 сентября

В этот раз в качестве продюсера конференции выступает Света Бондаренко. Она придумала офигенную концепцию - поговорить об эмоциях при работе с доступностью.

Вас ждёт очень много, более 15 экспертов по доступности. Они расскажут что их бесит в цифровых продуктах, что до сих пор удивляет, чему можно порадоваться и чего стоит бояться.

04.09 в 19:00 по МСК открытие конференции: трек "Бесит". посвящён проблемам и ситуациям от которых подгорает у всех кто связан с цифровой доступностью.

Серые буквы на сером фоне? Люди, которые не умеют в доступность и распространяют неверные сведения? Или может "версия для слабовидящих"?


11.09 в 19:00 по МСК трек: "Удивление". Вторая встреча посвящена тем неожиданным моментам, которые вызывают удивление у специалистов по цифровой доступности.

Улучшение доступности ухудшило доступность. Анонс реализации доступности спустя 2 года и другие курьёзы.


18.09 в 19:00 по МСК трек: "Страх". Третья встреча посвящена тем пугающим аспектам цифровой доступности, которые вызывают страх у специалистов.

Что если бизнес решит, что доступнось, это впустую потраченые деньги? А если разработка доступности будет "для галочки"?


25.09 в 19:00 по МСК трек: "Радость". Четвертая встреча посвящена тем моментам, которые приносят радость и удовлетворение в работе над цифровой доступностью.

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




Конференция бесплатная!

Приходите сами, и зовите друзей, будет интересно!

Privacy UX

Вы когда-нибудь обсуждали с кем-то покупку чего-либо и потом видели рекламу этого в соц. сетях? Или гуглили что-то, а потом баннеры с этим преследовали вас на всех сайтах? Может быть, видели эти надоедливые баннеры “Мы используем cookie”? Это всё о приватности данных.

Хочу поделиться докладом Виталия Фридмана “Privacy UX”, где он подробно и в своём стиле рассказывает о проблеме с приватностью данных и показывает примеры сайтов в диком Интернете. Крайне рекомендую посмотреть доклад не смотря на то, что он 2019 года. Я после этого доклада о многом задумался.

Чего не хватает в вебе?

С 6 по 7 июня прошла конференция CSS Day. Команда Chrome присутствовала на мероприятии и сделала полезный интерактив. В перерывах между докладами, участники конференции могли написать на стикере, чего не хватает в веб-платформе, и приклеить его на доску. Другие участники могли "голосовать" за фичи путём приклеивания оранжевого кружка. Лия Веру поделилась фото этой доски в конце конференции и я начал изучать её, чтобы подготовить материал и поделиться им в канале 🕵️‍♂️.

И вот, на днях в блоге Chrome For Developers вышла официальная публикация от Рейчел Эндрю, в которой она поделилась результатами с этой доски. Статья рассматривает топ 10 фич по количеству голосов.

Стилизация полей ввода, 21 голос

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

Visually hidden, 19 голосов

Распространённый паттерн добавления визуально скрытого, но доступного для вспомогательных технологий текста. Разработчики хотят встроенный элемент или атрибут вместо классов visually-hidden или sr-only с хитрым набором свойств.

position: sticky внутри overflow: hidden, 16 голосов

position: sticky работает только внутри элементов с overflow: visible. Ещё с 2017 года просят добавить overflow: hidden, поскольку есть ситуации, когда это нужно.

Анимация height: auto, 12 голосов

Каждый разработчик хотя-бы раз делал аккордеоны и сталкивался с тем, что анимировать высоту произвольного контента height: auto нельзя. В ход шли хаки с max-height и JavaScript. Об этой потребности давно известно и в разработке находится функция calc-size(), которая решает проблему.

Дополнительные типа полей ввода, 10 голосов

На данный момент в HTML есть 22 типа полей ввода и этого не достаточно. Разработчики хотят range с двумя ручками или список с произвольным авто дополнением. Над этим работают в OpenUI, как пример, упомянутые ранее комбобокс и переключатель.

Случайные числа в CSS, 10 голосов

Для реализации анимации иногда хочется настоящих случайных значений, чтобы сделать случайную по времени длительность. Функции, связанные со случайными значениями, находятся в разработке у CSSWG, о чём я недавно делал пост.

Миксины, 7 голосов

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

Глобальные стили в Shadow DOM, 6 голосов

Есть потребность применения глобальных стилей внутри Shadow DOM. Сейчас это просто так сделать нельзя из-за изоляции. Рабочая группа веб компонентов прорабатывает варианты API и ситуации, где это может быть нужно.

Деление разных величин, 6 голосов

Кому-то нужна возможность деления разных величин, например calc(100vw / 1px). Я с такой потребностью не сталкивался, но кому-то это нужно.

nth-letter, 6 голосов

В CSS можно выбрать первую строку или первую букву в строке, но почему-то нельзя выбрать n-ю букву. Это может быть полезно для каких-то красивых типографских эффектов. Оказывается, об этом просят уже 12 лет.

***

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

Alt-текст:

Фото доски с надписью "What's missing from the Web? Take a sticky Note and let us know!“. На доску наклеены стикеры с фичами. У некоторых фич есть круглые наклейки — голоса других участников.

С днём программиста!

Сегодня 256-й день в году, а это значит, что сегодня отмечается день программиста!

Поздравляю подписчиков с профессиональным праздником! Делайте хорошие интерфейсы, а плохие не делайте!
🎉 👩‍💻🧑‍💻

rgb нотации

Вы знаете, что в CSS существует 24 способа задать цвет в пространстве sRGB через rgb/rgba? Зачем так много? Ответ прост: обратная совместимость.

Функция rgb позволяет указать цвет в пространстве sRGB и принимает 3 значения от 0 до 255 для красного, зелёного и синего каналов:

rgb(221, 160, 221)

Количество цвета можно указывать не только от 0 до 255, но и от 0% до 100%:

rgb(87%, 63%, 87%)

Для указания полупрозрачного цвета была добавлена функция rgba с 4-м параметром для альфа-канала от 0 до 1:

rgba(221, 160, 221, 0.3) 
rgba(87%, 63%, 87%, 0.3)

Затем добавили опциональный параметр для альфа-канала в функцию rgb, а у функции rgba четвёртый параметр сделали опциональным. Теперь между ними нет разницы:

rgb(221, 160, 221)
rgba(221, 160, 221)
rgb(221, 160, 221, 0.3)
rgba(221, 160, 221, 0.3)

Потом добавили возможность указывать альфа-канал как в формате 0-1, так и в формате 0%-100%:

rgb(221, 160, 221, 30%)
rgba(221, 160, 221, 30%)
rgb(87%, 63%, 87%, 30%)
rgba(87%, 63%, 87%, 30%)

Как будто этого было мало. Появился новый синтаксис указания цвета без запятых. Старый синтаксис обозначен в спецификации как legacy, но он работает и поддерживается браузерами. Новый синтаксис выглядит так:

rgb(221 160 221)
rgb(87% 63% 87%)

Новый синтаксис поддерживает альфа-канал в формате 0-1 и 0%-100% через / в обеих функциях:

rgb(221 160 221 / 0.3)
rgba(221 160 221 / 0.3)
rgb(221 160 221 / 30%)
rgba(221 160 221 / 30%)

Итого имеем:

rgb(221, 160, 221)
rgba(221, 160, 221)
rgb(87%, 63%, 87%)
rgba(87%, 63%, 87%)
rgb(221 160 221)
rgba(221 160 221)
rgb(87% 63% 87%)
rgba(87% 63% 87%)

rgb(221, 160, 221, 0.3)
rgba(221, 160, 221, 0.3)
rgb(87%, 63%, 87%, 0.3)
rgba(87%, 63%, 87%, 0.3)
rgb(221 160 221 / 0.3)
rgba(221 160 221 / 0.3)
rgb(87% 63% 87% / 0.3)
rgba(87% 63% 87% / 0.3)

rgb(221, 160, 221, 30%)
rgba(221, 160, 221, 30%)
rgb(87%, 63%, 87%, 30%)
rgba(87%, 63%, 87%, 30%)
rgb(221 160 221 / 30%)
rgba(221 160 221 / 30%)
rgb(87% 63% 87% / 30%)
rgba(87% 63% 87% / 30%)

Что из всего этого многообразия использовать? Я бы переходил на функцию rgb и современный формат без запятых и со слешем. Но перечисление параметров через запятую кажется более естественным по аналогии с параметрами функций в JavaScript. Количество цвета удобнее и привычнее указывать в формате 0-255, чем в процентах. К тому же, этот формат используется во многих инструментах. Прозрачность я бы указывал в процентах. Поэтому мой выбор:

rgb(221 160 221)
rgb(221 160 221 / 30%)

Для совместимости можно трансформировать это в старый формат при помощи плагина PostCSS. Но самое главное, чтобы на проекте была консистентность и использовался единый способ указания цветов. В этом могут помочь правила stylelint.

State of HTML 2024

Две недели назад окончился опрос State of CSS 2024, а тут уже объявили о старте опроса State Of HTML 2024. Опрос затрагивает элементы HTML, Web API, Accessibility, Web Components и другие темы.

Вы знаете, что делать 😎

You don't know HTML: кнопки как ссылки

Для создания навигационных ссылок в HTML есть элемент <a>. Но можно ли создать ссылку, используя <button> без JavaScript? Можно! При помощи элемента <form>:

<form>
  <button formaction="/">Главная</button>
  <button formaction="/catalog">Каталог</button>
  <button formaction="/about">О нас</button>
  <button formaction="/delivery">Доставка</button>
</form>

Это работает, потому что кнопка по умолчанию имеет type="submit", что приводит к отправке родительской формы при нажатии. У кнопки указан атрибут formaction, который переопределяет значение action у родительской формы. У самой формы не указан атрибут method, значит по умолчанию используется get. В итоге при нажатии на кнопку будет отправлен get-запрос на соответствующий адрес, что приведёт к загрузке новой страницы.

Ещё можно вынести кнопки из формы при помощи атрибута form, который создаёт связь по id:

<form id="router"></form>

<button form="router" formaction="/">Главная</button>
<button form="router" formaction="/catalog">Каталог</button>
<button form="router" formaction="/about">О нас</button>
<button form="router" formaction="/delivery">Доставка</button>

Не ясно, правда, зачем это всё нужно, если есть <a>. Но просто знайте, что так можно. Иногда в коде можно найти кнопки с обработчиком click и вызовом window.location.href. Вот такие кнопки можно заменить на кнопки с формой, которые будут работать без JavaScrpt. Или это может сгодится для странных вопросов на собеседовании или каких-то ультра-редких случаев.

#ydkhtml

Уменьшение движения

Анимации, движения и плавные переходы — это круто! Пользователи такое любят, если всё работает плавно и не лагает. Но есть пользователи, которые хотят отключить эти анимации по разным причинам. Например, движения на экране могут вызывать головокружение, головную боль и тошноту у людей с некоторыми нарушениями здоровья. Или анимации потребляют CPU/GPU и увеличивают потребление батареи, что нежелательно при малом количестве заряда.

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

Самое простое и быстрое, что можно сделать — это добавить следующий сниппет кода в ваш проект:

@media (prefers-reduced-motion: reduce) {
  @view-transition {
    navigation: none !important;
  }
 
  *,
  ::before,
  ::after {
    animation-delay: -1ms !important;
    animation-duration: 1ms !important;
    animation-iteration-count: 1 !important;
    background-attachment: initial !important;
    scroll-behavior: auto !important;
    transition-duration: 1ms !important;
    transition-delay: -1ms !important;
    view-transition-name: none !important;
  }
}

Этот сниппет отключает View Transition и сводит к минимуму анимации и переходы. Не идеально, но в условиях нехватки времени — хороший компромисс. И это тот случай, когда использование !important уместно.

Если на сайте используются “гифки”, то лучше заменить их на видео. Но если “гифки” есть, можно добавить статическую версию изображения и реализовать переключение при помощи <picture>, <source> и атрибута media:

<picture>
  <source
    srcset="animated-logo.gif"
    type="image/gif"
    media="(prefers-reduced-motion: no-preference)"
  >
  <img src="static-logo.png" alt="Company name" width="80" height="80">
</picture>

Если на сайте есть автоматически воспроизводимые видео, это тоже стоит отключать в режиме уменьшения движения. Можно добавить статическую обложку при помощи атрибута poster, использовать matchMedia и останавливать воспроизведение через JavaScript.

Анимации, реализуемые средствами JavaScript, например, через Web Animation API или библиотеку GSAP, так же нужно отключать или уменьшать. Можно проверять, включён ли режим уменьшения движения при помощи того же matchMedia и реагировать на это соответствующим образом.