<divelopers>

Разметка бокового фильтра

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

<aside>

Если опустить мантру «<aside> для боковых колонок», то этот элемент предназначен для контента, который косвенно связан с окружающим его контентом и который можно удалить без потери смысла. Боковой фильтр подходит под эти критерии. К тому же <aside> — ориентир и к нему можно быстро перейти.

<nav>

<nav> группирует элементы, которые используются для навигации. Фильтр можно рассматривать как своего рода навигацию по каталогу товаров. Хороший фильтр дополняет адрес страницы параметрами, чтобы можно было сохранить ссылку или поделиться с кем-то. <nav> тоже ориентир и позволяет быстро перейти к фильтру.

<search>

<search> предназначен для разметки набора элементов, которые предоставляют функции поиска или фильтрации. Уже по описанию элемент подходит. Как и другие элементы, <search> — ориентир с возможностью быстрого доступа. Остаётся только вопрос с браузерной поддержкой, так как элемент относительно новый.

<form>

Хороший фильтр дополняет адрес страницы параметрами. Самый простой способ добиться этого — использовать <form>. Если элементы фильтра находятся внутри <form> этого может быть достаточно и другие семантические обёртки не нужны. <form> не ориентир, но быстрый доступ возможен через список форм. Или можно связать заголовок и форму, тогда получится ориентир.

<section>

Можно не вдаваться в нюансы семантики <aside>, <search>, <nav> и <form>, а просто использовать <section>. Элемент группирует связанные части страницы без дополнительной смысловой нагрузки. Сам по себе <section> ничего не даёт, но с привязанным заголовком он становится ориентиром. С помощью aria-roledescription можно задать произвольное название роли.

<div role="group"> или <fieldset> + <legend>

Последний вариант — просто сгруппировать элементы фильтра без добавления дополнительной семантики и создания ориентира. Для этого можно использовать <div role="group">. Или, следуя первому правилу ARIA — завернуть всё в <fieldset> + <legend>, что создаст группу с заголовком. Для большей понятности можно добавить описание роли.

#html #a11y

Видео с MinskJS #12

Опубликован плейлист докладов с MinskJS #12. Запись прямой трансляции разрезана на отдельные видео для удобного просмотра.

Я выступал с темой «да кто такие эти ваши веб-компоненты?!» и попытался объяснить, что такое веб-компоненты, сравнил их с фреймворками и показал, где они могут пригодиться.

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

Настя Котова объяснила, что такое node-gyp, зачем он нужен, почему при установке зависимостей и запуске сборки может упасть ошибка gyp ERR! и как это можно исправить.

Если вы хотите выступить с докладом на тему фронтенда, но сомневаетесь — смело подавайте заявку на MinskCSS или MinskJS. Организаторы рады новым спикерам и помогут с подготовкой доклада.

#js

Slick slider

Помните библиотеку для создания каруселей Slick? На старте карьеры я её использовал, потом перешёл на Swiper, а сейчас предпочитаю лёгкие веб-компоненты или решения на основе Scroll Snap. Работая над улучшением доступности проекта, я вновь столкнулся с Slick.

На сайте заявляется:

Fully accessible with arrow key navigation

В настройках есть параметр accessibility со значением true по умолчанию. Slick кое что делает для улучшения доступности: устанавливает атрибуты, добавляет управление стрелками. К сожалению, этого не достаточно, при аудите я обнаружил много проблем. В целом Slick не соответствует рекомендациям от WAI ARIA.

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

A fully accessible, WCAG 2.0 / 2.1 compliant, drop-in replacement for Slick Slider (1.8.1) intended to make life easier for real-world dev teams who need to pass accessibility audits.

Сколько бы времени мне это сэкономило, если бы я знал… Это полноценная замена Slick версии 1.8.1, в ядре которой исправлены проблемы с доступностью. API и функциональность остались прежними. Если на проекте используется Slick 1.8.1 и нужно сделать его доступным, можно просто заменить файл скрипта на форк.

А вообще удалите Slick и больше никогда его не используйте. Последняя версия вышла 7 лет назад, на GitHub 1210 открытых issue, проект больше не поддерживается и не развивается. Ещё и jQuery требует для работы. Это касается и React-обёрток над Slick, так в пакетах оказывается jQuery.

