You don't know HTML: Exclusive Accordion

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

Члены группы OpenUI внесли предложение под названием Exclusive Accordion. Его суть в возможности объединения нескольких элементов <details> в группу для реализации аккордеона. Браузеры уже поддержали и внедрили это предложение. Если добавить к нескольким <details> атрибут name с одинаковым значением, то они объединяются в группу и начинают работать как аккордеон.

<details name="faq">
  <summary>Доставка</summary>
  <p>Информация о доставке...</p>
</details>
<details name="faq">
  <summary>Оплата</summary>
  <p>Информация об оплате...</p>
</details>
<details name="faq">
  <summary>Возврат</summary>
  <p>Информация о возврате...</p>
</details>

В таком варианте только один <details> может быть раскрыт одновременно. Элемент вполне хорошо стилизуется и есть способы анимировать высоту в CSS (а скоро появится прямое решение для этого). Поэтому его можно использовать вместо сторонних плагинов и компонентов. Меньше стороннего кода — лучше производительность и проще поддержка.

Эксклюзивный аккордеон поддерживается во всех современных версиях браузеров. Если атрибут name не поддерживается, то <details> сам по себе работает как раскрывающийся блок и всё будет работать, но можно будет раскрыть все блоки. Важно, что вёрстка от этого не сломается. Прогрессивное улучшение! Если хочется, чтобы работало и в более старых браузерах, можно добавить очень лёгкий скрипт-полифилл:

document.querySelectorAll("details[name]").forEach(($details) => {
  $details.addEventListener("toggle", (e) => {
    const name = $details.getAttribute("name");

    if (e.newState == "open") {
      document
        .querySelectorAll(`details[name=${name}][open]`)
        .forEach(($openDetails) => {
          if (!($openDetails === $details)) {
            $openDetails.removeAttribute("open");
          }
        });
    }
  });
});

#ydkhtml

Стилизация нативных тултипов

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

- Невозможно стилизовать
- Большая задержка появления
- Не появляются при фокусе
- Не зависят от размера шрифта элемента и настроек шрифта в браузере
- Нельзя выделить текст
- Не закрываются по Esc

На протяжении многих лет поднимался вопрос о том, что делать с noscript. Стоит отдать должное команде Edge, они добавили закрытие тултипа по Esc и отображение при фокусе. Это шаг вперёд, но этого мало.

Летом 2023 Лия Веру предложила добавить новый псевдо-элемент ::tooltip с возможностями стилизации стандартных тултипов. После некоторых обсуждений, предложение было утверждено. То есть в какой-то момент появится возможность стилизовать тултипы, создаваемые атрибутом noscript.

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

Как должен работать <selectedoption>?

Стилизуемый <select> всё ближе к тому, чтобы заехать в браузеры. За флагом его уже можно пощупать в Chrome Canary 130. Я рассказывал ранее о разработке этого API.

Джейк Арчибальд написал статью, в которой размышляет о том, как должен работать новый элемент <selectedoption>. Он является частью нового API для стилизации <select> и предназначен для отображения выбранного <option>. Джейк запрашивает фидбэк, который он представит на встрече OpenUI.

Результаты State of CSS 2024

21 августа я призывал пройти опрос State of CSS. А сегодня, 21 октября, я уже публикую пост с обзором результатов. В этом году как-то быстро они.

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

Среди 6025 ответивших у 17% есть когнитивные нарушения, у 6% нарушения зрения, у 3% нарушения слуха, у 3% нарушения мобильности, у 2% прочие нарушения. Это очередной раз показывает, что доступность крайне важна, а пользователей с теми или иными нарушениями не так уж и мало.

К фичам. Людям очень нравится селектор :has(). Несмотря на поддержку, его использовало 72.9% опрошенных. Другую свежую фичу — Container Queries, использовало всего 31.3%. Люди экспериментируют с новыми возможностями, которые ещё не доступны во всех браузерах: Anchor Positioning — 4.8%, @scope — 4.8%, Style Queries — 5.4%, Scroll-driven Animations — 6.3% + 2.33%. Применение новых возможностей CSS растёт.

Топ-10 фич, которые участники сохраняли в список для чтения, для меня это повод рассказать о них позже:

1. hanging-punctuation
2. offset-path
3. @scope
4. Anchor Positioning
5. view-timeline
6. scroll-timeline
7. Discrete Properties Animations
8. image()
9. nth-child of S
10. light-dark()

Среди CSS-библиотек лидирует Tailwind CSS. На втором месте старичок Bootstrap. Замыкает тройку Ant Design. В списке также много специфичных для фреймворков библиотек компонентов.

