JavaScript сломал Интернет (и назвал это прогрессом)

Наткнулся на статью Джоно Олдерсона «JavaScript broke the web (and called it progress)», которая описывает то, о чём я давно думаю. Веб-разработка сместилась в сторону JS, а фреймворки на его основе стали выбором по умолчанию.

Не важно, это интерактивное веб-приложение, блог или интернет-магазин. Инструменты и подходы те же. Обязательно должен быть популярный фреймворк, сборщик, TypeScript, клиентский роутер и SSR с гидратацией, ведь иначе никак.

Мышление «приложениями» приводит к выбору неподходящих инструментов. Проекты усложняются, потребляют больше ресурсов, требуют больше времени на обслуживание и обновление зависимостей, становятся более хрупкими.

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

Основу Интернета всё ещё составляют обычные сайты, которые не должны создаваться как SPA. Лэндинги можно делать на базовых технологиях. Можно даже отказаться от зависимостей и не умереть.

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

#js

Вложенность в CSS

Препроцессоры CSS впервые предложили концепцию вложенности. Правила можно вкладывать в другие правила, а при сборке они объединяются в одно. Особенно хорошо это работает в сочетании с методологией БЭМ, чтобы избежать дублирования.

Вложенность настолько понравилась разработчикам, что её просили внедрить в CSS. Два года назад это произошло. Теперь во всех современных браузерах есть стандартная вложенность, которая скоро получит статус Widely Available.

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

Усложняется поиск и отладка. Поиск по селектору .card__heading из DevTools не даст результатов, потому что в коде он будет записан как &__heading, вложенный в .card. Поиск по &__heading может дать много совпадений в разных блоках.

Стандартная вложенность отображается в DevTools особым образом, не очень удобным для копирования селектора с целью дальнейшего поиска. Зато она работает как есть, не требует компиляции и карт исходного кода (sourcemaps).

Ухудшается читаемость. При глубокой вложенности код уходит вправо. Ситуация аналогична многоуровневой вложенности блоков кода (if, for) или вложенным callback-функциям, что приводит к так называемому callback hell.

Теряется контекст. При большом количестве вложенных блоков код не помещается на экране, поэтому легко потерять контекст блока верхнего уровня. В современных IDE это не так актуально благодаря sticky-строкам.

Недостаточная поддержка. Стандартная вложенность скоро получит статус Widely Available. Но это всё ещё новая возможность, не все версии браузеров это поддерживают. Поэтому код нужно предварительно обработать.

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

Тем не менее, вложенность удобна для медиа-запросов, директив @starting-style, @counter-style и @property, псевдо-классов и псевдо-элементов. Вложенность также полезна для объединения и группировки стилей.

#css

The Grug Brained Developer

Хочу дополнить пост про JS и сложность, который был в понедельник, ссылкой на The Grug Brained Developer. Груг — не очень умный, но опытный разработчик из пещерного века, который рассказывает о сложности в проектах.

complexity bad. complexity very bad. complexity very, very bad

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

Будьте как Груг.

European Accessibility Act в силе

Обычно я не выпускаю посты по выходным, но сегодня особый повод. Сегодня, 28 июня 2025 года, вступает в силу European Accessibility Act — закон о доступности цифровых сервисов и устройств в странах Европейского Союза.

EAA распространяется на широкий спектр продуктов и сервисов:

- Компьютеры: ноутбуки, планшеты, стационарные компьютеры, смартфоны и их операционные системы;
- Терминалы: банкоматы, инфокиоски, вендинговые автоматы, терминалы электронной очереди;
- Связь: VoIP сервисы, мессенджеры, сервисы видео-связи, телефония;
- Телевидение и стриминг: приложения для TV, стриминговые сервисы, онлайн-кинотеатры, видео-сервисы, приставки;
- Транспорт: сервисы покупки и бронирования билетов, терминалы и приложения для оплаты проезда;
- Банки и финансы: банкоматы, банковские сервисы, электронные банкинги, приложения для оплаты;
- Электронное чтение: ePUB файлы, электронные книги, приложения для чтения;
- Электронная коммерция: интернет-магазины, маркетплейсы, торговые площадки;
- Экстренная помощь: сервисы для связи с экстренными службами.