Поговорите с дизайнером, действительно ли вам нужны карусели. Если нужны, отдавайте предпочтение лёгким и современным вариантам. Swiper предлагает веб-компонент, совместимый с любым стеком. Для простых случаев рассмотрите sl-carousel, Splide, Scroll Snap Slider, Snap Slider. Со временем можно будет перейти на CSS-карусели.

#js #a11y

You don't know HTML: loading

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

Для этого применяются специальные библиотеки. Они полагаются на Intersection Observer, чтобы отслеживать пересечения изображений с областью просмотра. Затем ссылки из атрибутов data-src и data-srcset подставляются в src и srcset, что инициирует загрузку.

С библиотеками есть проблемы:

- Зависимость от JS и дополнительные накладные расходы. Ленивая загрузка не будет работать, пока не выполнится код библиотеки. Поэтому ссылки помещают в data-* атрибуты;

- Поисковые роботы могут не извлекать ссылки из data-src/data-srcset или игнорировать изображения без src. Таким образом можно навредить SEO;

- Атрибут src обязательный, поэтому многие инструменты анализа разметки (валидаторы, линтеры, сканеры доступности) будут игнорировать такие изображения или помечать как невалидные;

- Для предотвращения проблем с JS и SEO нужно добавлять дополнительный элемент <img> и вкладывать его в <noscript>.

Проблемы решает встроенный в HTML атрибут loading. Значение eager сообщает, что ресурс нужно обрабатывать как обычно. Это значение по умолчанию, поэтому атрибут можно не указывать. Значение lazy включает встроенную в браузеры ленивую загрузку.

Атрибут доступен у элементов <img> и <iframe>, также есть предложение добавить его для <video>. При установке loading="lazy" ресурс не будет скачиваться на этапе обработки HTML, сканер предварительной загрузки не добавит ссылку в очередь.

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

Можно было бы сказать, что для всех <img> и <iframe> нужно установить loading="lazy", но это не так. Не стоит устанавливать loading="lazy" для элементов в верхней части страницы, которые видны сразу.

Изображение может стать кандидатом на LCP (Largest Contentful Paint). В таком случае его важно показать как можно скорее. loading="lazy" помешает заранее начать загрузку. В результате пользователи получат изображение позже и значение метрики LCP возрастёт.

#ydkhtml #performance

Полностью стилизуемый <select>

Марафон новинок продолжается. В Chrome 135 доступен полностью стилизуемый <select>. Последние несколько лет прорабатывались разные варианты как это сделать. После тестовой реализации и обратной связи от разработчиков, финальный вариант был принят и теперь доступен в Chrome. У нас наконец-то появилась возможность стилизовать стандартный <select>!

Стилизация включается специальным значением свойства appearance:

select, select::picker(select) {
  appearance: base-select;
}

Установка свойства меняет режим отрисовки. Вместо системного виджета генерируется новый виджет c HTML-разметкой и базовыми стилями в Shadow DOM. Это позволяет стилизовать внутренние части <select>, но убирает некоторые функции:

- выпадающий список опций не сможет заходить за пределы окна браузера;
- на мобильных устройствах не будет открываться системный интерфейс выбора опций;
- ширина <select> не будет соответствовать самой длинной опции.

Вместе с этим меняется режим парсера. До этого в <select> можно было помещать <option>, <optgroup>, а с недавних пор <hr>. Все остальные элементы игнорируются. В новом режиме внутрь <option> можно поместить изображения, SVG и дополнительную разметку. В сам <select> можно добавить <button> и новый элемент <selectedcontent> для отображения выбранной опции.

<select>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option>
    <svg aria-hidden>…</svg>
    <span>HTML</span>
  </option>
  <option>
    <svg aria-hidden>…</svg>
    <span>CSS</span>
  </option>
  <option>
    <svg aria-hidden>…</svg>
    <span>JavaScript</span>
  </option>
</select>

<button>, <selectedcontent>, <option> и его внутренние элементы можно свободно стилизовать как обычные дочерние элементы. Вместе с ними можно стилизовать внутренние части в Shadow DOM, доступ к которым осуществляется через специальные псевдо-элементы и псевдо-классы:

- select:open — <select> в открытом состоянии;
- select::picker(select) — выпадающий список опций, реализован как Popover с привязкой через Anchor Positioning;
- select::picker-icon — иконка со стрелкой, которая меняется при открытии, в content можно подставить свой символ или изображение;
- option::checkmark — иконка в виде галочки у выбранной опции, в content можно подставить свой символ или изображение;
- option:checked — выбранная опция.

