Вы неправильно загружаете шрифты

Джоно Олдерсон написал исчерпывающую статью «You’re loading fonts wrong (and it’s crippling your performance)» о шрифтах. От исторического экскурса до современных подходов. Советую прочитать статью полностью. Основные принципы кратко:

- Системный стек. Начните с хорошего набора системных шрифтов и используйте пользовательские шрифты как прогрессивное улучшение. Если брендинг не важен, рассмотрите использование только системных шрифтов;

- Нарезка на подмножества. Нарежьте монолитный файл шрифта на несколько подмножеств («бандлов») под разные языки и загружайте только те подмножества, которые нужны на странице;

- Предварительная загрузка и встраивание. Предоставьте браузеру информацию о критических шрифтах как можно раньше с помощью Early Hints, <link rel="preload"> и встраивания @font-face в <style>;

- WOFF2. Используйте шрифты в современном формате woff2, не подключайте в @font-face форматы ttf, otf, eot, noscript. Если необходима поддержка старых браузеров, добавьте к woff2 шрифт в формате woff;

- SVG для иконок. Не используйте иконочные шрифты, такие как Font Awesome для добавления иконок. SVG поддерживается во всех браузерах, хорошо подходит для иконок и позволяет объединить их в один файл (спрайт);

- Вариативные шрифты. Используйте вариативные шрифты, если на сайте требуется тонкая настройка параметров (толщина, наклон, ширина) или используется много вариаций одного шрифта;

- Настройка резервных вариантов. Подберите настройки метрик для резервных шрифтов, чтобы внешне они максимально совпадали с пользовательским шрифтами во избежание прыжков макета при перерисовке;

- Глобальные сценарии. Учитывайте особенности и применяйте индивидуальные оптимизации для арабских языков, языков группы CJK, разных направлений написания и эмодзи;

- Тестирование. Проверяйте поведение и отображение шрифтов на различных устройствах, сетях и языках.

Шрифты — это не украшение, а часть инфраструктуры. Они находятся на критическом пути рендеринга, влияют на метрики LCP и CLS, представляют брендинг и влияют на то, смогут ли пользователи прочитать контент.

#css #performance

Псевдо-кнопки

Марианна Минич пишет:

На какие угодно ухищрения готовы пойти разработчики, лишь бы не использовать семантичную <button> 😅

И сопровождается пост подобным примером:

<div
  tabindex="0"
  role="button"
  class="button"
  (mouseenter)="onMouseEnter"
  (mouseleave)="onMouseLeave"
  (click)="onClick"
  (keydown)="onKeyDown"
  [attr.aria-pressed]="isPressed"
  [attr.aria-label]="label"
  ...
>
  ...
</div>

Подобное периодически встречается в кодовых базах, когда разработчики задумываются о доступности или приходят соответствующие специалисты и просят исправить кнопки. Раз просят, нужно исправлять:

- tabindex="0", чтобы не фокусируемый <div> попал в последовательность табуляции и стал доступен для клавиатуры;
- role="button", чтобы семантически нейтральный <div> попал в дерево доступности как кнопка и корректно обрабатывался вспомогательными технологиями;
- keydown, чтобы нажатия клавиш Enter и Space приводили к нажатию на <div> и вызову события click;
- aria-pressed, чтобы передавать в дерево доступности информацию о том, находится ли кнопка в нажатом состоянии;
- aria-label, чтобы задать кнопке имя для дерева доступности, которое переопределяет текстовый контент внутри (если его нет, как в случае с кнопками-иконками).

Эти манипуляции нужны, чтобы «исправить» кнопки и воспроизвести поведение <button> у <div>. Но это не всё: отправка, сброс и переопределение параметров формы, отключение, управление поповером и вызов команд — это то, что сегодня умеет <button>.

Поэтому просто используйте <button>! Причина создания псевдо-кнопок из <div> в стилизации. У <button> специфические стили, которые отличаются от браузера к браузеру. У <div> таких стилей нет и всё одинаково во всех браузерах.

Вместо написания лишнего JS для воспроизведения поведения у <div>, куда проще сделать сброс стилей у <button>, применив all: unset. Важно вернуть стандартную рамку фокуса (или реализовать свою), так как all: unset сбрасывает её:

button {
  all: unset;
}

button:focus-visible {
  outline: auto;
}