Закон большой и сложный. Но в контексте веба он значит, что если вы разрабатываете сайты или приложения в этих категориях, то они должны соответствовать WCAG 2.1 на уровне AA. В 2026 году ожидается переход на WCAG 2.2.

С применением EAA ожидается рост запросов на доработку веб-сервисов под требования доступности для Европейского рынка. Разработчикам рекомендую подборку ссылок для знакомства с доступной разработкой от Тани Фокиной.

Если вам нужен аудит, консультация или помощь с веб-доступностью, я готов предоставить свою экспертизу: последние 3 года работаю с веб-доступностью в сфере fintech и ecommerce. Обращайтесь в личку: @alexnozer.

#a11y

You don't know HTML: tabindex

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

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

tabindex всё ещё так работает, но индексы больше 0 считаются плохой практикой. Элементы с tabindex больше 0 переносятся в начало последовательности фокусировки и выстраиваются в своём порядке, что нарушают естественный поток.

Это запутывает пользователей, делает клавиатурную навигацию непоследовательной и непредсказуемой. Сегодня tabindex стоит использовать только со значениями -1 и 0 для решения некоторых задач.

tabindex="-1" убирает фокусируемый элемент из последовательности фокусировки, но сохраняет возможность установки фокуса с помощью вызова метода focus() в JS или за счёт атрибута autofocus. Есть два варианта применения:

- Реализация техники roving tabindex — навигации с помощью стрелок внутри виджетов, которые подразумевают такую навигацию;
- Добавление возможности программно сфокусироваться на не фокусируемом элементе. Например заголовке <h1> в SPA или первом элементе <p> внутри модального окна.

tabindex="0" делает изначально не фокусируемый элемент фокусируемым и добавляет его в последовательность фокусировки. Это нужно при создании интерактивных пользовательских виджетов на основе паттернов ARIA с требованиями к клавиатурной навигации.

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

Если вы используете стандартные фокусируемые элементы HTML, не создаёте собственные виджеты на основе ARIA, не реализуете техники клавиатурной навигации и не управляете поведением фокуса из JS, атрибут tabindex вам не понадобится.

#ydkhtml

Web Awesome beta

Вышла первая бета-версия проекта Web Awesome — ребрендинга и следующей мажорной версия библиотеки веб-компонентов Shoelace. Я активно использую её на разных проектах и часто рекомендую. Есть даже соответствующий пост.

Создатель и основной ментейнер Shoelace, Кори ЛаВиска, в 2022 году присоединился к команде Font Awesome — популярной библиотеки иконок. В 2024 году была проведена успешная кампания на Kickstarter по сбору средств на разработку Web Awesome.

Результатом стал полный ребрендинг Shoelace с новым названием, визуальным оформлением и функциями. Web Awesome по-прежнему останется библиотекой с открытым исходным кодом. Всё, что доступно в Shoelace будет доступно в Web Awesome.

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

Из нового: утилиты для раскладки, две новые темы (Default и Web Awesome, старая сохранена под названием Shoelace), стили для стандартных HTML-элементов, визуальные тесты для поддержания консистентности, дополнительные дизайн-токены.

Для поддержания устойчивости проекта появились варианты платных подписок с расширенными функциями:

- Редактор тем. Возможность создать собственную уникальную тему через веб-интерфейс и выгрузить её для использования в проекте;
- Библиотека шаблонов. Набор готовых популярных шаблонов пользовательского интерфейса, собранных из компонентов библиотеки;
- Компонент страницы. Специальный настраиваемый компонент для расположения основных элементов страницы и создания адаптивного макета;
- Иконки Font Awesome. Быстрое добавление в проект иконок Font Awesome Pro при наличии соответствующей подписки;
- Темы и компоненты. Дополнительные темы и компоненты, такие как Data Grid, Chart, Combobox, Date Picker;

На данный момент Web Awesome вышла в стадию публичной беты после этапа альфа-тестирования. Работа продолжается, в том числе некоторые обновления отправляются в текущую 2.x версию Shoelace.

