Новые CSS-функции

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

- random() — генерация случайного значения из диапазона
- random-item() — выбор случайного значения из списка
- sibling-count() — количество дочерних элементов
- sibling-index() — позиция дочернего элемента
- progress() — позиция значения в диапазоне в виде числа
- media-progress() — позиция медиа-выражения в диапазоне в виде числа
- container-progress() — позиция контейнерного выражения в диапазоне в виде числа
- mix() — интерполяция двух значений
- calc-mix() — интерполяция двух чисел, размеров или процентов
- cross-fade() — смешивание двух изображений
- transform-mix() — интерполяция двух значений со списками трансформаций
- first-valid() — выбор первого поддерживаемого браузером значения
- toggle() — циклический выбор одного значения из списка
- calc-size() — вычисление внутреннего значения, например auto-высоты по контенту

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

VI конференция по цифровой доступности стартует 4 сентября

В этот раз в качестве продюсера конференции выступает Света Бондаренко. Она придумала офигенную концепцию - поговорить об эмоциях при работе с доступностью.

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

04.09 в 19:00 по МСК открытие конференции: трек "Бесит". посвящён проблемам и ситуациям от которых подгорает у всех кто связан с цифровой доступностью.

Серые буквы на сером фоне? Люди, которые не умеют в доступность и распространяют неверные сведения? Или может "версия для слабовидящих"?


11.09 в 19:00 по МСК трек: "Удивление". Вторая встреча посвящена тем неожиданным моментам, которые вызывают удивление у специалистов по цифровой доступности.

Улучшение доступности ухудшило доступность. Анонс реализации доступности спустя 2 года и другие курьёзы.


18.09 в 19:00 по МСК трек: "Страх". Третья встреча посвящена тем пугающим аспектам цифровой доступности, которые вызывают страх у специалистов.

Что если бизнес решит, что доступнось, это впустую потраченые деньги? А если разработка доступности будет "для галочки"?


25.09 в 19:00 по МСК трек: "Радость". Четвертая встреча посвящена тем моментам, которые приносят радость и удовлетворение в работе над цифровой доступностью.

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




Конференция бесплатная!

Приходите сами, и зовите друзей, будет интересно!

Privacy UX

Вы когда-нибудь обсуждали с кем-то покупку чего-либо и потом видели рекламу этого в соц. сетях? Или гуглили что-то, а потом баннеры с этим преследовали вас на всех сайтах? Может быть, видели эти надоедливые баннеры “Мы используем cookie”? Это всё о приватности данных.

Хочу поделиться докладом Виталия Фридмана “Privacy UX”, где он подробно и в своём стиле рассказывает о проблеме с приватностью данных и показывает примеры сайтов в диком Интернете. Крайне рекомендую посмотреть доклад не смотря на то, что он 2019 года. Я после этого доклада о многом задумался.

Чего не хватает в вебе?

С 6 по 7 июня прошла конференция CSS Day. Команда Chrome присутствовала на мероприятии и сделала полезный интерактив. В перерывах между докладами, участники конференции могли написать на стикере, чего не хватает в веб-платформе, и приклеить его на доску. Другие участники могли "голосовать" за фичи путём приклеивания оранжевого кружка. Лия Веру поделилась фото этой доски в конце конференции и я начал изучать её, чтобы подготовить материал и поделиться им в канале 🕵️‍♂️.

И вот, на днях в блоге Chrome For Developers вышла официальная публикация от Рейчел Эндрю, в которой она поделилась результатами с этой доски. Статья рассматривает топ 10 фич по количеству голосов.

Стилизация полей ввода, 21 голос

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

Visually hidden, 19 голосов

Распространённый паттерн добавления визуально скрытого, но доступного для вспомогательных технологий текста. Разработчики хотят встроенный элемент или атрибут вместо классов visually-hidden или sr-only с хитрым набором свойств.

position: sticky внутри overflow: hidden, 16 голосов

position: sticky работает только внутри элементов с overflow: visible. Ещё с 2017 года просят добавить overflow: hidden, поскольку есть ситуации, когда это нужно.

Анимация height: auto, 12 голосов

Каждый разработчик хотя-бы раз делал аккордеоны и сталкивался с тем, что анимировать высоту произвольного контента height: auto нельзя. В ход шли хаки с max-height и JavaScript. Об этой потребности давно известно и в разработке находится функция calc-size(), которая решает проблему.

Дополнительные типа полей ввода, 10 голосов

На данный момент в HTML есть 22 типа полей ввода и этого не достаточно. Разработчики хотят range с двумя ручками или список с произвольным авто дополнением. Над этим работают в OpenUI, как пример, упомянутые ранее комбобокс и переключатель.

Случайные числа в CSS, 10 голосов

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

Миксины, 7 голосов

В CSS появилось практически всё, что было в препроцессорах, я когда-то делал об этом пост. Но вот миксины в CSS пока недоступны. Есть способы имитации, но они выглядят как хаки. CSSWG приняла предложение о добавлении миксинов и функций и сейчас ведётся работа над этим.

Глобальные стили в Shadow DOM, 6 голосов

Есть потребность применения глобальных стилей внутри Shadow DOM. Сейчас это просто так сделать нельзя из-за изоляции. Рабочая группа веб компонентов прорабатывает варианты API и ситуации, где это может быть нужно.

Деление разных величин, 6 голосов

Кому-то нужна возможность деления разных величин, например calc(100vw / 1px). Я с такой потребностью не сталкивался, но кому-то это нужно.

nth-letter, 6 голосов

В CSS можно выбрать первую строку или первую букву в строке, но почему-то нельзя выбрать n-ю букву. Это может быть полезно для каких-то красивых типографских эффектов. Оказывается, об этом просят уже 12 лет.

***

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

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