Споры вокруг веб-компонентов

В зарубежном сообществе веб-разработчиков уже несколько дней идут споры по поводу веб-компонентов.

Началось все со статьи Райана Карниато, создателя Solid, с громким заголовком “Веб-компоненты — это не будущее”. Райан высказывает некоторую критику веб-компонентов с позиции своего опыта и заявляет, что веб-компоненты опасны для развития веба из-за ложных ожиданий.

В ответ на это последовала статья “Веб-компоненты — это не будущее, это настоящее” от Кори ЛаВиска, создателя Shoelace. Кори говорит о возможности использования компонентов в разных средах, о низкоуровневом примитиве платформы, путанице в терминологии и усталости от постоянного переписывания.

Высказался и Нолан Лоусон, ментейнер PocuhDB и разработчик Lightning Web Components, в статье “С веб-компонентами всё хорошо”. Он подметил, что каждый по своему прав и есть разные сценарии, стеки, инструменты и приоритеты, где веб-компоненты могут подходить или не подходить.

Какие выводы для себя я сделал, прочитав статьи и дискуссии в комментариях и твиттере:

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

Свойство text-box

Думаю многие сталкивались с ситуациями, когда:

- текст внутри CSS-бокса не центрирован по вертикали
- над и под текстом есть пространство, которым нельзя управлять
- высота бокса с текстом в Figma не совпадает с тем, что получается в браузере
- не получается визуально выровнять иконку относительно текста
- текст внутри кнопки с одинаковым padding визуально не центрирован по вертикали.

Всё из-за того, что рендеринг текста в браузере — это крайне сложно. CSSWG совместно с разработчиками браузеров работают над исправлением ситуации и добавляют новые свойства для работы с текстом: text-box-trim, text-box-edge и сокращённое свойство text-box. Эти свойства дадут нам некоторый контроль над текстовым боксом.

Свойство text-box-trim позволяет отрезать часть пространства бокса над и\или под текстом. Это “над” и “под” зависит от направления письма. Дизайнеры уже могут делать это в Figma, но в браузерах сейчас это невозможно.

text-box-trim: none; /* Не обрезать, значение по умолчанию */
text-box-trim: trim-start; /* Обрезать начало (над текстом для ltr языков) */
text-box-trim: trim-end; /* Обрезать конец (под текстом для ltr языков) */
text-box-trim: both; /* Обрезать c двух сторон */

Свойство text-box-edge определяет, где будет находиться граница бокса для отрезания пространства. Оно принимает одно или два значения и зависит от значения text-box-trim.

text-box-edge: normal; /* Значение по умолчанию */
text-box-edge: text; /* Обрезать по границе текста */
text-box-edge: ex; /* Обрезать по высоте строчной буквы */
text-box-edge: cap; /* Обрезать по высоте заглавной буквы */
text-box-edge: ex alphabetic; /* Обрезать сверху по строчной букве, а снизу по границе baseline */
text-box-edge: cap alphabetic; /* Обрезать сверху по заглавной букве, а снизу по границе baseline */
/* есть ещё значения для CJK-языков (с иероглифами) */

Свойство text-box является сокращением для text-box-trim и text-box-edge. На данный момент свойства доступны с Chrome и Edge 128+ и Safari 16.4+ за флагами. В скором времени планируется включить эти свойства для всех. С Firefox пока тихо, но у них тоже есть планы на этот счёт.

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

Сходил в гости к Веб-стандартам

Поговорили про веб-компоненты: споры в сообществе, веб-компоненты против фреймворков, плохое название, польза для бизнеса, проблема с образовательными материалами.

Выпуск №443. Вадим Макеев, Полина Гуртовая, Алексей Назаренко, Алексей Симоненко про Safari TP, Firefox 131, CrUX History API и про вечный спор веб-компонентов и фреймворков.

— Слушайте на Ютубе
— Ссылки на сайте

00:02:40 Safari TP
00:12:58 Firefox 131
00:29:19 CrUX History API
00:34:06 Веб-компоненты и фреймворки
01:06:14 Что такое веб-компоненты
01:21:19 Веб-компоненты в рантайме
01:32:30 Зачем нужны веб-компоненты

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, если сочтут нужным.