Платные функции и поддержка со стороны Font Awesome делают проект устойчивым. Ядро остаётся бесплатным и с открытым кодом. Разработка на основе веб-стандартов обеспечивает долговечность и совместимость практически с любым стеком.

#ui

Кнопка «наверх»

Один из распространённых паттернов в интернете — кнопка «наверх», которая плавно прокручивает страницу к началу. Обычно для этого используется JS-плагин или пишется небольшой скрипт с вызовом метода scroll* и Web Animations API.

Темани Афиф придумал способ сделать такую кнопку на CSS. Понадобится grid, sticky-позиционирование и немного хитростей. Вот весь код:

<body>
  <div>
    <header id="top">
      <!-- шапка страницы -->
    </header>
    <!-- остальной контент -->
  </div>
  <a href="#top">Наверх</a>
</body>

body {
  display: grid;
  grid-template-columns: auto 0px; 
}

@media (prefers-reduced-motion: no-preference) {
  body {
    scroll-behavior: smooth;
  }
}

a[href="#top"] {
  --offset: 50px; 
  
  position: sticky;
  bottom: 20px;      
  margin-right: 10px; 
  place-self: end;
  margin-top: calc(100vh + var(--offset));
}

В <body> создаётся сетка из двух колонок: для контента и кнопки. Колонка с кнопкой получает нулевую ширину. Кнопка смещается на высоту области просмотра и ещё некоторое дополнительное расстояние. При прокрутке прилипает к нижней части экрана.

Получается то что нужно: вверху страницы кнопка не видна, но появляется при прокрутке на указанное в --offset расстояние и прилипает к нижней части страницы. Саму кнопку при этом можно свободно стилизовать.

В качестве «кнопки» используется элемент ссылки <a> с фрагментом #top. При нажатии браузер прокрутит страницу к элементу с атрибутом id="top", в примере это <header>. Причём не просто прокрутит, а перенесёт туда фокус.

Свойство scroll-behavior: smooth у <body> сделает прокрутку плавной, но только если пользователь не предпочёл уменьшить количество движений в настройках ОС. Пользовательские предпочтения нужно уважать.

Получается вполне интересное, не сложное и функциональное решение для кнопки «наверх» без применения JS. Подробнее о нём можно почитать в статье Темани Афифа «How to Make an Animated Back to Top Button Using Only CSS».

#css #ui

Преимущества доступности для разработчиков

Конечные получатели выгоды от доступности — пользователи с ограниченными возможностями. Но Нолан Лоусон приводит свои эгоистичные причины создания доступных интерфейсов с преимуществами для разработчиков.

Отладка

Когда разметка состоит из <div>-ов с нечитаемыми хэш-классами, в ней трудно ориентироваться и находить нужные элементы при отладке. Семантическая разметка с ARIA-атрибутами более читаемая и удобная для отладки в браузере.

Именование

«Автокомплит»? «Дропдаун»? «Пикер»? Члены команды могут использовать разные названия для UI-элементов. Руководство ARIA предлагает названия для распространённых UI-элементов, чтобы говорить на одном языке.

Состояния

Часто состояния элементов задаются в виде динамически изменяемых CSS-классов: current, selected, has-dropdown. Вместо них можно использовать ARIA-атрибуты: aria-current="page", aria-selected="true", aria-haspopup="true".

Тестирование

В UI-тестировании для поиска элементов используются классы, текст и data-* атрибуты. При семантической разметке c ARIA-атрибутами в качестве якорей можно использовать роли, состояния и свойства элементов. Об этом есть свежий доклад.

Опытные пользователи

Многие профессиональные пользователи используют клавиатуру при взаимодействии с интерфейсом для ускорения работы. Доступные UI-элементы с клавиатурной навигацией позволяют пользоваться интерфейсом быстрее.

***

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

#a11y #ux

Используем новые возможности веба в привычной разработке

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

В докладе освещаются следующие возможности:

- image-set();
- :focus-visible;
- min-content, fit-content, max-content;
- text-wrap: balance;
- Альтернативный текст в content;
- field-sizing: content;
- ::target-text;
- scroll-behavior: smooth;
- scrollbar-gutter;
- View Transitions;
- Intl;
- <dialog>;
- enterkeyhint;
- CSS Nesting;
- LightningCSS, esbuild, Vite;
- P3, oklch().