Два CSS-свойства вместо десятков строк кода на JS и полотна из атрибутов в HTML (или директив в шаблоне компонента фреймворка), чтобы получить стилизуемую, семантическую, доступную кнопку со всеми её встроенными возможностями и API.

#html #css #a11y

Современный CSS

Предлагаю запись доклада Адама Аргайла с прошедшего в апреле митапа Smashing Meets CSS. Адам рассказал о 33-х новых возможностях CSS. Практически каждая функция сопровождается демонстрациями на codepen, где можно изучить код и скопировать его в собственные проекты.

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

#css

Меню без скриптов

Я уже писал о CSS-хаках и раскрывал эту тему на примере вкладок на основе ссылок и псевдо-класса :target. Продолжу разбором решения из статьи «меню для отзывчивого интерфейса без скриптов» с очередным хаком.

В этом руководстве мы покажем, как сделать отзывчивое mobile-first меню только с помощью HTML и CSS.

По вводному предложению можно подумать, что статья расскажет о новых Popover и Anchor Positioning, с помощью которых действительно можно создать меню только с помощью HTML и CSS. Но статья про старый добрый хак с флажком.

<!-- Hamburger icon -->
<input class="side-menu" type="checkbox" id="side-menu"/>
<label class="hamb" for="side-menu"><span class="hamb-line"></span></label>
<!-- Menu -->
<nav class="nav">

<label> привязывается к скрытому флажку и меняет его состояние при нажатии. Псевдо-класс :checked позволяет отследить отмеченное состояние флажка и через комбинатор соседства ~ применить стили к нижележащему элементу <nav>.

.side-menu {
  display: none;
} /* Hide checkbox */

/* Toggle menu icon */
.side-menu:checked ~ nav{
    max-height: 100%;
}

Таким меню невозможно воспользоваться с клавиатуры, так как флажок скрыт, а <label> не фокусируемый. Можно скрыть флажок классом visually-hidden и добавить видимый индикатор фокуса, тогда меню можно будет открыть с клавиатуры.

<label> не содержит текста, поэтому у флажка нет доступного имени. Пользователи программ чтения с экрана услышат что-то вроде «checkbox, not checked» и это их только запутает. Также не получиться активировать флажок голосовым управлением.

Доступность — важный аспект веб-разработки. Он гарантирует, что ваш сайт будет удобным для пользователей с ограниченными возможностями. Атрибуты ARIA (Accessible Rich Internet Applications) играют ключевую роль в этом.

В статье есть раздел про улучшение доступности. На <label> установлен атрибут aria-label="Menu", что исправляет проблему с безымянным флажком. Но в этом нет смысла, так как флажок скрыт, а <label> не интерактивный.

Добавлены роли banner и navigation для <header> и <nav>, у которых они встроены по умолчанию. На <nav> установлен атрибут aria-label="Main", a на подменю — aria-haspopup. При этом подменю отображается при ховере и фокусе без передачи соответствующего состояния.

Добавления ARIA-атрибутов не сделало меню доступным. Флажок скрыт и недоступен для клавиатуры, программ чтения с экрана и голосового управления. Не передаётся состояние aria-expanded. Подменю работают при ховере и фокусе. Анимации не сокращены.

Это плохое меню с точки зрения пользовательского опыта и доступности. Стоит ли погоня за реализацией «без JS» сломанного опыта для пользователей? Для меня ответ очевиден: не стоит. Хаки есть хаки, применять их в интерфейсах не стоит.

#html #css #a11y #ui

System design и выбор фреймворков

Недавно прошёл 13й митап сообщества MinskJS, где по традиции было три доклада. Хочу отметить первые два, которые дополняют друг друга. Василий Ванчук рассказал про System Design для фронтендеров, а Анна Ширяева про выбор фреймворков.

Оба доклада так или иначе затрагивают темы кругозора и осознанного выбора инструментов и подходов для решения задачи. Периодически я пишу о выборе неподходящих инструментов и вытекающих из этого последствиях.

#js

You don’t know HTML: виды скриптов

Для добавления скриптов на страницу используется элемент <noscript>. При этом скрипты бывают разных видов, что влияет на их поведение и загрузку.

<noscript>

Классический скрипт. Выполняется сразу же при обнаружении парсером и блокирует его.

<noscript type="not-javanoscript">

Если значение атрибута type не равно одному из MIME-типов JS или одному из ключевых слов, то это блок данных. Код в теле <noscript> не обрабатывается и не выполняется, что можно использовать для хранения данных.

<noscript src="/noscript.js">