Можно стилизовать <optgroup>, но не его подпись, создаваемую через атрибут label. К счастью, можно вложить <span> с подписью, стилизовать как нужно и привязать к <optgroup> через ARIA. Доступны псевдо-классы :hover, :focus и :focus-visible, поэтому можно изменять внешний вид <option> при наведении и фокусе. Можно применять flexbox и grid для расположения элементов.

Если браузер не поддерживает новые свойства, то <select> будет работать по-старому. Все недопустимые внутри элементы будут игнорироваться и отображаться в виде обычного текста. Также интересно, что можно отключить appearance: base-select по медиа-запросу, чтобы вернуть на мобильных устройствах системный интерфейс выбора опций.

#css

Миксины в CSS

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

У Chrome, похоже, марафон анонсов новых функций. Адам Аргайл у себя на сайте поделился, что CSS-миксины уже доступны в Chrome Canary за флагом и готовы к экспериментам. К посту приложен вот такой фрагмент кода:

@mixin --box {
  aspect-ratio: 1;
  inline-size: 100px;
  block-size: 100px;
}

.box {
  @apply --box;
}

Миксин объявляется через новую директиву @mixin. Затем следует название в синтаксисе <dashed-ident>, как у custom properties. Далее описывается блок с правилами. Применяется миксин через ещё одну новую директиву — @apply. Почти как в SCSS.

Миксины и функции основаны на предложении CSS Mixins & Functions от Мириам Сюзанн, которая много работает над развитием CSS и Sass. Предложение приняли в рабочей группе CSS и на его основе пишется спецификация CSS Functions and Mixins.

Лично для меня миксины — последняя часть пазла, чтобы полностью отказаться от препроцессоров. Я пробовал использовать в проектах чистый CSS и именно миксинов мне не хватало. Где-то это решалось через custom properties и сокращенные свойства, где-то дополнительным классом в HTML.

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

#css

Заголовки и outline

На старте карьеры я запомнил правило: на странице должен быть один <h1>. Остальные заголовки нужно размечать элементами <h2>-<h6> согласно иерархии. Периодически попадаются статьи и комментарии, которые предлагают использовать <h1> для всех заголовков на странице, потому что браузеры и поисковики умеют с этим работать.

Ноги растут из алгоритма outline, который был описан в спецификации HTML. Это алгоритм определения структуры документа, выделения содержания (table of content) и навигации горячими клавишами.

Ещё при разработке XHTML 2.0 вместо заголовков разных уровней предлагалось использовать новый элемент <h>. Уровень должен был автоматически определяться на основе вложенности в элементы секционирования (<section>, <article>, <aside>, <nav>, и другие).

XHTML 2.0 не удался, но некоторые идеи перекочевали в HTML5. В том числе идея использовать <h1> в сочетании с элементами секционирования для разметки заголовков. Долгое время в спецификации можно было найти подобные примеры кода:

<body>
  <h1>Основной заголовок</h1>
  <section>
    <h1>Заголовок раздела 1</h1>
    <article>
      <h1>Заголовок элемента 1</h1>
    </article>
    <article>
      <h1>Заголовок элемента 2</h1>
    </article>
  </section>
  <aside>
    <h1>Заголовок раздела 2</h1>
  </aside>
</body>

Что давало такую структуру:

Основной заголовок (ур. 1)
├── Заголовок раздела 1 (ур. 2)
│   ├── Заголовок элемента 1 (ур. 3)
│   └── Заголовок элемента 2 (ур. 3)
└── Заголовок раздела 2 (ур. 2)

Из-за этих примеров стала распространяться информация, что можно использовать только <h1> и не использовать <h2>-<h6>. Из этого следовало, что на странице можно использовать несколько <h1>. Поисковые системы тоже это учитывают. Индексирующему алгоритму, в общем-то, всё равно как размечены заголовки.

Но алгоритм outline никогда не был реализован ни в одном из браузеров из-за сложностей. Единственное, что реализовано — стили для <h1>, которые зависят от вложенности. Недавно был поднят вопрос о том, чтобы эти стили удалить из спецификации и браузеров.

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

От алгоритма outline решено отказаться. Его следы оставались в спецификации до 1 июля 2022 года. Тогда раздел переписали, удалив описание алгоритма и примеры с <h1>. Термин outline остался в спецификации, но теперь обозначает дерево всех заголовков страницы, которое формируется на основе уровней. В актуальной версии все ещё есть один пример с несколькими <h1> и подписью “A document can contain multiple top-level heading”.

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