Что-то из этого не такое новое и уже давно доступно во всех браузерах. Что-то более новое, но может использоваться как прогрессивное улучшение.

#html #css #js #web_api

if() в CSS

Год назад я писал о том, что рабочая группа CSS приняла решение о добавлении функции if(). В недавно вышедшей 137й версии Chrome и Edge появилась поддержка if(). Хотя я скептически отношусь к этому нововведению, оно стоит внимания.

Функция if() позволяет задавать разные значения свойств в зависимости от условий или резервное значение, если ни одно из условий не выполняется. Количество условий не ограничено, а резервное значение не обязательно. Базовый синтаксис такой:

selector {
  property: if(
    condition-1: value-1;
    condition-2: value-2;
    else: value-3
  );
}

На данный момент в качестве условия можно применить одну из трёх функций:

- media() — привычные медиа-запросы, аналогичные директиве @media;
- supports() — запросы поддержки функций, аналогичные директиве @supports;
- style() — запросы стиля, которые недавно стали доступны в рамках директивы @container.

Синтаксис функции if() заменяет директивы @media, @supports и @container в тех случаях, когда нужно использовать другие значения отдельных свойств при выполнении условия директивы. С if() код получается короче:

/* Подход с переопределением */

.card {
  padding: 2rem;
}

@media (width < 600px) {
  .card {
    padding: 1rem;
  }
}

/* Подход с вложенностью */

.card {
  padding: 2rem;

  @media (width < 600px) {
    padding: 1rem;
  }
}

/* Подход с if() */

.card {
  padding: if(
    media(width < 600px): 1rem; else: 2rem
  );
}

Наиболее интересна функция style(), которая позволяет проверять значения стандартных и пользовательских свойств. Так, в зависимости от цвета текста можно менять иконку в компоненте, вроде тоста, примечания или уведомления:

.toast {
  background-image: if(
    style(color: green): url('/success.noscript');
    style(color: orange): url('/warning.noscript');
    style(color: red): url('/danger.noscript');
    else: url('/info.noscript')
  );
}

.toast--success {
  color: green;
}

.toast--warning {
  color: orange;
}

.toast--danger {
  color: red;
}

Все иконки указаны в одном месте и зависят от цвета текста. В противном случае определять иконки нужно у каждого класса-модификатора. Объём кода в обоих случаях будет плюс-минус сопоставимым, но с if() иконки описаны в одном месте.

UPD 03.08.25: style() может принимать обычные свойства, но пока поддерживаются только пользовательские свойства. Пример выше не будет работать.

Пользовательские свойства позволяют определять произвольные характеристики элементов и их значения. Это можно использовать в сочетании с функцией if() для создания различных вариантов компонентов с разными стилями:

.toast {
  background-image: if(
    style(--variant: success): url('/success.noscript');
    style(--variant: warning): url('/warning.noscript');
    style(--variant: danger): url('/danger.noscript');
    else: url('/info.noscript')
  );
  color: if(
    style(--variant: success): green;
    style(--variant: warning): orange;
    style(--variant: danger): red;
    else: lightblue
  );
}

.toast--success {
  --variant: success;
}

.toast--warning {
  --variant: warning;
}

.toast--danger {
  --variant: danger;
}

Все стили тоста определяются в одном месте, а модификаторы задают только значения пользовательского свойства. Это чем-то похоже на пропсы во фреймворках. С if() и обновлённой функцией attr() можно обойтись без модификаторов:

<style>
  .toast {
    --variant: attr(data-variant type(<custom-ident>), default);
    /* свойства с if() */
  }
</style>

<!-- установка --variant через атрибут style -->
<div class="toast" style="--variant: danger">
  <!-- danger тост -->
</div>

<!-- установка --variant через data-атрибут -->
<div class="toast" data-variant="success">
  <!-- success тост -->
</div>

Несмотря на мой скепсис по поводу if(), стилизация компонентов с указанием пользовательских свойств в style или data-* атрибутах и проверкой их значений в одном месте выглядит интересно.