Как классический скрипт, но загружается внешний файл. Во время загрузки и обработки парсер блокируется. Тело элемента <noscript> с атрибутом src игнорируется, даже если там JS. Поэтому внутри можно оставить комментарии и пояснения.

<noscript src="/noscript.js" async>

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

<noscript src="/noscript.js" defer>

Атрибут defer не блокирует парсер во время загрузки скрипта, но откладывает выполнение до момента готовности DOM. Отложенные скрипты выполняются в том же порядке, в котором они расположены в HTML, что отличает defer от async.

<noscript src="/noscript.js" async defer>

Если у скрипта одновременно указаны атрибуты async и defer, то defer игнорируется. Поведение будет таким же, как у <noscript src="/noscript.js" async>.

<noscript src="/noscript.js" type="module">

Скрипт с атрибутом type="module" обрабатывается как ES-модуль, где работают операторы import и export. Такие скрипты не блокируют парсер во время загрузки и выполняются по готовности DOM, при этом все зависимые модули должны загрузиться.

<noscript src="/noscript.js" type="module" async></noscript>

Модульный скрипт с атрибутом async и все его зависимые модули загружаются параллельно и не блокируют парсер. Модуль выполнится сразу, как только будет загружена самая последняя зависимость.

<noscript src="/noscript.js" nomodule></noscript>

Атрибут nomodule сообщает браузерам с поддержкой ES-модулей, что скрипт классический и его не нужно загружать и обрабатывать. nomodule используется в сочетании с модульными скриптами для создания резервного варианта для старых браузеров.

<noscript type="importmap">

Атрибут type="importmap" сообщает браузеру, что тело скрипта — карта импортов. Это JSON-объект с псевдонимами путей к модулям, которые используются в операторах import и export. В современных браузерах можно определить несколько карт импортов.

<noscript type="speculationrules">

Атрибут type="speculationrules" сообщает браузеру, что тело скрипта — правила спекулятивной загрузки. Браузеры заранее загружают страницы при выполнении указанных условий, что приводит к мгновенной загрузке страниц и ресурсов.

Атрибуты src, async, nomodule и defer не должны применяться для type="not-javanoscript", type="importmap" и type="speculationrules", поэтому их использование не окажет никакого влияния.

#ydkhtml #js

Web Interface Guidelines

Vercel поделилась списком лучших практик дизайна и разработки веб-интерфейсов. Список разделён на категории: взаимодействие, анимации, раскладка, контент, формы, производительность, дизайн и копирайтинг.

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

Vercel также предлагает готовый файл AGENTS.md с адаптированными для LLM рекомендациями. Его можно использовать для расширения контекста агентов, чтобы они следовали этим практикам при генерации кода.

#ui

Плавающие подписи

В интерфейсах часто встречаются так называемые плавающие подписи (floating labels). Это когда подпись отображается поверх поля ввода как заполнитель (placeholder), а при попадании фокуса плавно съезжает вверх и уменьшается в размерах.

Этот подход стал популярным благодаря дизайн-системе Material Design от Google. Он сохраняется в актуальной на сегодняшний день 3й версии. Его также можно встретить в других дизайн-системах и библиотеках компонентов.

Задумка плавающих подписей — компактность, учитывая что Material Design разработан в том числе для Android. Можно было бы использовать стандартный заполнитель, но это не лучшая идея. Плавающие подписи лучше, чем заполнители.

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

<label for="name">
  Имя
</label>
<input
 type="text"
 id="name"
 autocomplete="given-name"
 autocapitalize="words"
 spellcheck="false"
>

<!--
Имя
[___________]
-->

Недостатки плавающих полей:

1. Структура HTML. <label> нужно размещать после <input> и использовать селектор с комбинатором ~ или +. Или воспользоваться относительно новым селектором :has():

input:is(:not(:placeholder-shown), :focus) + label {
  /* ... */
}
    
label:has(+ input:is(:not(:placeholder-shown), :focus)) {
  /* ... */
}
    

2. Переполнение. Длина подписи может оказаться больше длины поля. Хотя длинные подписи — плохая практика с точки зрения UX, такое иногда встречается. Перенос подписи ломает смещение и перекрывает введённое значение, с overflow: hidden теряется информация, а торчащая за пределы поля подпись выглядит не красиво.

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

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