Поэтому старое правило «один <h1> на страницу» и соблюдение иерархии заголовков всё ещё актуально. Не стоит экспериментировать, меняя все заголовки на <h1>. Даже если поисковые системы это поддерживают и кто-то говорит, что так можно.

#html

CSS-карусели

Прошло всего несколько месяцев с анонса, а Адам Аргайл поделился новостью, что в 135 версии Chrome появятся встроенные карусели. Их можно будет создавать средствами CSS, с кнопками вперёд/назад, маркерами, плавной прокруткой, перетаскиванием и доступностью.

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

Есть реализации с дополнительным JS, который добавляет кнопки, маркеры, перетаскивание и прочие возможности. Теперь всё это можно будет добавить с помощью нескольких новых псевдо-элементов: ::scroll-button(), ::scroll-marker и ::scroll-marker-group.

::scroll-button() создаёт кнопки в зависимости от параметра в скобках (top, right, bottom, left и логических аналогов block-start, block-end, inline-start и inline-end). Это полноценные кнопки, которые можно нажимать, фокусировать и стилизовать как нужно.

::scroll-marker создаёт маркеры. Они также интерактивные и стилизуемые. Браузер учитывает количество маркеров относительно количества слайдов и шагов прокрутки. Маркеры синхронизируются с прокруткой, а текущий маркер может быть стилизован через псевдо-класс :target-current.

::scroll-marker-group соответствует контейнеру с маркерами. Его можно размещать в нужной части карусели, ограничить по ширине или ещё как-либо стилизовать. Контейнер предлагает навигацию по маркерам при помощи стрелок.

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

Текущая реализация не включает некоторые возможности, но позволит закрыть 80% задач с каруселями. В дальнейшем планируется расширить функциональность: зацикленная прокрутка, передача собственных элементов в качестве кнопок и маркеров, JS-методы для программной прокрутки и так далее.

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

#css

Автодополнение номера телефона

Я уже писал про автодополнение в браузерах. Работая над улучшением доступности одного проекта, я настраивал автодополнение в рамках критерия WCAG 1.3.5 Identify Input Purpose. Не углубляясь в детали, критерий требует установки соответствующих цели ввода значений атрибутов type и autocomplete у полей. Одно из них я настроил примерно так:

<label for="ContactPhone">
  Phone Number
</label>
<input
  type="tel"
  name="contact[phone]"
  id="ContactPhone"
  autocomplete="tel-national"
  placeholder="123-555-1212"
>

На вид все хорошо: лейбл есть, type="tel" для ввода телефона есть, autocomplete="tel-national" для телефона в национальном формате (без кода страны, для него рядом другое поле) есть. Проверив этот код через расширение для анализа доступности, я получил ошибку:

The autocomplete attribute has an incorrect value

Значение tel-national описано в спецификации HTML и предназначено для ввода телефона в национальной форме. Баг расширения, подумал я, и завёл issue. Спустя какое-то время я проверил код с этой формой в валидаторе HTML и получил примерно такую же ошибку:

Bad value tel-national for attribute autocomplete on element input: The autofill field name tel-national is not allowed in this context.

Закралось ощущение, что это не баг, а я чего не знаю. В исходом коде теста из расширения есть дополнительная проверка на тип поля. Для type="tel" единственным допустимым значением считается autocomplete="tel", поэтому и возникла ошибка. Но тест же на чём-то основан?

И да, в спецификации HTML есть абзац о том, что значения атрибута autocomplete должны применяться у допустимых типов полей, что отмечено в таблице со значениями. Это логично: спецификация защищает от ситуаций, когда для поля с type="email" устанавливается значение autocomplete="given-name", что не имеет смысла.

Поле с type="tel" предназначено для ввода полного номера телефона, с кодом страны и региона. У такого поля можно установить только autocomplete="tel". Если поле предназначено для ввода части номера (без кода страны и региона), то нужно использовать другое значение autocomplete, а type="tel" для такого уже не подойдёт.

Исправленный вариант:

<label for="ContactPhone">
  Phone Number
</label>
<input
  type="text"
  inputmode="tel"
  name="contact[phone]"
  id="ContactPhone"
  autocomplete="tel-national"
  placeholder="123-555-1212"
>

Как было изначально, сохранилось значение autocomplete="tel-national" для номера без кода страны. type="tel" заменён на универсальный type="text" для ввода произвольных данных, который совместим со значением tel-national. И добавлен атрибут inputmode="tel" для возврата виртуальной клавиатуры, удобной для ввода номеров.