Так как синтаксис if() можно откатить к директивам @media, @supports и @container, его уже скоро можно будет использовать в сочетании с PostCSS или LightningCSS. Пока в них нет соответствующих преобразований, но это лишь вопрос времени.

#css

Bootstrap нового поколения

Две недели назад выкатили бета-версию Web Awesome — новую мажорную версию библиотеки веб-компонентов Shoelace. Я делал пост об этом и в процессе написания у меня возникла мысль, что Web Awesome — это Bootstrap нового поколения.

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

Всё это не привязано к какому-то фреймворку и подключается к сайту с помощью <link> и <noscript>. Есть возможность установки через npm, чтобы собрать и настроить собственную версию с нужными токенами и файлами.

Bootstrap жив и активно развивается, вопреки некоторым мнениям. Текущая версия 5.3.7 вышла 10 июня. В разработке находится 6-я мажорная версия. Bootstrap активно используется: 5.4 млн. установок с npm, не считая загрузок с CDN.

И тут на сцену выходит Web Awesome с утилитами, раскладками, сеткой, шаблонами распространённых элементов интерфейса, интерактивными компонентами, установкой через npm или CDN, возможностью собственной сборки и токенами.

Web Awesome постепенно догоняет Bootstrap по возможностям, но использует более современные возможности браузеров. Это решает некоторые проблемы Bootstrap и делает библиотеку удобнее в использовании.

Вместо копирования вёрстки — пользовательские элементы. Вместо настройки через SCSS — темы на основе пользовательских свойств. Стили компонентов изолированы, никакой борьбы с переопределением.

Поэтому для меня Web Awesome выглядит как Bootstrap нового поколения. В ту же сторону стоило бы двигаться и самому Bootstrap. Посмотрим, каким будет Web Awesome после беты и что выкатят в 6-й версии Bootstrap.

#css #ui

Ссылки, ресурсы и известные личности

Алекс Рассел собрал большую подборку ссылок на руководства, видео, инструменты, блоги компаний и отдельных людей в сфере веб-производительности и веб-стандартов в целом. Доступен OMPL-файл для импорта в RSS-ридеры.

Контент ориентирован на веб-платформу, понимание работы браузеров, производительность, доступность, в общем то, о чём я пишу в этом канале. Если вы искали что почитать и на кого подписаться — это отличная подборка.

#html #css #js #performance #a11y #web_api

Спекулятивная загрузка

Хорошая навигация — это мгновенная навигация. Но перед отображением страницы нужно выполнить сетевой запрос и получить все ресурсы. Чтобы переход был мгновенным, можно «угадать» следующую страницу и загрузить заранее.

На данный момент в браузерах есть следующие способы реализации предварительной загрузки:

- <link rel="prefetch" href="/catalog"> — браузер загружает HTML страницы в фоновом режиме с низким приоритетом, когда сеть не занята загрузкой ресурсов для текущей страницы. Загруженный HTML кэшируется для дальнейшего использования. Но остальные ресурсы (стили, картинки, скрипты) не загружаются и не кэшируются;

- <link rel="prerender" href="/catalog"> — браузер загружает HTML страницы и все ресурсы, а затем рендерит страницу в невидимой вкладке. Это требует больше ресурсов и нагружает сеть, но страница будет полностью отрисована и готова к немедленному отображению, как-будто пользователь её уже загрузил;

- <noscript type="speculationrules"> — новый API с настраиваемыми правилами предварительной загрузки. Позволяет настроить список страниц для загрузки в фоне, загрузку при наведении или касании определённых ссылок, приоритеты и условия предварительной загрузки. Пока только в Chromium-браузерах;

- Service Worker — скрипт, который выполняется в отдельном потоке и перехватывает запросы. При установке Service Worker можно определить набор страниц, загрузить их в параллельном потоке и сохранять в Cache Storage. Затем перехватывать запросы и отдавать из кэша уже сохранённые страницы.

Помимо стандартных возможностей браузеров, есть JS-библиотеки. Google экспериментировал с guess.js и quicklink. У популярных мета-фреймворков и библиотек роутинга часто есть встроенные решения.

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

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

#performance #web_api

Metalsmith