5. Размер шрифта. Наряду со смещением подписи вверх, также принято уменьшать её размер. Это может привести к слишком мелкому тексту, который трудно читать людям с нарушениями зрения. Увеличение размера текста в настройках либо ни к чему не приведёт, либо сломает плавающие подписи.

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

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

#ux #a11y

Enhanced Range Input

Во всех браузерах уже достаточно давно существует элемент <input type="range">, отображающий слайдер с ползунком для изменения значения в заданном диапазоне. Элемент вполне можно использовать, но есть ряд проблем:

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

Из-за этого стандартный слайдер заменяют JS-библиотеками, вроде noUiSlider. Предложение Enhanced Range Input от OpenUI призвано решить проблемы и предоставить нативное решение.

Дисклеймер: это обзор раннего предложения новых функций. Синтаксис может измениться в будущем или от функций могут отказаться.

Первое предложение связано со спецификацией CSS Form Control Styling, о которой я уже рассказывал. Это возможность включить «базовый» режим для стандартных элементов управления с помощью свойства appearance.

В «базовом» режиме элемент управления получает набор минималистичных стилей, которые стандартизированы и одинаковы для всех браузеров. Также «базовый» режим открывает доступ к новым псевдо-элементам для стилизации внутренних частей.

input[type="range"] {
  appearance: base;
  
  ::slider-track {
    /* Шкала, по которой перемещается ползунок */
  }

  ::slider-fill {
    /* Заполненная часть шкалы */
  }
  
  ::slider-thumb {
    /* Ползунок */
  }

  ::slider-segment {
    /* Часть шкалы между двумя ползунками */
  }

  ::slider-tick {
    /* Засечки при использовании <datalist> */
  }

  ::slider-tick-label {
    /* Подпись засечки при использовании <datalist> */
  }
}

Далее предлагается новый элемент <rangegroup> для создания слайдера с несколькими ползунками. Это контейнер, который оркестрирует элементами <input type="range"> и отображает единый элемент управления.

<rangegroup>
  <legend>Цена</legend>

  <label for="price-min">
    Минимальная цена
  </label>
  <input
    type="range"
    id="price-min"
    name="price-min"
    value="25"
  >

  <label for="price-max">
    Максимальная цена
   </label>
  <input
    type="range"
    id="price-max"
    name="price-max"
    value="75"
  >
</rangegroup>

У элемента <rangegroup> можно указать атрибуты min, max, name, list и stepbetween. Первые четыре работают как у <input type="range">, но определяют общий диапазон. stepbetween задаёт минимальную дистанцию между двумя ползунками.

Атрибуты min, max, value, name и step у <input> будут корректно взаимодействовать с атрибутами у <rangegroup>. Так min и max у <rangegroup> ограничивают min и max у <input>, чтобы они не выходили за пределы диапазона.

Предусмотрена возможность привязки элемента <datalist> с набором <option> к <rangegroup> для создания засечек с подсказками, к которым «магнитятся» ползунки. С псевдо-элементами ::slider-tick и ::slider-tick-label их можно стилизовать.

Промежутки между несколькими ползунками также можно стилизовать, используя новый псевдо-элемент ::slider-segment в сочетании с псевдо-классами :nth-child. Аналогично можно по-разному стилизовать каждый ползунок.

Для работы с диапазонами и несколькими значениями у <rangegroup> будут соответствующие свойства и методы. Никуда не исчезнет API самих элементов <input type="range">, с которыми можно работать, получив их через <rangegroup>.

const rangeGroup = document.querySelector(
  'rangegroup[name="price-range"]'
);

// Получение значений
console.log(rangeGroup.values); 
// [100, 750]

// Получение слайдеров
const inputs = rangeGroup.inputs;
console.log(inputs.length); 
// 2

// Установка значений
rangeGroup.setRangeValue(0, 150);
console.log(rangeGroup.values);
// [150, 750]

Предложение развивается и есть ряд открытых вопросов. Примеры кода и API можно посмотреть в самом предложении. Также автор подготовил прототип в виде веб-компонента и интерактивную площадку с примерами. Ждём реализацию в браузерах.

#html #css #js #ui

Atomic Accessibility

Чарли Триплет создал набор атомарных критериев доступности для дизайнеров, разработчиков, тестировщиков и продуктовых менеджеров. Это своего рода чеклист для проверки доступности, но со своими особенностями.

Atomic Accessibility предлагает атомарный подход к требованиям соответствия. Сначала нужно выбирать роль: дизайнер, веб-, iOS- или Android-разработчик. Для каждой роли есть список элементов с разбивкой по категориям.

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