В мире CSS-in-JS в лидерах CSS Modules. Styled Components всё ещё держатся. Затем идёт Emotion.

Среди пре- и пост-процессоров первое место занимает Sass/SCSS. На втором месте PostCSS. Less на третьем месте. Интересно, что Stylus всё ещё используется.

В утилиты напихали всего подряд. Но в топе стандартные инструменты, которые есть на большинстве проектов: Prettier, Autoprefixer и Stylelint. В списке также есть минификаторы cssnano и PurgeCSS. Для себя я открыл Project Wallace, никогда до этого о нём не слышал, выглядит круто на первый взгляд.

По браузерам всё стандартно, люди в основном работают в Chrome, Firefox и Safari. Довольно сильно взлетел Arc, обогнав Brave и Vivaldi, приблизившись к Edge. В списке есть специализированный браузер для разработчиков и тестировщиков — Polypane. Ну и посочувствуем тем 64 бедолагам, которым приходится работать с IE11.

Рад видеть, что разработчики всё больше тестируют сайты при помощи клавиатуры, специальных плагинов (Axe, Lighthouse) и скринридеров.

Сравнивая баланс между написанием CSS и JS, бросается в глаза большой процент людей, которые в основном пишут JS и немного CSS. Это объясняется тем, что многие разрабатывают веб-приложения и работают с экосистемой JavaScript-фреймворков. Если говорить о медиане, то она находится на отметке 50%-50%.

Интересно посмотреть, чего разработчикам не хватает в CSS, топ-5 выглядит так:

1. Mixins
2. Conditional Logic
3. Masonry Layout
4. Parent Selector
5. CSS Nesting

Самая большая боль разработчиков при работе с CSS — браузерная поддержка. Затем, внезапно, Tailwind. На третьем месте чрезмерная сложность. Стоит отметить, что на вопрос ответило всего 1090 участников. Это может говорить о том, что в целом остальных всё устраивает.

Удовлетворение развитием веб-технологий в целом осталось неизменным с 2021 года, а вот удовлетворение развитием CSS увеличилось в этом году.

Рад видеть “Веб-стандарты” на втором месте в списке подкастов. Хорошее достижение для русскоязычного подкаста в, по большей части, англоязычном опросе.

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

You don't know HTML: noscript и блок данных

Как известно, элемент <noscript> предназначен для выполнения встроенного или внешнего JavaScript-кода. Но на этом его применение не ограничивается.

У элемента <noscript> есть атрибут type, который принимает MIME-тип. Если атрибут type указан и его значение не равно module, importmap или text/javanoscript, то <noscript> определяет блок данных. Это можно использовать для встраивания любых данных в текстовом формате для их дальнейшего использования в клиентских скриптах.

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

<noscript id="data" type="application/json">
{
  "data": {
    "user": {
      "name": "Алексей"
      ...
    }
  }
}
</noscript>

Помимо JSON, можно встраивать любые другие текстовые данные: YAML, TOML, XML, HTML, SVG, CSV, Markdown, AsciiDoc, LaTeX, обычный текст и т.д. Но нужно быть осторожным с XML-подобными форматами, потому что некоторые сочетания символов внутри <noscript>, например <!--, <noscript или </noscript могут привести к непредсказуемому поведению.

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

#ydkhtml

<html->

Обнаружил забавный проект <html->, где автор в качестве эксперимента пытается максимально точно реплицировать существующие HTML-элементы с помощью API веб-компонентов. Названия элементов используются стандартные, но с дефисом в конце, так как пользовательские элементы должны содержать минимум один дефис в названии. При этом дефис в конце — валидное имя пользовательского элемента.

При воссоздании элементов автор учитывает стандартные стили браузера, семантику, атрибуты, свойства и поведение. Если с элементами вроде <abbr-> или <b-> все довольно просто, то вот с элементами <a-> или <button-> всё уже намного сложнее. Даже у элемента <aside-> есть подводные камни, связанные с семантикой, которая зависит от родительских элементов.

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

<html-> A forward thinking custom elements library that you probably shouldn’t use.
Like actually. As an exercise of seeing how much we can do with the Web Components APIs, this is an attempt to re-implement much of HTML with it.

Еще я вижу тут отсылку к библиотеке Shoelace, про которую я как-то рассказывал. Потому что её слоган звучит так:

A forward-thinking library of web components.

Тем не менее, проект <html-> интересен тем, что раскрывает возможности стандартных HTML-элементов и показывает их реализацию на JavaScript. У некоторых элементов много скрытых возможностей под капотом, которые нужно будет повторить. Лично мне интересно будет взглянуть на реализацию таких элементов, как <input>, <select> или <link>.