#html #a11y

MinskJS #12

Присоединяйтесь к прямой трансляции MinskJS Meetup #12 сегодня в 19:00 по Минску!

Я буду выступать с докладом "Да кто такие эти ваши веб-компоненты?!". С другими докладами можно ознакомиться в программе.

Список описаний на практике

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

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

Первая статья на HTMHell от Дэвида Лура “The underrated <dl> element”. Дэвид приводит три примера. Первый — классический список терминов и определений, для чего <dl> изначально предназначался. Второй пример — блок с цифрами и подписями, такие часто встречаются на сайтах, чтобы подсветить достижения в виде цифр. Последний, третий пример — список характеристик велосипеда в каталоге.

Вторая статья от Бэна Мейерса “On the <dl>”. Бэн приводит четыре примера. Первый — характеристики продукта, в примере это книга. Второй пример — карточка пользователя с контактами и адресом. Третий пример — блок со свойствами в стиле Википедии. Четвёртый пример самый интересный: Бэн показывает большую карточку с информацией о персонаже из Dungeons & Dragons, которая практически полностью состоит из списков описаний.

Списки описаний полезны для группировки связанного контента, который можно представить в виде пар ключ-значение. Если взглянуть на интерфейсы, такие списки можно встретить чаще, чем кажется. Хотя полезность <dl> с точки зрения семантики слегка сомнительная, всё же стоит его использовать для группировки подходящего контента.

#html

You don't know HTML: способы расширения HTML

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

Авторы стандартов и разработчики браузеров внедряют новые элементы (<details>, <dialog>) и улучшают существующие. Но как бы они ни старались, невозможно покрыть всё многообразие контента, сайтов, приложений и способов использования HTML.

Поэтому HTML разработан как расширяемый язык. Спецификация определяет следующие способы безопасного расширения HTML:

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

- атрибуты data-* для данных, которые игнорируются браузером и ни на что не влияют, но могут использоваться для стилизации и передачи данных для скриптов. Довольно часто используются для хранения настроек и мета-данных, которые считываются и используются в JS.

- элемент <meta name="…" content="…"> для добавления мета-данных на уровне страницы. Чаще всего используется для добавления социальной разметки (Open Graph, Twitter Card) для поисковых систем и социальных сетей. Также можно добавлять произвольные данные в виде ключ-значение, а сам элемент <meta> можно размещать не только в <head>.

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

- элемент <script type="…"> для добавления произвольных данных в текстовом виде. Значение атрибута type, отличное от text/javascript, module и importmap делает <script> блоком данных. В нём можно разместить любые данные в текстовом формате, которые затем можно считывать и обрабатывать в скриптах. Это используется микро-форматом JSON-LD.

- модель прототипов JS для расширения существующих API, что делают разные библиотеки. Хотя расширение прототипов считается плохой практикой в мире JS, такой вариант расширения возможен. Главное использовать это с умом, не перезаписывать стандартные свойства и методы, использовать наследование и Symbol.

- атрибуты itemtype, itemscope и itemprop для добавления микро-данных, которые используются другими сайтами и приложениями. Наиболее распространён словарь Schema.org, на который ориентируются поисковые системы и различные парсеры.

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

Стоит отметить ещё некоторые возможности, которые не затронуты стандартом, но также позволяют расширять HTML:

- язык MathML для разметки сложных математических формул
- язык SVG для встраивания векторной графики
- стандарт ARIA для добавления, расширения и переопределения семантики с целью улучшения доступности при использовании вспомогательных технологий

#ydkhtml

Стилизация системных элементов форм

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

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

Проблема постепенно решается. За последние годы появились точечные свойств, такие как accent-color, field-sizing и appearance, которые где-то упрощают стилизацию. В Safari реализовали переключатель <input type="checkbox" switch>, а в Chrome вот-вот добьют главного босса — <select>. Стоит отдать должное инициативе OpenUI.

Команда Джен работает над спецификацией CSS Form Control Styling. Идея в том, чтобы значительно расширить возможности стилизации элементов форм и предоставить доступ к их внутренним частям.

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

В режиме базовой отрисовки появится доступ к внутренним частям элементов. Сейчас к некоторым из них можно обратиться через специальные псевдо-элементы с префиксами — ::-webkit-slider-thumb или ::-moz-range-thumb. Но они не стандартизированы, работают только в конкретных браузерах и отличаются набором поддерживаемых свойств.

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