У каждого элемента есть критерии соответствия. Для дизайнеров — требования WCAG и нарушения, которые затрагивает элемент. Для разработчиков — ожидаемое поведение клавиатуры, скринридеров и настроек системы.

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

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

#a11y

Custom ident и dashed ident

В CSS есть два типа значений: <custom-ident> и <dashed-ident>. Оба типа позволяют создавать произвольные идентификаторы для некоторых сущностей. В отличие от строкового типа, для идентификаторов не требуются кавычки.

<custom-ident> используется для именования счётчиков, ключевых кадров, линий и областей сетки. Это значения list, bounce, logo, nav и search в следующем примере:

ul {
  counter-reset: list;
}

li {
  counter-increment: list;
}

li::before {
  content: counter(list);
}

@keyframes bounce {
  /* ... */
}

.bounce { 
  animation-name: bounce;
  /* ... */
}

.header {
  grid-template-area: 'logo nav search' ;
} 

.header__logo {
  grid-area: logo;
}

.header__nav {
  grid-area: nav;
} 

.header__search {
  grid-area: search; 
}

Тип <dashed-ident> будет знаком по синтаксису пользовательских свойств. Это такой же произвольный идентификатор, но который должен начинаться с двух дефисов --. Не всем нравятся эти лишние символы, но на то есть ряд исторических причин.

Многие новые возможности CSS используют тип <dashed-ident> для именования. Среди них view-transition-name, anchor-name, anchor-target, view-timeline-name, scroll-timeline-name, функции и миксины.

Кевин Пауэлл в видеокасте рассуждает о статье Ромы Комарова об именовании сущностей. Как не запутаться, где нужно использовать <custom-ident>, а где <dashed-ident>? Рома предлагает решение.

Дело в том, что <custom-ident> может содержать в начале два тире, потому что тире — это обычный символ, который разрешён в идентификаторах. Поэтому все пользовательские идентификаторы можно начинать с --.

Тогда не имеет значения, это <custom-ident> или <dashed-ident>, синтаксис будет одинаковый, а запоминать разницу не придётся. Хотя такой подход странновато выглядит в именованных областях и линиях сетки, он имеет право на жизнь.

ul {
  counter-reset: --list;
}

li {
  counter-increment: --list;
}

li::before {
  content: counter(--list);
}

@keyframes --bounce {
  /* ... */
}

.bounce { 
  animation-name: --bounce;
  /* ... */
}

.header {
  grid-template-area: 
    '--logo --nav --search'
   ;
} 

.header__logo {
  grid-area: --logo;
}

.header__nav {
  grid-area: --nav;
} 

.header__search {
  grid-area: --search; 
}

#css

Nerdy Notebook

Адам Аргайл запустил проект Nerdy Notebook, где он собирает различные фрагменты CSS. Так как Адам работал в команде Chrome DevRel и отвечал за контент про CSS и UI, в заметках много современных возможностей.

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

#css #ui

Атрибуты supports и layer для <link>

У элемента <link rel="stylesheet"> можно указать атрибут media с выражением как в директиве @media. Браузер будет проверять медиа-выражение на соответствие текущему окружению, что повлияет на загрузку файла стилей.

<link
  rel="stylesheet"
  href="mobile.css"
  media="(width < 600px)"
>

Если условие не выполняется, файл стилей загружается с низким приоритетом и асинхронно (не блокирует отрисовку), а сами стили не применяются. Эта механика лежит в основе доклада Вадима Макеева «условно адаптивно», о котором я делал пост.

В 496-м выпуске Веб-стандартов слушатель задал вопрос про директиву @import и каскадные слои (@layer). Хочется обернуть стили из внешнего файла в каскадный слой без изменения исходного кода этого файла.

Тут бы пригодился атрибут layer у элемента <link>, который помещал бы загруженные стили в указанный слой. Но такого атрибута на данный момент нет. Единственный способ — использовать директиву @import с layer() внутри элемента <style>:

<!-- атрибут layer не поддерживается
<link
  rel="stylesheet"
  href="utils.css"
  layer="utils"
>
-->

<style>
  @import url('utils.css') layer(utils);
</style>

Браузер загрузит utils.css и поместит его в слой с именем utils, что позволит управлять каскадом: повысить или понизить приоритет всех стилей из этого файла по сравнению со стилями из других слоёв.