Также это хороший пример того, сколько всего нужно реализовать, когда разработчики по каким-то причинам отказываются от стандартных элементов, например <a>, и пытаются "повторить" с помощью <div role="link" tabindex="0"> и JavaScript.

Ну и проект может послужить примером использования API веб-компонентов и как далеко автор сможет зайти с ними. Это является главной целью проекта.

Интерфейс оценки

Интерфейс оценки в виде звёзд, он же звёздный рейтинг, достаточно распространён. Обычно это 5 серых звёзд, расположенных горизонтально. Нажатие на звезду закрашивает её и все предыдущие. Выбор первой звезды — оценка 1 из 5, выбор последней звезды — оценка 5 из 5. Стандартный паттерн.

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

Можно по ошибке или случайности нажать не ту звезду, а отменить это уже нельзя. Хороший интерфейс оценки, на мой взгляд, предлагает звёзды, текст "ваша оценка X из Y" и кнопку подтверждения. Выбор звезды не должен быть конечным и необратимым действием. Пользователь может подумать над оценкой и подтвердить её, когда будет готов. Ещё хорошо предоставить вторую кнопку “Не сейчас”, так как пользователь не всегда готов что-то оценить в данный момент.

Хорошие формы

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

- Хорошие формы работают без клиентского JavaScript
- Хорошие формы всегда отправляются
- Хорошие формы запоминают значения и показывают сообщения об ошибках
- Хорошие формы логина взаимодействуют с менеджерами паролей
- Хорошие формы используют элемент <form>
- Хорошие формы используют подходящие типы полей
- Хорошие формы имеют понятные подписи для полей и кнопок
- Хорошие формы имеют состояние :focus
- В хороших формах логичная последовательность табуляции
- Хорошие формы позволяют вставлять данные из буфера обмена
- Элементы хороших форм используют атрибут inputmode
- Элементы хороших форм используют атрибут autocomplete
- В хороших формах поиска элемент <form> вложен внутрь элемента <search>
- Хорошие формы можно сбрасывать с помощью <button type="reset">
- Хорошие формы работают с formData
- Хорошие формы не используют placeholder в качестве подписи
- Хорошие формы работают на мобильных телефонах
- Хорошие формы не всплывают и не запрашивают персональные данные
- Хорошие формы не слишком большие и спрашивают только о самом необходимом
- Хорошие формы используют HTTPS
- Хорошие формы используют подходящие методы HTTP
- Хорошие формы проверяются на клиенте и на сервере
- Хорошие формы проверены с помощью скринридера перед отправкой в прод
- В хороших формах четко обозначены обязательные поля
- Хорошие формы предупреждают о деструктивных и дорогостоящих действиях
- Хорошие формы заставляют младенца Иисуса улыбаться (ориг. make the baby Jesus smile)
- Хорошие формы аутентификации используют сгенерированный сервером одноразовый код nonce
- Хорошие формы проверяют состояние сети при помощи navigator.onLine перед отправкой
- Хорошие формы используют accent-color для стилизации, если этого достаточно
- В хороших формах пользовательские элементы управления не приветствуются и должны быть удалены при первой возможности

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

Улучшения <details>

Недавно я рассказывал о способе создания аккордеонов при помощи элементов <details> и <summary>. Но всё ещё есть некоторые шероховатости при стилизации этих элементов. Команда Chrome в 131-й версии внедряет ряд доработок, которые сглаживают их.

Установка display для <details>

Сейчас установка свойства display со значениями flex или grid для <details> не влияет на отображение. Это ограничивает возможности стилизации. Доработки устраняют ограничения, flex и grid будут работать.

Псевдо-элемент ::details-content

На данный момент нет способа стилизовать контейнер с контентом, который на самом деле есть в Shadow DOM внутри <details>. Это можно решить добавлением обёртки <div>. Новый псевдо-элемент ::details-content позволит стилизовать существующий под капотом контейнер с контентом без добавления обёртки.

Анимации дискретных свойств

Новые функции CSS calc-size(), intetpolate-size: allow-keyword и content-visibility напрямую не относятся к доработкам <details>, но добавляют новые возможности к настройке анимации. Можно будет анимировать свойство display: none, width: auto и height: auto.

***

Пока только Chrome, но я думаю, что другие браузеры тоже скоро подтянутся.

<datagrid>, который мы потеряли