- ::picker() — выпадающий пикер у <select> и других элементов
- ::picker-icon — индикатор пикера
- ::file-selector-button — кнопка выбора файла у <input type="file">
- ::checkmark — индикатор выбранного состояния у <input type="checkbox">, <input type="radio"> и <option>
- ::thumb — ползунок у <input type="range">
- ::track — направляющая у <input type="range">, <input type="checkbox" switch>, <meter> и <progress>
- ::fill — заполненная часть у <input type="range">, <input type="checkbox" switch>, <meter> и <progress>
- ::field-text — редактируемая часть полей ввода
- ::clear-icon — кнопка очистки у <input type="search">
- ::step-control — блок с кнопками у <input type="number">
- ::step-up — кнопка увеличения значения у <input type="number">
- ::step-down — кнопка уменьшения значения у <input type="number">
- ::field-component — блок с компонентом даты/времени у соответствующих полей
- ::field-separator — разделитель компонентов даты/времени у соответствующих полей
- ::color-swatch — блок с выбранным цветом у <input type="color">

В спецификации есть несколько псевдо-классов для стилизации состояний элемента <meter>.

- :low-value — значение ниже оптимального
- :high-value — значение выше оптимального
- :optimal-value — значение в оптимально диапазоне

Есть в предложении интересная функция — control-value(). Она позволяет получать текущее значение элемента формы и выводить его в свойство content псевдо-элементов ::before/::after и других. Можно вывести значение и привязать его к ползунку <input type="range">.

Черновик стандарта находится в стадии разработки и многое ещё не продумано. Есть много issue, которые затрагивают важные вопросы. Выглядит амбициозно и на самом деле давно пора уже это сделать. Теперь нужно дождаться, когда это примут в CSSWG и начнутся первые эксперименты в браузерах.

#css

Invoker Commands

Я уже делал обзор предложения Invokers API от OpenUI. В конце прошлой недели в блоге Chrome For Developers представили command и commandfor. Invokers API теперь называется Invoker Commands, предложение разделили на две части, первую уже готовят к релизу в Chrome. Пришло время взглянуть на это всё ещё раз.

Invoker Commands — это декларативный механизм вызова команд у указанного элемента при нажатии кнопки. Сейчас для этого нужно написать обработчик, найти целевой элемент и вызывать нужный метод. Предлагается способ делать это в HTML двумя атрибутами: command (ранее invokeraction) и commandfor (ранее invokertarget). Первый принимает название команды, второй — id элемента, у которого нужно вызвать команду.

<button
  type="button"
  commandfor="hello-dialog"
  command="show-modal"
>
  Open Dialog
</button>

<dialog id="hello-dialog">
  Hello world

  <button 
    type="button" 
    commandfor="dialog" 
    command="close"
  >
    Close
  </button>
</dialog>

show-modal и close — это встроенные команды. Если comandfor ссылается на <dialog>, то они соответствуют вызовам методов showModal() и close(). Команды toggle-popover, hide-popover и show-popover соответствуют методам togglePopover(), hidePopover() и showPopover() у элемента с атрибутом popover. Новые атрибуты работают аналогично существующим атрибутам popovertarget и popovertargetaction из Popover API. Планируется, что новые атрибуты со временем заменят их.

В предложении OpenUI было больше встроенных команд. Принято решение разделить предложение на две части и внедрять его постепенно. В первую часть попали команды для работы с <dialog> и popover. Над второй частью ещё работают, но стоит ожидать команд для переключения <details>, раскрытия системных пикеров у <input> и <select>, управления воспроизведением <audio> и <video>, копирования текста, переключения полноэкранного режима и так далее.

В рамках первой части также будут реализованы пользовательские команды. Используя синтаксис именования пользовательских свойств CSS можно объявлять собственные команды и реагировать на них через JS. При нажатии кнопки на целевом элементе возникает событие command, а в объекте события можно обратиться к свойству command, в котором будет имя команды.

<button
  type="button"
  commandfor="custom"
  command="--do-something"
>
  Do something
</button>

<div id="custom"></div>

<script>
  const custom = document.querySelector('#custom');
  custom.addEventListener('command', (event) => {
    if (event.command === '--do-something') {
      // ...
    }
  });
</script>