Директива @import известна как плохое решение для производительности и многие рекомендуют её избегать. Дело в том, что вложенные @import приводят к последовательной загрузке стилей вместо параллельной.

Не смотря на то, что в файле utils.css могут отсутствовать директивы @import и загрузка должна быть как у <link rel="stylesheet">, всё ещё остаются вопросы к такому методу подключения внешних файлов стилей.

Другая полезная директива — @supports. В теории хотелось бы загружать некоторые стили только при наличии поддержки определённых CSS-функций. Это пригодилось бы для реализации прогрессивного улучшения:

<!-- атрибут supports не поддерживается
<link
  rel="stylesheet"
  href="scroll-animations.css"
  supports="(animation-timeline: scroll())"
>
-->

<style>
  @import url('scroll-animations.css') supports(animation-timeline: scroll());
</style>

В WHATWG есть issue, где обсуждается расширение элемента <link>, чтобы учесть директивы @layer и @supports. Пока решение по этому вопросу не принято, но есть разные идеи того, как это может выглядеть и работать.

#html #css

Будущее фронтенда: хватит ли веб-платформы?

20-21 октября буду на конференции Frontendconf в качестве участника круглого стола на тему «Будущее фронтенда: хватит ли веб-платформы?» Обсудим разработку UI-библиотек, как в этом могут помочь современные возможности веб-платформы, конечно же затронем веб-компоненты и попытаемся заглянуть в будущее. Кто среди подписчиков будет на Frontendconf — приходите послушать нашу дискуссию.

#ui

Scoped Focusgroup

Дисклеймер: это обзор раннего предложения новых функций. Синтаксис может измениться в будущем или от функций могут отказаться.

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

Недавно было опубликовано новое предложение Scoped Focusgroup — следующую итерациею focusgroup. Некоторые идеи оригинального предложения отложили, а остальные немного переработали. Что изменилось:

- Поддержка CSS-свойств отложена на будущее;
- Поддержка навигации по двум осям отложена на будущее;
- Добавлена область действия для управление фокусом только там, где это предполагается исходя из ролей элементов.

В целом синтаксис и поведение атрибута focusgroup и его значений сохраняется (за исключением навигации по двум осям). Но добавляется набор новых значений для определения области действия, которые соответствуют ролям ARIA.

Новый синтаксис выглядит так:

<div focusgroup="<behavior> [inline|block] [wrap] [no-memory]">
  <!-- ... -->
</div>

- <behavior> — роль элемента и поведение фокуса. Принимает значения toolbar, tablist, radiogroup, listbox, menu, menubar, в будущем grid;
- [inline|block] — направление навигации: inline — горизонтально, block — вертикально, зависит от направления письма;
- [wrap] — циклический перенос между крайними элементами. Если значение wrap указано, то перенос включён;
- [no-memory] — сброс последнего сфокусированного элемента при выходе за пределы виджета. Если значение no-memory указано, фокус сбрасывается.

<div
  focusgroup="toolbar inline wrap"
  aria-label="Форматирование текста"
>
  <button type="button">
    Жирный
  </button>
  <button type="button">
    Курсив
  </button>
  <button type="button">
    Подчёркнутый
  </button>
</div>

В примере элемент получает роль toolbar (из значения <behavior>), кнопки удаляются из последовательности табуляции, добавляются обработчики клавиатуры для горизонтальной навигации с переносом между крайними кнопками.

Другие примеры и подробности можно посмотреть в самом предложении. Выглядит многообещающе, а изменения вполне логичные и правильные. Буду следить за развитием дальше и приносить новости.

#html #ui

WCAG 2.2 — международный стандарт ISO/IEC

21 октября Международная организация по стандартизации (ISO/IEC JTC 1) утвердила WCAG 2.2 в качестве международного стандарта ISO/IEC 40500:2025. Это позволит большему числу стран официально принять WCAG 2.2.

Многие страны в той или иной степени используют WCAG разных версий как основу для законов об обеспечении доступности. Теперь они смогут использовать международный стандарт ISO/IEC 40500:2025.

#a11y

Quiet UI

Месяц назад Кори ЛаВиска, создатель библиотеки веб-компонентов Shoelace, объявил у себя в блоге о запуске проекта Quiet UI. Это библиотека из 80+ готовых UI-компонентов, которые выполнены в виде веб-компонентов.

Может возникнуть вопрос: зачем автор создал ещё одну библиотеку веб-компонентов, когда есть Shoelace и Web Awesome? Более того, в Quiet UI используются многие наработки из этих двух проектов.