В недавнем опросе State of HTML был вопрос “если бы вы могли добавить 3 элемента в HTML, что бы это было”. На выбор предлагалось 11 фиксированных вариантов и поле со свободным вводом. Один из вариантов — Data Table with sorting, filtering, etc. Этого элемента чертовски не хватает тем, кто разрабатывает современные бизнес-приложения, где всегда есть интерактивные таблицы с данными.

Разработчикам приходится подключать сторонние библиотеки с таблицами, зачастую очень тяжёлые. Или реализовывать нетривиальную функциональность таблиц самостоятельно. Для специалистов по доступности это тоже вызов, потому что у интерактивных таблиц сложная модель взаимодействия со вспомогательными технологиями. Взгляните на документацию от WAI:

- общее описание паттерна
- свойства таблиц
- пример реализации

Пример WAI достаточно базовый, в реальных приложениях таблицы сложнее. Забавно, что у WAI есть пример сложной интерактивной таблицы, но это страница-заглушка без контента. До недавнего времени некоторые разделы про таблицы содержали пометки TODO. То есть даже в WAI ещё не до конца решили все вопросы с таблицами.

Было бы здорово, чтобы ребята из WHATWG, CSSWG, WAI и браузеров собрались и сделали классный примитив для интерактивных таблиц. Тем временем я обнаружил кое что интересное в первом или одном из первых черновиков спецификации HTML5 от 22 января 2008 года. Это элемент <datagrid>:

The datagrid element represents an interactive representation of tree, list, or tabular data.

<…>

In the datagrid data model, data is structured as a set of rows representing a tree, each row being split into a number of columns. The columns are always present in the data model, although individual columns may be hidden in the presentation.

В далёком 2008 году (почти 17 лет назад) в спецификацию добавили элемент, который представляет интерактивные таблицы и деревья. Согласно спецификации, в <datagrid> можно было вкладывать <table>, <ol>, <select>, <datalist> и другие. В зависимости от вложенных элементов, менялось поведение <datagrid>. Элемент предлагал методы для работы с данными: получение количества строк и столбцов, сортировка столбцов, выделение и редактирование ячеек, контекстное меню строки и т.д.

Мощнейшее предложение, которое удалили из черновика в 2009 году. Представить только, если бы браузеры реализовали это… Кто знает, может быть в ближайшем будущем к <datagrid> вернутся.

Делать ли ещё посты с обзором подобных находок из прошлого?

Результаты исследований

На прошлой неделе были опубликованы два исследования: результаты опроса State Of HTML 2024 и отчёт Web Almanac 2024.

State Of HTML — это опрос среди разработчиков, который проводится с 2023 года. State Of HTML посвящён HTML, браузерным API, веб-компонентам, доступности и веб-приложениям. Я делал разбор результатов за 2023 год: часть 1 и часть 2.

Web Almanac — это проект HTTP Archive по исследованию состояния веба. Отчёт выходит раз в год, крайний был опубликован в 2022 году. В 2023 году отчёта не было и вот вышел отчёт за 2024 год. Он пока включает не все разделы, но кое что уже можно посмотреть. Web Almanac хорош тем, что собирает данные с миллионов сайтов в интернете и показывает реальное состояние веба. В этом он отличается от того же State Of HTML, который проводится среди активных и осведомлённых разработчиков.

Я планирую детальнее разобраться с результатами и сделать несколько постов с выводами по конкретным направлениям. А пока можете ознакомиться с результатами по ссылкам:

- State Of HTML 2024
- Web Almanac 2024

Синтаксис Custom Properties

Возможно, вы задавались вопросом: почему у custom properties такой странный синтаксис с двумя дефисами в качестве префикса? Почему не использовали символ $, # или какой-то ещё? Всё дело в парсере CSS. Он давно написан, обрабатывает миллиарды сайтов и ломать его не хочется.

Если у custom properties не будет префикса, возникнут конфликты со стандартными свойствами. Символ @ зарезервирован для медиа-выражений и его использование привело бы к неоднозначным ситуациям парсера. Другие символы не поддерживаются, так как свойства могут начинаться только с буквы или тире.

Парсер умеет разбирать вендорные свойства, например:

-webkit-appearance

Они начинаются с дефиса, затем идёт название вендора, затем ещё один дефис и далее название свойства. А если в качестве названия вендора использовать пустую строку?

--appearance

Парсер обработает это как вендорное свойство без имени вендора. Вот и получился синтаксис custom properties, который использует существующий алгоритм парсера и не нарушает синтаксис свойств CSS. По сути, custom properties — это ваши собственные "вендорные" свойства.

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

Результаты State of HTML 2024

Без лишних предисловий обзор результатов State of HTML 2024.

Демография