Изучая исходный код одного блога, обнаружил инструмент под названием Metalsmith. Это супер простой, расширяемый генератор статики для Node. Похожий слоган у другого инструмента, который я использую — Eleventy, поэтому Metalsmith меня заинтересовал.

У Metalsmith довольно простая концепция: рекурсивный обход указанной директории и формирование JS-объекта со всеми найденными файлами. Ключ объекта — путь к файлу, значение — объект с мета-данными и содержимым файла.

Далее объект проходит через цепочку плагинов, каждый из которых меняет объект: конвертирует Markdown в HTML, добавляет глобальные мета-данные, применяет layout. Из итогового объекта создаются файлы в указанной директории.

Metalsmith, по сути, ничего особенного не делает. Есть несколько встроенных плагинов. В остальном это конвейер для других плагинов. Концептуально напоминает Gulp или PostCSS, где вся суть заключается в создании цепочки из плагинов для обработки.

Плагинов для Metalsmith много: от небольших утилит до движков шаблонов и CSS-препроцессоров. Так как всё работает на Node, а суть заключается в обходе объекта с файлами, можно легко написать плагин для решения собственной задачи.

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

#js

State of HTML 2025

В начале недели стартовал опрос State of HTML 2025 и я, конечно же, призываю его пройти. Опрос посвящён возможностям HTML и Web API и включает разделы про формы, интерактивность, графику, контент, производительность, веб-компоненты, доступность, системные возможности, использование и мнение.

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

#html #web_api

Openable API

Группа OpenUI продолжает работать над проектированием стандартных возможностей для создания пользовательских интерфейсов. Не так давно на сайте появилось новое предложение под названием Openable API.

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

В интерфейсах часто встречается шаблон, когда элемент скрыт (display: none) и появляется при нажатии кнопки. В качестве примеров виджет показать/скрыть (show/hide, disclosure), древовидный раскрываемый список (tree) или раскрываемые строки таблиц.

Суть таких виджетов можно описать следующим примером кода:

<button 
  type="button" 
  aria-expanded="false"
  aria-controls="details"
>
  Подробнее
</button>

<div 
  id="details"
  role="group"
  hidden
>
  Скрытый контент
</div>

<noscript>
  const button = document.querySelector('button');
  const details = document.querySelector('#details');

  button.addEventListener('click', () => {
    details.hidden = !details.hidden;
    button.setAttribute(
      'aria-expanded', 
      String(!details.hidden)
    );
  });
</noscript>

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

Предлагается новый глобальный атрибут openable. Он делает элемент скрытым по умолчанию, добавляет ему JS-методы openOpenable(), closeOpenable() и toggleOpenable() для программного переключения видимости. Похоже на Popover API.

<button type="button">
  Подробнее
</button>

<div role="group" openable>
  Скрытый контент
</div>

<noscript>
  const button = document.querySelector('button');
  const details = document.querySelector('[openable]');

  button.addEventListener('click', () => {
    details.toggleOpenable();
  });
</noscript>

Чтобы элемент по умолчанию был виден, предлагается ещё один атрибут — defaultopen, который связан со свойством элемента defaultOpen. Установка этого атрибута на элемент или изменение значения свойства на true приводит к переключению.

Вместе с JS-методами предлагается декларативный способ переключения с использованием Command Invokers, о которых я рассказывал. К ним добавляются новые системные команды, что позволяет делать переключение без JS:

<button 
  type="button"
  commandfor="details"
  command="toggle-openable"
>
  Подробнее
</button>

<div id="details" openable>
  Скрытый контент
</div>

Для стилизации предусмотрен псевдо-класс :open, который соответствует элементу в раскрытом состоянии. С псевдо-классом :not() можно будет стилизовать скрытое состояние. Браузеры должны применять следующие системные стили:

[openable]:not([hidden=until-found]):not(:open) {
  display: none;
}

[openable][hidden=until-found]:open {
  content-visibility: revert;
}

Для отслеживания переключения в JS предлагаются события toggle и beforetoggle, как у <dialog> и Popover API. Предусмотрен возврат фокуса при закрытии.

Подумали о поиске на странице, чтобы скрытый контент отображался, если соответствует искомой фразе. Подумали о доступности. Хотя предложение всё ещё находится в стадии раннего черновика.