Как отмечает автор, Shoelace и его наследник Web Awesome — это серьёзные проекты с большим сообществом, командой разработки и финансовой поддержкой. Quiet UI — пет-проект для тестирования идей и творчества.

Quiet UI не конкурирует с Shoelace и Web Awesome, а служит творческой площадкой и испытательным полигоном. Вскоре после релиза автор поменял лицензию на MIT и теперь библиотека доступна как ПО с открытым исходным кодом.

В Quiet UI используются некоторые новые возможности браузеров и есть компоненты, которых нет в Shoelace и Web Awesome. Не исключено что в будущем некоторые из таких компонентов будут адаптированы и перенесены.

В общем интересный проект, который можно использовать как альтернативу Shoelace и Web Awesome. Причём использовать можно с любым фреймворком или без них, так как в этом сила веб-компонентов.

UPD 11.11.2025. Автор в конечном итоге принял решение оставить проект для личного пользования. Поэтому теперь библиотека недоступна для использования и больше не предоставляется как проект с открытым исходным кодом. Все статьи о проекте в блоге удалены.

#ui

Порядок в <head>

Как часто вы заглядываете в <head> ваших проектов и проверяете, что там происходит? А стоило бы периодически это делать, потому что содержимое и порядок элементов могут негативно влиять на производительность.

Начать стоит с валидности. Внутри <head> допустимы только определённые элементы:

- Один <noscript>
- Один <base>
- Ноль и более <link>
- Ноль и более <meta>
- Ноль и более <noscript>
- Ноль и более <style>
- Ноль и более <template>
- Ноль и более <nonoscript>

При обнаружении любого другого элемента парсер немедленно закрывает <head> и переносит оставшиеся элементы в <body>.

<head>
  <meta charset="utf-8">
  <noscript>Мой сайт</noscript>
  <img src="pixel.png">
  <link
    rel="preload"
    href="custom-font.woff2"
    as="font"
    type="font/woff2"
  >
  <link 
    rel="stylesheet"
    href="styles.css"
  >
  <noscript
    src="noscript.js"
    defer
  ></noscript>
</head>
<body>
  <!-- ... -->
</body>

<!-- парсер сделает так: -->

<head>
  <meta charset="utf-8">
  <noscript>Мой сайт</noscript>
</head>
<body>
  <img src="pixel.png">
  <link
    rel="preload"
    href="custom-font.woff2"
    as="font"
    type="font/woff2"
  >
  <link 
    rel="stylesheet"
    href="styles.css"
  >
  <noscript
    src="noscript.js"
    defer
  ></noscript>
  <!-- ... -->
</body>

У этого есть разные последствия, потому что от размещения элементов в <head> или <body> меняется место и приоритет в очереди загрузки ресурсов, статус блокировки парсера, нарушается работа скриптов, завязанных на <head>.

Недопустимые элементы в <head> часто появляются при интеграции различных «пикселей», аналитических фреймов и прочих сторонних вставок. Обычно они представлены элементами <img>, <iframe> и <div>.

Инструкции к таким вставками обычно предлагают вставить сниппет в начало <body>, но нередко они попадают в <head> вместе с элементами <noscript>. Отловить подобные ошибки помогает валидатор HTML.

Другой источник проблем — неверный порядок элементов в <head>. Простая перестановка элементов в нужном порядке может выиграть вплоть до нескольких секунд времени загрузки. Об этом есть отличный доклад Гарри Робертса.

Выявить проблемы с порядком элементов помогут два инструмента:

- ct.css — файл стилей, который делает элементы <head> видимыми и подсвечивает проблемные места;
- capo.js — сниппет, который анализирует содержимое <head> и выводит в консоль текущий и отсортированный порядок.

Отдельного внимания заслуживают менеджеры тегов, через которые на сайты неконтролируемо попадают разные маркетинговые скрипты и засоряют <head>. Подробнее об этом как-нибудь напишу пост.

#html #performance

Релиз Web Awesome

В понедельник я рассказал о проекте Quiet UI, а тут спустя почти 4 месяца бета-теста произошёл официальный релиз другого проекта того же автора — Web Awesome. Это полноценный UI kit на базе веб-стандартов, «Bootstrap нового поколения».

Web Awesome — наследник библиотеки компонентов с открытым исходным кодом Shoelace, которую я часто упоминаю. Проведена работа по улучшению архитектуры и системы темизации, добавлены новые компоненты, утилиты, темы и раскладки.