В опросе приняло участие 5402 человека, из которых 58% прошли опрос практически полностью. Аудитория достаточно взрослая и опытная: медианный возраст — 35 лет, а опыт — 15 лет. Эти цифры выше, чем в State of CSS и State of JS. 1248 человек отметило те или иные нарушения здоровья.

Список для чтения

Топ 5 фич из список для чтения: Customizable Select, focusgroup attribute, Popover API, EditContext и CSS Custom Highlight API. Интересно, что в опросе были фичи, находящиеся на стадии разработки: DOM Parts, HTML Modules, focusgroup attribute.

Формы

Основные боли, связанные с формами: проблемы со стилизацией и баги элементов форм, валидация, браузерная поддержка и обработка форм. Людям нравится <datalist>, стилизуемый <select> и autocomplete, но многие отмечают наличие проблем с ними.

Интерактивность

Больше всего болей с интерактивностью связано с браузерной поддержкой, элементом <dialog>, анимациями, Popover API и стилизацией. <dialog> и Popover API нравятся людям, но обладают ограниченной браузерной поддержкой.

Контент

При работе с контентом больше всего болей с SVG, менеджментом изображений, интернационализацией, <iframe> и браузерной поддержкой. Content Security Policy и атрибуты изображений srcset и sizes вызывают негативный опыт.

Веб-компоненты

Основные боли при использовании готовых веб-компонентов: стилизация и кастомизация, Shadow DOM, SSR, совместимость с React и доступность. Что касается болей при разработке веб-компонентов, то в топе Shadow DOM, стилизация и кастомизация, чрезмерная сложность и многословность, браузерная поддержка. Shadow DOM и связанные с ним особенности — главная проблема веб-компонентов. Интересно, что среди фреймворков для разработки веб-компонентов на первом месте Svelte.

Доступность

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

Нативные веб-приложения

Из 3560 ответивших, 55% используют JS-фреймворки для разработки нативных приложений, 38% используют нативные и не связанные с JS технологии. Больше всего болей с проблемами на Apple/iOS, проблемами PWA, браузерной поддержкой, пользовательским опытом и производительностью.

Инструменты

Самый популярным генератор сайтов — Next.js, за ним Astro, Nuxt, SvelteKit и Eleventy. Самые популярные валидаторы — W3C Validator и Validator.nu HTML Checker, хотя это одно и то же. Интересно, что больше половины ответивших не используют валидаторы вообще. Среди инструментов производительности в топе Lighthouse, Devtools, PageSpeed Insights, WebPageTest и Pingdom. Для аналитики больше всего используют Google Analytics, Matomo, Datadog, New Relic и Plausible Analytics. Среди браузеров картина стандартная, но интересно разнообразие. Среди ресурсов лидер — MDN, за ним идут Can I Use, Web.dev, W3C и блог WebKit.

Использование

Топ 5 фич, которые разработчики не могут использовать из-за ограниченной поддержки: Popover API, Anchor Positioning, ViewTransition API, <dialog> и PWA. Среди элементов с недостаточной функциональностью <select>, <input type="date">, <dialog>, <datalist> и <details> + <summary>. Список недостающих в HTML элементов не изменился с прошлого года, в топе Data Table, Tabs, Switch, Skeleton, Context menu. Чаще всего HTML используют для веб-приложений, контентных сайтов, маркетинговых сайтов, дизайн-систем и email.

Мнения

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

***

Вот таким был State of HTML 2024. Посмотрим, что изменится в следующем году. А пока предлагаю пройти опрос State of JS 2024, который идёт прямо сейчас.

You don't know HTML: autocomplete

Атрибут autocomplete устанавливается у элементов <form>, текстовых полей ввода <input> и <textarea>. Это подсказка для браузера, какие данные ожидаются в полях. Это именно подсказка, полного контроля нет. Браузер сам принимает итоговое решение на основании множества факторов.

Типы полей <input>, значения атрибутов name и id, текст в <label> и placeholder, соседние элементы, иногда даже значения в атрибуте class и некоторые предположения использует браузер, чтобы вычислить данные, потому что формы не всегда спроектированы хорошо. Есть доклад и статья от разработчиков Яндекс Браузера о том, как работает автозаполнение. Так как Яндекс Браузер основан на Chromium, это справедливо для всех браузеров на этом движке. В других движках механизмы схожие.

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