Внешний commandfor не найдёт целевой элемент внутри Shadow DOM так же, как <label for> “не видит” элемент с нужным id внутри Shadow DOM. В будущем эти проблемы будут решены за счёт предложения Reference Target. А пока можно напрямую указать целевой элемент, используя свойство commandForElement.

<my-element>
  <template shadowrootmode="open">
    <button 
      type="button"
      command="show-popover"
    >
      Show popover
    </button>
    <slot></slot>
  </template>

  <div popover></div>
</my-element>

<script>
  class MyElement extends HTMLElement {
    connectedCallback() {
      const popover = this.querySelector('[popover]');
      const button = this.shadowRoot.querySelector('button');
      button.commandForElement = popover;
    }
  }

  customElements.define('my-element', MyElement);
</script>

Invoker Commands вот-вот должны появиться в Chrome. Другие браузеры смотрят на предложение позитивно и тоже займутся внедрением. Затем стоит ожидать дальнейшего развития и добавления новых команд.

#html #web_api

Лэндинги и статический HTML

Андрей Ситник в твиттере поднял тему лэндингов и статики. Основная мысль в том, что можно разрабатывать лэндинги как статический HTML без сборки. Меньше подвижных частей — меньше точек отказа, проще разработка и поддержка. Я оказывался в ситуациях, когда для минутных правок на сайте нужно было час сражаться с ошибками запуска dev-режима.

Обычно лэндинг — это одна страница под маркетинговые задачи. Нужно показать товар/услугу, CTA и подвести пользователя к целевому действию. Часто лэндинги одноразовые, сделал и забыл. Некоторые лэндинги живут долго и регулярно меняются. Бывают многостраничные и мультиязычные лэндинги. Но чаще это маленький проект, который нужно сделать быстро и минимальными усилиями.

Лэндинг можно рассматривать как большой однофайловый компонент. В HTML есть <style> для стилей, <script> для скриптов, <body> для контента. Можно даже не выносить в отдельные файлы, если кода мало. Базовая модульность обеспечивается с помощью <link>, @import, <script type="module"> и ESM. Для удобства в современных браузерах есть <script type="importmap">.

Для карусели, анимации, валидации форм и прочего могут понадобиться сторонние библиотеки. Большинство из них поставляются в виде standalone-скриптов. Подключить можно как есть с CDN или положить рядом с проектом. Что-то можно подсобрать с помощью esm.sh или bundlejs, если ну очень нужно.

Для нетривиальной логики с реактивным интерфейсом (калькулятор цен, конфигуратор продукта) есть HTML-first библиотеки: Alpine.js, petite-vue, hyperscript и десяток других. Они доступны в виде standalone и работают без сборки. В таком же режиме можно использовать Vue.

Чтобы избежать копипасты повторяющихся частей есть веб-компоненты. Google и Bing разворачивают Shadow DOM и видят всё, что внутри, поэтому проблем с SEO быть не должно. В качестве альтернативы трансклюзия фрагментов с помощью sl-include, include-fragment, i-html или даже сниппета htmz. Если сервер позволяет, можно настроить SSI и ESI, главное помнить о нюансах с безопасностью.

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

Графика оптимизируется один раз руками (squoosh, squish) или через прокси для картинок. Минификация при малом количестве ресурсов не так важна. Сжатие gzip включено на любом сервере и без минификации тоже достаточно эффективно.

Для редактирования контента нашёл интересный инструмент — Textolite. Это админка с WYSIWYG для редактирования статического HTML. После изменений перезаписывает исходный HTML-файл. Работает на PHP, но он есть на любом популярном хостинге. Правда выглядит, что проект заброшен, а аналогов не нашёл.

Звучит всё это как возврат в 00-е, когда так создавали сайты. Отчасти так и есть. Но не всегда старое — значит плохое. Плюс появились новые возможности, которых в то время не было. В итоге такой олдскульный подход вполне может подойти для многих лэндингов. Не нужно усложнять простые задачи инструментами, которые мы по привычке тянем из больших проектов потому что так “принято”.

#html

popover="hint"

Popover API впервые представлен в Chrome 114 полтора года назад, а в январе этого года получил статус Newly available с выходом Safari iOS 18.3. В сочетании с Anchor Positioning можно решать многие интерфейсные задачи, связанные со всплывающими элементами (собственно, поповерами). Popover API предлагает декларативное решение этих задач с учётом доступности и управления поведением фокуса.