Web Awesome распространяется по модели freemium. Все базовые компоненты, утилиты, раскладки и 3 темы доступны для использования бесплатно. Всё, что было доступно в Shoelace, бесплатно доступно в Web Awesome.

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

В честь релиза предлагается пожизненная скидка 20% на подписку Pro до 19 ноября.

#ui

Toolbar Elements

Члены группы OpenUI продолжают работать над UI-примитивами и опубликовали черновик предложения Toolbar Elements. Они предлагают добавить в веб-платформу встроенное решение для создания панели инструментов.

Такие панели встречаются во многих веб-приложениях: Google Docs, Figma, VSCode, Notion, Photoshop Web и так далее. Панель инструментов группирует кнопки, списки выбора, переключатели и другие интерактивные элементы интерфейса.

Сейчас для создания панели инструментов нужно использовать ARIA-роль toolbar. В спецификации ARIA также пишется, что у элемента с ролью toolbar можно реализовать управление фокусом, что подразумевает навигацию стрелками.

Дисклеймер: это обзор раннего предложения новых функций. Синтаксис может измениться в будущем или от функций могут отказаться.

Предлагается новый элемент <toolbar>, в который будет встроена роль toolbar и навигация по интерактивным элементам с помощью стрелок. По умолчанию <toolbar> отображает элементы горизонтально.

<toolbar aria-label="Main">
  <button
    id="undoButton"
    aria-label="Undo"
  >
    <img src="..." alt=""> 
  </button>
  <button
    id="redoButton" 
    aria-label="Redo"
  >
    <img src="..." alt="">
  </button>
  <button
    id="printButton"
    aria-label="print"
  >
    <img src="..." alt="">
  </button>
  <input
    id="zoomSelect"
    list="zoom"
    aria-label="zoom"
  >
  <!-- ... -->
</toolbar>

<datalist id="zoom">
  <option>Fit</option>
  <option>50%</option>
  <!-- ... -->
</datalist>

<noscript>
  undoButton.addEventListener("click", 
    () => undo();
  );
  // ...
</noscript>

Есть открытые вопросы о том, как должен стилизоваться <toolbar>, как должно работать изменение ориентации (для вертикальной панели инструментов) и нужно ли поддерживать внутри разделители (как <hr> внутри <select>).

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

#html #ui

Negative border radius

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

Есть разные хаки с абсолютно позиционированными элементами-масками. В целом вёрстка таких блоков — задача непростая. Но ребята из HTML Academy выкатили решение — библиотеку nebo.css.

Nebo — сокращение от negative border radius, как часто называют подобные эффекты. Это CSS-файл на 100 с лишним строчек кода, который предоставляет несколько классов и пользовательские свойства для точечной настройки.

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

Для использования достаточно подключить nebo.css к проекту или просто скопировать код и вставить в файл стилей. Далее к элементу, у которого нужно сделать вырез, добавляется класс nebo и модификатор стороны, с которой нужен вырез:

<link rel="stylesheet" href="nebo.css">

<!-- br - сокращение bottom right -->
<div class="card nebo nebo--br">
  <!-- контент карточки -->
</div>

Доступны модификаторы для четырёх сторон:

- .nebo--tl — top left
- .nebo--tr — top right
- .nebo--bl — bottom left
- .nebo--br — bottom right

Логические свойства не завезли, но это отличный повод сделать pull request. Также есть ограничение, что одновременно на элементе можно сделать только один вырез. Если нужно несколько вырезов, то придётся использовать обёртки.

Далее у элемента с вырезом можно точечно настраивать параметры с помощью пользовательских свойств:

- --nb-r — радиус всех трёх скруглений
- --nb-w — ширина выреза
- --nb-h — высота выреза

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

Подробнее о библиотеке рассказывает Александр Першин в видео Вогнутые углы за пару строк CSS из рубрики CSS Боль. Также есть интерактивная песочница, где пошагово демонстрируются возможности библиотеки.

#css

Alt изображения: четыре квадратных блока с фиолетовым градиентным фоном расположены по два в ряд. У каждого блока есть вырез со скруглёнными углами. У первого блока квадратный вырез в левом верхнем углу. У второго блока вытянутый прямоугольный вырез в правом верхнем углу. У третьего блока вытянутый прямоугольный вырез в левом нижнем углу. У четвёртого блока квадратный вырез в правом нижнем углу.