<form action="/register" method="post">
  <label for="firstname">Имя</label>
  <input type="text" id="firstname" name="firstname" autocomplete="given-name">
  <label for="lastname">Фамилия</label>
  <input type="text" id="lastname" name="lastname" autocomplete="family-name">
  <label for="phone">Телефон</label>
  <input type="tel" id="phone" name="phone" autocomplete="tel">
  <label for="email">Email</label>
  <input type="email" id="email" name="email" autocomplete="email">
  <label for="name">Пароль</label>
  <input type="password" id="password" name="password" autocomplete="new-password">
  <button>Создать аккаунт</button>
</form>

У autocomplete не очень много значений, но они покрывают наиболее распространённые сценарии форм: логин, регистрация, оформление заказа, обратная связь. Не исключено, что в будущем появятся новые значения. Например, не так давно было добавлено значение webauthn для Web Authentication API.

В качестве значений можно использовать несколько токенов для разграничения, например, адреса доставки и адреса выставления счёта:

<label for="shipping">Адрес доставки</label>
<input type="text" id="shipping" name="shipping" autocomplete="shipping street-address">
<label for="billing">Платёжный адрес</label>
<input type="text" id="billing" name="billing" autocomplete="billing street-address">

Аналогично можно помечать домашний, рабочий и мобильный телефоны (home tel, work tel или mobile tel). Можно добавлять секции (section-*) для разделения комплексных форм, где есть разделы или динамические группы полей.

Если форма размечена корректно, используется autocomplete и у браузера достаточно данных, то он может заполнить всю форму в один клик. Это очень удобно, особенно на мобильных устройствах. Для максимальной точности советуют использовать распространённые значения для атрибутов name и id, соответствующие типы полей и autocomplete одновременно.

Для отладки автозаполнения форм в Chrome 124 добавили новую панель Autofill. Туда можно добавить разные данные и отлаживать, как форма будет заполняться.

#ydkhtml

Зум полей ввода на iOS

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

“Баг” происходит, когда у текстовых полей ввода значение font-size меньше 16px. Это пороговое значение для комфортного чтения. Поэтому при фокусе в поле страница увеличивается для удобства чтения вводимого значения, чтобы компенсировать font-size ниже порогового значения. Такое поведение распространяется на все браузеры под iOS, так как на данный момент там доступен только один браузерный движок — Webkit. С новыми европейскими регуляциями возможно появление альтернативных движков.

Google тоже учитывает слишком маленький размер шрифта, но иначе. В Lighthouse есть проверка в рамках аудита SEO. Она завершается с ошибкой, если у 40% текста на странице font-size меньше 12px. Ранее похожая проверка была в Google Search Console, в разделе Mobile-friendly. Но с 1 декабря 2023 года поддержка этого раздела прекращена в пользу Lighthouse.

Чтобы избежать зума страницы на iOS, достаточно установить для текстовых полей значение font-size больше или равное 16px. И хорошо, чтобы это было минимальным значением в целом, а не только для полей ввода. Не нужно следовать советам, которые предлагают "исправить проблему" путём добавления значение maximum-scale=1 в мета-тег viewport. Такое "исправление" не проходит один из тестов критерия WCAG 1.4.4 Resize Text. Кроме того, браузеры могут игнорировать значения мета-тега viewport, если сочтут нужным.

CSS Wrapped 2024

Команда Chrome DevRel запустила CSS Wrapped 2024. Это лендинг с обзором новых возможностей CSS, выпущенных в Chrome (и не только) в этом году. Можно считать это итогами года для CSS.

В CSS появилось 17 новых возможностей:

- field-sizing
- Анимация height: auto, calc-size() и interpolate-size
- Exclusive Accordion
- ::details-content
- Anchor Positioning
- scrollbar-color и scrollbar-width
- View transitions
- Scroll-driven animations
- Scroll snap events
- Наследование свойств в ::backdrop
- light-dark()
- @property
- Popover API
- @starting-style
- ruby-align
- paint-order
- CSSNestedDeclarations

Глядя на этот список и отслеживая новинки для публикации в этот канал, я впечатлён развитием CSS в этом году. Не помню такого количества фич раньше. Осталось дождаться хорошей поддержки всего этого. Тут я тоже настроен позитивно, о чём я уже упоминал. А пока предлагаю перейти на сайт CSS Wrapped 2024 и ознакомиться с демками всех новых возможностей. Особенно через последнюю версию Chrome, в которой все они поддерживается.

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

Размер DOM и доступность

Я уже писал о размере DOM в контексте производительности. Но чрезмерный размер DOM может негативно повлиять и на доступность.

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

У веб-страниц тоже есть дерево доступности, которое можно посмотреть в DevTools. Дерево доступности веб-страницы формируется на основе DOM. Браузер передаёт операционной системе данные о семантике и свойствах элементов, которые определены по умолчанию или заданы разработчиком через ARIA. Поддерево доступности сайта встраивается в общее дерево операционной системы.

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