Для декларативного переключения видимости есть элементы <details>/<summary>, <dialog> и Popover API. Зачем нужен ещё один способ?

- У <details>/<summary> есть встроенная семантика и ограничения по структуре;
- У <dialog> также есть чёткая семантика и поведение вокруг модальности, фокуса, способа закрытия и отображения поверх страницы;
- С Popover API ситуация как у <dialog>, кроме того, что поповером может быть любой элемент.

Openable API применяется к любым (с оговорками) элементам, не добавляет семантику, не отображается поверх другого контента, не вносит сложную модель фокус-менеджмента.

Посмотрим, куда будет двигаться это предложение. Идея в целом классная и полезная. Чем больше будет API с поддержкой декларативности, где браузер забирает на себя часть логики, тем проще и доступнее будет создание интерфейсов.

#html #css #js #ui

px или rem?

Недавно читал статью Стаса Мельникова «Очень вероятно, что эти HTML- и CSS-ошибки есть в вашем коде». В ней среди прочего есть пункт про установку значения font-size для <html> в px. Статья и комментарии натолкнули на давнюю тему px или rem.

Есть мнение, что вместо px нужно использовать rem. Объясняется это улучшением доступности и возможностью изменять значение в одном месте. Кто-то даже предлагает отказаться от px и использовать только rem.

Для справки: rem — относительная единица, которая зависит от значения font-size корневого элемента <html>. px — абсолютная единица, устанавливается как есть. Браузер всё равно пересчитывает rem в px при обработке CSS.

Говоря о доступности, имеют ввиду критерий WCAG 1.4.4 Resize Text. Его суть в том, что должна быть возможность увеличить размер текста на 200% без потери контента и функциональности страницы и без использования сторонних программ.

В настройках браузеров есть возможность изменить размер шрифта. По умолчанию установлено значение 16px, которое применяется к документу и наследуется корневым элементом <html>. Это значение можно увеличить.

Если для корневого элемента не задано свойство font-size или оно задано в %, em или rem, то всё хорошо, значение из настроек будет наследоваться на <html>, а оттуда вниз по дереву. Но если font-size задан в px, настройка не наследуется.

То же касается значения font-size у других элементов. px задаёт конкретное значение, в то время как rem привязывает его к корневому элементу. Чтобы настройка размера шрифта работала, у всех элементов font-size должен быть задан в %, em или rem.

При изменении настройки увеличивается размер текста, но всё остальное (поля, рамки, отступы, размеры иконок) остаётся без изменений. Это выглядит крайне странно и может ломать вёрстку. Отсюда идея использовать rem для всех свойств.

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

Другой способ удовлетворить критерию 1.4.4 — использовать зум. Он есть во всех браузерах и пропорционально увеличивает всю страницу. Технически можно использовать px и всё равно увеличить текст в 2 раза, поэтому rem не обязателен для доступности.

Выводы такие:

- отказ от rem не значит, что сайты будут недоступными, потому что есть браузерный зум;
- если хотите поддерживать настройку размера шрифта, не задавайте font-size у <html> и других элементов в px, используйте %, em или rem

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

- Accessible Font Sizing, Explained
- Accessibility: px or rem?
- Ремы, емы, и почему отказ от них — не проблема

#css #a11y

Нюансы функции style()

Не так давно я писал о новой функции if(), которая появилась в 137й версии Chrome и Edge. В частности, там упоминалась функция style(), с помощью которой можно проверять значения свойств. В посте был такой пример кода:

.toast {
  background-image: if(
    style(color: green): url('/success.noscript');
    style(color: orange): url('/warning.noscript');
    style(color: red): url('/danger.noscript');
    else: url('/info.noscript')
  );
}

.toast--success {
  color: green;
}

.toast--warning {
  color: orange;
}

.toast--danger {
  color: red;
}

Этот пример на данный момент работать не будет! Согласно спецификации CSS Conditional Rules Module Level 5, функция style() может принимать декларации, валидные свойства и пользовательские свойства. Это значит, что color — допустимое значение.