Есть проблема с использованием popover="auto" (или просто popover) на разных элементах, которые должны сосуществовать. Сейчас у элементов с popover="auto" есть поведение light dismiss, когда отображение всплывающего элемента приводит к скрытию другого недочернего всплывающего элемента. Во многих случаях так и должно быть. Но есть отдельный класс элементов, где такое поведение всё ломает.

Например, есть кнопка, при нажатии которой открывается выпадающее меню. Рядом есть кнопка с иконкой, при наведении на которую отображается всплывающая подсказка с пояснением назначения. Использование popover="auto" для меню и подсказки приведёт к тому, что отображение подсказки закроет меню. Этого можно избежать за счёт popover="manual", но придётся вручную повторять поведение, которое из коробки даёт Popover API.

В Chrome 133 добавляют новое значение popover="hint". У всплывающих элементов с этим атрибутом меняется поведение light dismiss по сравнению со значении auto. На словах сложно объяснить разницу, проще ознакомиться с сравнительной таблицей в статье из блога Chrome for Developers. Но приведённый пример с меню и подсказкой будет работать так, как ожидается.

Доработки также направлены на дальнейшую интеграцию Invoker Commands API, разработка которого идёт полным ходом. Конкретно речь идёт об атрибуте interesttarget, который позволит открывать всплывающие элементы не кликом по кнопке, как c атрибутом popovertarget, а при наведении указателя или при фокусе на элемент. Я сделаю отдельный пост с обзором этих новых API.

#html #web_api

19 марта буду выступать на MinskJS с докладом про веб-компоненты.

💡Скучали? Мы тоже. Поэтому начинаем новый сезон минских митапов по фронтенду! И стартуем с JavaScript.

MinskJS Meetup #12 пройдет 19 марта 2025 года в 19:00 (по минскому времени) онлайн!

И наш первый спикер — Алексей Назаренко. Он расскажет, что же такое веб-компоненты на самом деле, какие мифы вокруг них существуют и пора ли их уже тащить в свои проекты.

📌 Место проведения: уютная онлайн-трансляция на нашем YouTube канале. Никакой регистрации, просто приходите!
👉 https://youtube.com/live/ILRrXYSthsA

Описание и программа
👉 https://telegra.ph/MinskJS-Meetup-12-03-01

Переосмысление контейнера

Элемент с классом container или wrapper часто используется в вёрстке, чтобы ограничить ширину контента на десктопных экранах. Стили классического резинового контейнера выглядят примерно так:

.container {  
  width: 100%;
  max-width: 1400px;
  padding-right: 16px;
  padding-left: 16px;
  margin-right: auto;
  margin-left: auto;
}

width: 100% не обязательно указывать, но это нужно для случаев, когда контейнер находится внутри flex-контекста. max-width ограничивает ширину контейнера. padding задаёт отступы, чтобы контент не прилипал к краям на узких экранах, а margin со значением auto используется для горизонтального центрирования. Обычно контейнер применяется так:

<section class="section">
  <div class="container">
    <!-- Контент первой секции -->
  </div>
</section>
<section class="section">
  <div class="container">
    <!-- Контент второй секции -->
  </div>
</section>

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

На одном проекте я решил переосмыслить подход к контейнеру, основываясь на двух идеях:

1. попробовать более новые возможности CSS.
2. избежать лишнего DOM-элемента и вложенности.

И вот что у меня получилось:

:root {
  --container-max-width: 1400px; 
  --container-min-field: 16px; 
  --container-field: calc(
    (var(--vw) - var(--container-max-width)) / 2
  );
}

.container {
  width: 100%;
  padding-inline: max(   
    var(--container-field),   
    var(--container-min-field)
  );
}

В :root объявлены пользовательские свойства:

- --container-max-width — максимальная ширина контейнера.
- --container-min-field — минимальный размер одного поля, чтобы контент не прилипал к краям экрана.
- --container-field — динамический размер одного поля, который вычисляется так: от ширины вьюпорта отнимается максимальная ширина контейнера и делится на 2. В итоге получается тот размер, который обычно достигается через margin со значением auto.

Ширина области просмотра в формуле представлена пользовательским свойством --vw, чтобы учесть ширину прокрутки. Про это есть отдельный пост.

Далее используется функция max(), чтобы выбрать максимальное значение из динамического и минимального поля. На десктопе поле будет занимать всё свободное пространство от края экрана до контентной области контейнера, а на узких экранах поле будет минимальной ширины.

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

<section class="container section">
  <!-- Контент -->
</section>

#css