В итоге программа чтения с экрана, например, может озвучивать информацию с большой задержкой или озвучивать уже неактуальную информацию. Иногда вовсе может прекратить работу и вылететь из-за того, что не хватило ресурсов на обработку большого объёма данных. Об этом рассказал Эрик Бейли, специалист по доступности из GitHub, на конференции performance. now(), которая прошла недавно. Кому интересно, есть запись доклада.

7 функций, которые нужны каждому сайту

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

- Cookie-баннер, запрашивающий согласие на трекинг для рекламодателей, обязательно с неочевидными вариантами выбора.
- Запрос местоположения через Geolocation API, чтобы точно знать, где находится пользователь.
- Запрос на отправку Push-уведомлений, чтобы пользователь точно был в курсе всех “важных” новостей сайта.
- Всплывающее модальное окно на весь экран сразу после загрузки страницы, требующее ввести email для подписки на бесполезную рассылку.
- Автоматически воспроизводимое видео со скрытыми элементами управления плеером, чтобы остановить его мог только опытный пользователь.
- Сложная CAPTCHA, ведь пользователям нравится несколько раз подряд выбирать светофоры, автобусы и пешеходные переходы.
- Отключение кнопки “назад”, чтобы возникли трудности при попытке вернуться на предыдущую страницу, обязательно с модальным окном, что пользователь не прав.

Шутки шутками, но мы живём в мире, где такие “функции” не редкость. Я делился докладом Виталия Фридмана Privacy UX, где он показывает такие паттерны на реальных сайтах. Пожалуйста, не делайте так.

Link Area Delegation

Есть распространённый паттерн карточки товара, статьи и так далее. Обычно это картинка, заголовок, ссылка и дополнительные элементы. Верстают их по-разному, но в целом выработан паттерн, который выглядит примерно так:

<article>
  <img src="..." alt="">
  <h3>
    <a href="/catalog/76345865">Title</a>
  </h3>
  <p>99$</p>
  <p>Denoscription</p>
  <a href="/cart/add/76345865">Add to cart</a>
</article>

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

Но внутри интерактивных элементов нельзя размещать другие интерактивные элементы. В примере это “Add to cart”. Вложенные интерактивные элементы приводят к плохому пользовательскому опыту и проблемам с доступностью. Кроме того, весь текстовый контент ссылки становится её доступным именем, что крайне избыточно. Иногда от ссылки отказываются, меняя на <div> с обработчиками кликов. Тоже плохо.

Хейдон Пикеринг предложил компромиссное решение. Если кратко, то ссылка остаётся внутри заголовка. К ней добавляется псевдо-элемент ::before и растягивается на всю карточку. Другие интерактивные элементы поднимаются на слой выше, чем ::before. Клик по псевдо-элементу делегируется ссылке и всё работает.

Паттерн рабочий, я им пользуюсь, но есть неудобства. Нужно добавлять ::before, работать с position: absolute и z-index, не забыть поднять другие интерактивные элементы выше, правильно настроить рамку фокуса и т.д.

Группа OpenUI поделилась идеями по улучшению и выпустила предложение Link Area Delegation. Суть сводится к тому, чтобы предоставить декларативный механизм делегирования кликов с других элементов на ссылку. Предложено несколько вариантов, которые ещё будут прорабатываться.

Вариант 1: атрибуты

<article linkarea>
  ...
  <h3>
    <a href="/catalog/76345865" defaultlink>Title</a>
  </h3>
  ...
</article>

<article linkarea="link_id">
  ...
  <h3>
    <a href="/catalog/76345865" id="link_id">Title</a>
  </h3>
  ...
  <a href="/cart/add/76345865">Add to cart</a>
</article>

Клик по элементу с атрибутом linkarea делегируется ссылке с атрибутом defaultlink или ссылке, id которой указан в атрибуте linkarea.

Вариант 2: новый элемент

<article>
  <linkarea>
    ...
    <h3>
      <a href="/catalog/76345865" defaultlink>Title</a>
    </h3>
    ...
    <a href="/cart/add/76345865">Add to cart</a>
  </linkarea>
</article>

Вместо атрибута предлагается элемент <linkarea>. Клики по нему делегируются ссылке с атрибутом defaultlink. Это менее удобно, не всегда можно что-то обернуть, например, строку таблицы, у которой жёсткие правила вложенности.

Вариант 3: CSS вместо HTML

