Alt-текст:

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

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

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

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

rgb нотации

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

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

rgb(221, 160, 221)

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

rgb(87%, 63%, 87%)

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

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

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

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

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

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

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

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

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

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

Итого имеем:

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

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

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

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

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

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

State of HTML 2024

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

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

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

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

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

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

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

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

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

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

#ydkhtml

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

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

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

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

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

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

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

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

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

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

Richer Text Fields

Группа OpenUI опубликовала у себя на сайте новый эксплейнер под названием Richer Text Fields. Cуществует целый класс задач, среди которых сложные текстовые поля, WYSIWYG-редакторы, комплексные поля поиска, поля для сообщений в мессенджерах, поля для комментариев. Сейчас разработчикам приходится писать много кода и костылей, чтобы это всё работало как требуется. Некоторые из самых распространённых проблем богатых текстовых полей пытаются решить этим эксплейнером.

Предлагается расширить возможности элементов <input> и <textarea>, добавив некоторые новые API:

- Получение диапазона текста
- Применение CSS Highlights к диапазонам
- Маски ввода
- Автодополнение ввода

Диапазоны текста

В браузерах есть интерфейс Range, который позволяет получить диапазон текста и узлов. Это можно использовать для выделения, перемещения, получения координат выделенных узлов. Но применить Range к тексту внутри <input> и <textarea> сейчас нельзя. В случае с <input> диапазон будет пустой, а в случае с <textarea> диапазон будет содержать начальный текст, вместо того, который был введён пользователем.

Предлагается расширить Range или добавить новый специализированный интерфейс InputRange для получения диапазонов внутри <input> и <textarea>. Имея доступ к диапазону, можно получить координаты и привязать к ним всплывающее меню с опциями, как пример.

Стилизация диапазонов

Так как сейчас нельзя выделить диапазон внутри <input> и <textarea>, то и применить стилизацию к фрагменту текста тоже нельзя. Поэтому сейчас поверх поля накладываются <div>-ы, в них дублируется текст, вычисляются координаты, выполняется позиционирование и стилизация текста. Это сложно и с этим много проблем.

Когда получение диапазона из <input> и <textarea> станет возможным, тогда можно будет применить новый CSS Custom Highlight API для подсветки специальных токенов, например, теги в Slack (@all, @User Name).

Маски ввода

Распространённый паттерн в интернете, особенно для номеров телефона. Сейчас для этого используются JS-плагины (привет jquery.maskedinput). Обычно я выступаю против такого, потому что работает плохо, мешает браузеру сохранять номер и предлагать автозаполнение. И вообще, дайте мне ввести мой номер телефона как я хочу.

Предлагается добавить атрибут mask для <input>. Он принимает строку со значениями А (буква), 9 (число) и * (любой символ), из которых можно будет сформировать маску как в популярных плагинах. В CSS предлагается добавить псевдо-элемент ::masked и ::masked(n) для стилизации заполнителей. Сами заполнители будут отдельным элементом, как placeholder.

Автодополнение ввода

В последнее время набрал популярность паттерн предсказания текста, он же "Ghost Text". Это когда вы пишете текст, а нейросеть предлагает вам продолжение, которое вы можете принять или отклонить. Так работает Copilot, например. Есть ещё варианты со всплывающим списком вариантов, а на телефонах уже давно есть Т9. Для решения этой задачи в вебе нужно много костылей и хитрые наложения <div>-ов поверх поля ввода.

Предлагается добавить к <input> и <textarea> новый интерфейс с методами для генерации и отклонения подсказок, а также соответствующие события принятия и отклонения подсказки. При помощи этого API можно будет, например, подключить нейросеть, скормить ей пользовательский ввод, получить вывод и предложить пользователю. Псевдо-элементы ::suggestion и ::suggestion(n) позволят стилизовать текст предложения, а само предложение также будет отдельным элементом.

***

Хорошие идеи, буду наблюдать за этим предложением.

Нужно ли использовать карусели?

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

Есть один интересный сайт, который взывает к вопросу: Should I Use A Carousel (нужно ли мне использовать карусель). На этом сайте собраны UX-исследования о каруселях. Забавно, что сам сайт выполнен в виде карусели и лично я не успеваю прочитать весь текст некоторых слайдов до того, как они переключаются. Меня это дико бесит, интересно, это такая задумка?

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

Листаемые галереи отстой. Хорошо их не сделать, можно сделать не так плохо.

Если всё-таки дизайнер карусель нарисовал и требует реализовать, то стоит придерживаться хороших практик. WAI даёт пошаговый туториал по созданию доступной карусели. Можно использовать популярный Swiper вместе с a11y-модулем. Однако мне не очень нравится Swiper по ряду причин. Для простых случаев можно взять Shoelace Carousel или Splide. Также рекомендую посмотреть отрывок из доклада Ильи и прочитать его статью.

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

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

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

Началось все со статьи Райана Карниато, создателя 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 для стилизации, если этого достаточно
- В хороших формах пользовательские элементы управления не приветствуются и должны быть удалены при первой возможности

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