Но на данный момент браузеры поддерживают только пользовательские свойства в style(). Об этом дважды указано в статье про использование контейнерных запросов на MDN: первое упоминание, второе упоминание.

При этом ошибки не будет, применится значение, указанное в блоке else. То есть вне зависимости от значения свойства color, у background-image всегда будет значение url('/info.noscript'). Рабочий пример будет выглядеть так:

.toast {
  background-image: if(
    style(--color: green): url('/success.noscript');
    style(--color: orange): url('/warning.noscript');
    style(--color: red): url('/danger.noscript');
    else: url('/info.noscript')
  );
  color: var(--color, inherit);
}

.toast--success {
  --color: green;
}

.toast--warning {
  --color: orange;
}

.toast--danger {
  --color: red;
}

#css

Пользовательские атрибуты

В HTML есть набор глобальных атрибутов. Например class, id, lang, dir, hidden, translate и так далее. Полный список можно посмотреть в спецификации. Эти атрибуты можно указывать у любых элементов.

Некоторые атрибуты специфичны для конкретных элементов. Например type и value у <input> или scope и colspan у <th>. У таких атрибутов бывают правила использования в сочетании с другими атрибутами.

Стандарт ARIA предлагает набор атрибутов с префиксом aria-* и атрибут role для создания более доступных сайтов. У них есть правила использования и ограничения. В целом их можно отнести к глобальным и задавать на любых элементах.

Когда стандартных атрибутов не хватает, разработчики могут безопасно применять пользовательские атрибуты с префиксом data-*. Кроме того, для работы с data-* атрибутами DOM API предлагает интерфейс dataset.

Некоторые разработчики и авторы библиотек пренебрегают префиксом data-*, аргументируя это лучшим DX. Отчасти это справедливо. С другой стороны, это нарушает стандарт и может привести к долгосрочным последствиям.

При разработке Popover API планировали добавить атрибут popup. Исследование показало, что достаточно много сайтов уже используют атрибут с таким названием, поэтому внедрение popup сломает сайты. В итоге атрибут назвали popover.

Если вы автор библиотеки или просто хотите использовать пользовательский атрибут — добавьте префикс data-*. 5 лишних символов не сильно испортят DX, но предотвратят возможные конфликты и облегчат жизнь авторам стандартов.

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

#html

Анализ производительности сайта Йоркширской воздушной скорой помощи

Гарри Робертс поделился видео с анализом производительности сайта Йоркширской воздушной скорой помощи. За 40 с лишним минут, с помощью DevTools и других инструментов Гарри идентифицировал основные проблемы и дал рекомендации по исправлению.

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

#performance

Семантический HTML и TypeScript

Казалось бы, что может быть общего у семантического HTML и TypeScript? Просматривая один из докладов, услышал интересную аналогию.

Есть TypeScript, который расширяет JS синтаксисом описания типов. Разработчики дают определённым структурам данных «названия», отмечая, что это не случайные данные, а «пользователь», «заказ» или «позиция в корзине».

Грамотная типизация данных даёт ряд преимуществ:

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

То есть разные потребители (IDE, библиотеки, сборщики, компиляторы, линтеры, скрипты) извлекают из типов полезную для себя информацию и что-то на её основе делают.

В TypeScript есть конструкция, наличие которой в коде считается плохой практикой — тип any. Он нужен в некоторых ситуациях, но в основном его использование сводит преимущества TypeScript на нет.

Аналогия с семантическим HTML такая: <div> и <span> в HTML аналогичны any в TypeScript. Если использовать только эти элементы для разметки всего на странице, то получится ничего не значащий, не «типизированный» контент.

Разные потребители (поисковые роботы, режимы чтения, браузерные расширения, средства доступности, парсеры) не извлекут для себя полезную информацию, которую извлекли бы при наличии семантических элементов.

Разница в том, что типы TypeScript более конкретные, в то время как семантика HTML-элементов достаточно абстрактная. Но даже из этого можно извлечь пользу. Есть способы дополнить HTML «типами», но об этом в другой раз.

Это не значит, что нужно заменять любые <div> и <span> чем-то другим. У этих элементов есть назначение, в рамках которого они уместны. Но не стоит использовать только их при наличии подходящих альтернатив.

#html