<article class="card">
  ...
  <h3>
    <a href="/catalog/76345865">Title</a>
  </h3>
  ...
  <a href="/cart/add/76345865">Add to cart</a>
</article>

<style>
  .card { 
    pointer-area: contain;
  }
  
  .card h3 a { 
    pointer-area: expand;
  }
</style>

Первая ссылка внутри карточки расширяет (pointer-area: expand) свою область клика на элемент, который содержит (pointer-area: contain) расширяемый элемент.

Вариант 4: использование Invokers

<article commandfor="link_id" commands="click contextmenu">
  ...
  <h3>
    <a href="/catalog/76345865" id="link_id">Title</a>
  </h3>
  ...
  <a href="/cart/add/76345865">Add to cart</a>
</article>

Invokers — это декларативный механизм добавления действий к элементам. Я делал пост с обзором ранней версии этого предложения. Частично Invokers уже реализованы в Chrome Canary, Firefox Nightly и Safari TP. В ближайшем будущем стоит ожидать полноценного внедрения в стабильные браузеры.

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

Cписок описаний

На прошлой неделе мне попался твит, в котором автор задавался вопросом, какие HTML-элементы с точки зрения семантики лучше подойдут для разметки такого контента:

Name: Anton
Email: xx@yy.com
Age: 80

Среди вариантов <table> и <dl>. Можно использовать <table> и сделать горизонтальную таблицу с заголовочными ячейками в первом столбце:

<table>
  <tr>
    <th scope="row">Name:</th>
    <td>Anton</td>
  </tr>
  <tr>
    <th scope="row">Email:</th>
    <td>xx@yy.com</td>
  </tr>
  <tr>
    <th scope="row">Age:</th>
    <td>80</td>
  </tr>
</table>

Если в таблице первая ячейка каждой строки — <th>, то она действует как заголовок этой строки. Можно явно указать область действия заголовочной ячейки атрибутом scope="row", как в примере. На мой взгляд <table> избыточен для такого контента. Таблицы нужны для объединения однородного набора данных, когда есть группа характеристик, для которых нужны общие заголовки и структурная связь.

Для разметки пар ключ-значение хорошо подходит элемент <dl>. Я решил написать об этом, потому что редко вижу элемент <dl> в разметке и вокруг него есть некоторые мифы. Разметка контента из примера при помощи <dl> будет выглядеть так:

<dl>
  <div>
    <dt>Name:</dt>
    <dd>Anton</dd>
  </div>
  <div>
    <dt>Email:</dt>
    <dd>xx@yy.com</dd>
  </div>
  <div>
    <dt>Age:</dt>
    <dd>80</dd>
  </div>
</dl>

<dl> — это список описаний или ассоциативный список. Многие ошибочно считают <dl> списком определений, поэтому применимость ограничивается только терминами и их расшифровками. Такое встречается не часто: на сайтах вроде Википедии, словарях или справочниках. Дело в том, что в HTML4 элемент назывался definition list и действительно был задуман как список определений. В HTML5 семантика <dl> изменилась и с тех пор это denoscription list. Его можно использовать не только для терминов, а для любых пар ключ-значение.

В <dt> описывается термин или ключ, а в <dd> соответствующие данные. Ключей и данных может быть несколько. Одному <dt> может соответствовать несколько <dd> и наоборот. У <dl> особая контентная модель, которая допускает использование <div> на первом уровне вложенности, если внутри него находятся только <dt> и <dd>. При этом <div> можно не использовать и вкладывать <dt> и <dd> напрямую в <dl>. В обычных списках так нельзя.

Как и <ul>, <ol> и <menu>, элемент <dl> — это список. Скринридеры озвучат количество элементов в списке и предоставят дополнительные возможности взаимодействия. В текущей версии ARIA in HTML указано, что у <dl>, <dt> и <dd> нет встроенных ролей. При этом Chrome добавляет свою роль DenoscriptionList для <dl> и роли term и definition для <dt> и <dd> соответственно. В Firefox всё аналогично, кроме роли <dl>, там она указана как definitionlist. Подробнее о взаимодействии скринридеров с элементом можно почитать в статье Адриана Розелли.

На практике <dl> подойдёт для разметки как списка терминов и определений, так и любого набора ключей со значениями. Например, в интернет-магазинах есть блок c характеристиками товара, где сначала идёт название характеристики, а затем значение. Данные в аккаунте пользователя тоже подойдут. Есть реализация паттерна Disclosure FAQ через <dl>. Обычный FAQ без “раскрывашек” тоже можно разметить с помощью <dl>. В целом если что-то выглядит как название свойства и значение, и таких пар несколько, скорее всего, это <dl>.