CSS Scroll Snap Module Level 2

23 июля CSSWG опубликовала первый черновик CSS Scroll Snap Module Level 2. Это дальнейшее развитие Scroll Snap.

Напомню, что CSS Scroll Snap — это спецификация про управление привязкой элементов внутри прокручиваемого контейнера. Например, при помощи этой спецификации можно сделать полноэкранную прокрутку страницы, как в плагине fullPage.js. Также при помощи этой спецификации, гридов и небольшого количества JavaScript реализована карусель в библиотеке компонентов Shoelace.

Module Level 2 расширяет спецификацию и добавляет новые возможности.

1) свойство scroll-snap-target для указания элемента, который изначально должен быть привязан:

.carousel {
  overflow-inline: auto;
}

.carousel .origin {
  scroll-start-target: auto;
}

И разметка:

<div class="carousel">
  <img src="img1.jpg">
  <img src="img2.jpg">
  <img src="img3.jpg" class="origin">
  <img src="img4.jpg">
  <img src="img5.jpg">
</div>

2) псевдоклассы :snapped-x, :snapped-y, :snapped-inline и :snapped-block для стилизации привязанных элементов. Однако, принято решение отказаться от них в пользу новых Style Container Queries.

3) события scrollsnapchange и scrollsnapchanging для отслеживания изменений привязанных элементов при прокрутке в JavaScript. Вместе с ними добавляется новый тип события SnapEvent с соответствующим интерфейсом и набором свойств.

7го августа выступаю на MinskCSS с докладом про Shadow DOM! Приходите, начало в 19:00.

✨ Продолжаем знакомить вас с докладами на MinskCSS Meetup #12.

Наш следующий спикер Алексей Назаренко расскажет про особенности Shadow DOM, связанные с изоляцией и стилями, и покажет, как с этим работать.

Место проведения:
👉 https://youtube.com/live/-s7s_IB2egc 👈

Описание и программа:
https://telegra.ph/MinskCSS-Meetup-12-07-29

Подписывайтесь, чтобы ничего не пропускать: Telegram | Twitter

Скоро начинаем!

Слайды вчерашнего доклада с MinskCSS. Запись трансляции доступна на YouTube. Спасибо всем, кто присоединился к трансляции ❤️

Через некоторое время организаторы нарежут доклады на отдельные видео, которые будут доступны на том же канале. Также можете посмотреть другой мой доклад "HTML: 25 фич, которые сделают ваш сайт удобнее".

Также напомню, что если у вас есть тема и вы хотите выступить с ней, или попробовать, пишите ребятам из MinskCSS/MinskJS и Accessibility Club Minsk.

И если есть какие-то вопросы по Shadow DOM или веб-компонентам в целом, пишите в личку.

Глобальная дизайн-система

Брэд Фрост, эксперт в области дизайн-систем, автор книги "Атомарный дизайн", опубликовал в своём блоге статью "Глобальная дизайн-система". В этой статье он призывает сообщество заняться созданием глобальной дизайн-системы для всего мира. Звучит очень амбициозно.

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

Брэд считает, что пришло время сообществу начать работу над Глобальной дизайн-системой. Его основные идеи и тезисы:

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

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

- кастомизация. Глобальная дизайн-система должна поставляться как headless-решение с минимальными базовыми стилями браузера для возможности реализации конкретного внешнего вида.

- интуитивность. Глобальная дизайн-система должна быть максимально легкой и понятной в использовании, все компоненты, возможности, API должны быть подробно документировны.

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

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

- расширяемость. Глобальная дизайн-система должны покрывать большинство кейсов использования по правилу 80/20, при этом быть легко расширяемой, чтобы на её основе можно было строить другие дизайн-системы.

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

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

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

You don't know HTML: inert

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

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

Атрибут inert решает задачу более простым способом. Это глобальный атрибут, поэтому его можно добавить к любому элементу. Когда атрибут установлен, происходит следующее:
- все дочерние интерактивные элементы становятся недоступными для взаимодействия, как будто для них установлено свойство pointer-events: none
- все дочерние интерактивные элементы пропадают из последовательности табуляции, как будто для них установлен атрибут tabindex="-1"
- элемент вместе со своими дочерними элементами скрывается из дерева доступности, как будто для них установлен атрибут aria-hidden="true".

<main inert>
  <p><!-- контент --></p>
  <p><a href="/">ссылка</a></p>
  <p><!-- контент --></p>
  <button type="button">Удалить</button>
</main>

<div role="dialog" aria-modal="true" aria-labelledby="dialog-heading">
  <h2 id="dialog-heading">
    Вы действительно хотите удалить запись?
  </h2>
  <button type="button">Да</button>
  <button type="button" autofocus>Нет</button>
</div>

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

#ydkhtml

Intent to Prototype: CSS Gap Decoration

Ранее я писал о предложении по добавлению в CSS возможности стилизации gap-ов во flexbox и grid. И вот, команда Microsoft Edge начала разработку прототипа этих функций в Blink (движок в Chromium браузерах). Подробнее с предложением можно ознакомиться в черновике спецификации и эксплейнере.

Другие движки (Webkit и Gecko) пока явно не проявили заинтересованность, но если обкатка прототипа пройдёт успешно, эту спецификацию доработают и примут в CSSWG, а там и другие движки подтянутся. Предложение на самом деле очень полезное и нужное.

Роли-контейнеры: region

Продолжаю рассказывать про ARIA-роли. region — это область с контентом, которая имеет особое значение в рамках страницы, которое определено автором. Элемент с этой ролью попадает в список ориентиров, поэтому пользователи вспомогательных технологий смогут быстро добраться к этому участку страницы. При этом region должен использоваться для группировки контента, назначение которого не попадает ни под один из существующих ориентиров (banner, navigation, contentinfo, complementary, main, search или form).

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

- область с основным описанием продукта и формой добавления в корзину в интернет-магазине
- область с Call-To-Action формой на сайте услуг
- разные по функционалу панели в админке
- область с чатом возле основного плеера на стриминговом сервисе

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

<div role="region" aria-labelledby="r1">
  <h2 id="r1">Важная область</h2>
  <!-- контент -->
</div>

Если к встроенному в HTML элементу <section> привязать заголовок, то элемент получит встроенную роль region. Исходя из первого правила ARIA, лучше использовать именно такой вариант.

<section aria-labelledby="r1">
  <h2 id="r1">Важная область</h2>
  <!-- контент -->
</section>

К region можно быстро переключиться через список ориентиров или горячие клавиши. В этом смысле заголовки решает похожую задачу. Но region добавляет дополнительную семантику, скринридеры озвучат границы и название области. При помощи aria-roledenoscription можно дать роли более конкретное название. Подробнее об использовании region можно прочитать в технике ARIA20.

Go Make Things

Хочу поделиться проектом под названием Go Make Things. Его автор, Крис Фердинанди, практически каждый день пишет небольшие заметки о том, как делать более простой, быстрый и устойчивый веб. Архив заметок доступен на сайте, также можно подписаться на email-рассылку.

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

Заметки затрагивают темы HTML, CSS, Vanilla JS, доступности, производительности, архитектуры, веб-компонентов, статических сайтов и т.д. Если вам нравится то, о чём я пишу в этом канале, то вам, с большой вероятностью, понравится и то, о чём пишет Крис.

Отказаться от зависимостей и не умереть

В 435-м выпуске Веб-стандартов обсуждали ванильный дауншифтинг. Поводом для этого послужил запуск сайта Plain Vanilla. На этом сайте демонстрируются подходы к созданию компонентов, стилизации, роутингу, модульности, деплою, тестированию и менеджменту состояния с использованием стандартных HTML, CSS, JavaScript и Web API. Без фреймворков, сборщиков, библиотек и прочих инструментов. Проект интересен как минимум тем, что показывает возможности современного веба. Полезно для тех разработчиков, которые много работают в экосистемах фреймворков и мало смотрят за их пределы. Несмотря на ряд спорных моментов, идея классная.

Одно из замечаний к таким проектам обычно звучит так: “круто, автор сделал todo app на vanilla, а как насчёт полноценного приложения”? Тут мне вспомнился доклад “Отказаться от зависимостей и не умереть” Ильи Черторыльского с конференции Frontendconf. Он в качестве эксперимента поставил себе задачу разработать полноценное приложение в React-стиле без использования зависимостей и посмотреть, насколько современные возможности далеко продвинулись.

Говоря о технических деталях:

- Используется VSCode с плагином для подсветки теговых шаблонных литералов
- Нет node_modules, package.json, package-lock.json, сторонних пакетов и этапа сборки, весь код в папке public
- React-подобная структура component/container с корневым компонентом App и монтированием в точке входа index.js
- Простая типизация при помощи instanceof и подсказки IntelliSense
- Стандартные браузерные ES-модули import/export
- <noscript type="importmap"> для алиасов путей к модулям
- jsconfig.json для настройки алиасов в VSCode для перехода к файлу по клику (оказывается, такой файл существует для обычного JS, по аналогии с tsconfig.json)
- Роутинг на веб-компонентах и History API
- Импорт стилей через Import Attributes (import style from 'style.css' assert { type: 'css' };). Это уже практически стандарт (Stage 3) с той лишь разницей, что синтаксис с assert заменили на with
- Работа с объектом CSSStyleSheet() и adoptedStylesheet. Илья сказал, что это только для ShadowRoot, но на самом деле можно использовать и для Document
- В качестве компонентной модели используются веб-компоненты, в частности Custom Elements и Shadow DOM с классом-обёрткой для более удобного DX (реализован простой DOM diffing, привязки обработчиков событий, ref, storage и т.д.)
- DOMParser для парсинга шаблонов и точечного обновления DOM
- Element Internals, Form-associated Custom Elements и Constraint Validation API для работы веб-компонентов с формами и валидацией
- <dialog> для создания модальных компонентов
- Intl API для локализации дат

В итоге удалось создать приложение внутреннего корпоративного портала для разработчиков. Достаточно большая структура, около сотни компонентов, модалки, формы, авторизация. Получившийся проект дорабатывали как опытные синьоры, так и стажёр. В итоге все разобрались с кодом и смогли реализовать поставленные задачи. По словам Ильи, переход на такой подход удался 50/50, потому что остальная часть проектов в компании написана на React, UIKit сделаны под React и портировать всё это долго и лениво.

Я считаю его опыт успешным. Илья за трое выходных разработал тонкую обёртку над браузерными API и на этом смог построить полноценное работающее приложение без сторонних библиотек и сборщиков. Код читаем, написан в React-стиле, работает достаточно быстро, разработчикам понятно. Это говорит о том, что эксперимент можно считать успешным. Иными словами, на нативных технологиях можно разработать приложение, но не без нюансов, конечно.

Размер DOM

Обычно разработчики не задумываются о количестве элементов в DOM и используют столько, сколько нужно. А иногда используют сильно больше, чем нужно. На многих проектах в DevTools можно увидеть “ёлочку”:

<div>
  <div>
    <div>
      <div>
        <div>
          <div>
            <div>
              <!-- контент -->  
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Предполагаю, что это происходит из-за ограничений фреймворков, когда у компонента мог быть только один корневой элемент. И, конечно, этим корневым элементом выступал <div>. При глубокой вложенности компонентов появлялась “ёлочка”. В современных версиях фреймворков эти ограничения уже не актуальны, но много проектов написано на старых версиях.

Чем плоха такая “ёлочка” и большое количество элементов в DOM? Тем, что это влияет на производительность. На каждый HTML-элемент браузеры создают объект DOM, у которого большое количество свойств, методов, вложенных объектов и связей с другими объектами. Значения всех свойств и связи нужно просчитать. Также браузеры вычисляют значения всех CSS-свойств и положение на экране для отрисовки. Оптимизация работы с DOM происходит постоянно, поэтому все расчёты происходят очень быстро. Тем не менее, чем больше элементов DOM, тем:

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

Поэтому следует избегать “ёлочки” и большого количества элементов в DOM. Google Lighthouse выдаст предупреждение “избегайте чрезмерного размера DOM”, если:

- в документе более 1400 элементов
- есть элементы с глубиной вложенности более 32 уровней
- есть элементы, у которых более 60 дочерних элементов

На эти цифры и стоит опираться. Говоря об общем количестве элементов, стоит придерживаться принципа чем меньше, тем лучше.

Как уменьшить количество элементов:

- фрагменты в React <></>
- виртуализация большого набора данных (отображение только той части списка или таблицы, которая видна на экране)
- разбиение большого количества данных на страницы (пагинация), при этом не более 60 элементов набора данных на страницу
- фильтрация, поиск и группировка большого количества данных для уменьшения выборки
- альтернативные решения вместо бесконечных лент, ленивой дозагрузки и формирования большого набора данных на одной странице
- динамическая генерация интерфейса (модальные окна, тултипы), но осторожно, потому что генерировать сложные интерфейсы на лету тоже не очень производительно
- раскладка контента по областям при помощи CSS Grid вместо дополнительных контейнеров и обёрток
- адаптивный дизайн, чтобы избегать отдельных скрытых частей интерфейса для разных экранов

State of CSS 2024

Стартовал ежегодный опрос State of CSS 2024 о состоянии CSS. Этот опрос важен, поскольку разработчики спецификаций и браузеров смотрят на результаты и делают выводы. Поэтому призываю всех выделить время и пройти этот опрос. Также пошарьте с коллегами, пусть тоже пройдут.

Не делайте сайты как SPA

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

Когда я делал этот сайт, это была обычная вёрстка, интегрированная в WordPress. Клиент решил обновить сайт и обратился к веб-студии. Они разработали новый контентный сайт в виде SPA… Сайт из 5 страниц с текстом, картинками, видео и парочкой интерактивных элементов сделан как SPA. Кажется, что в индустрии стало нормой забивать гвозди микроскопом, а разработчиков с микроскопом в руках это особо не заботит.

Что плохого в SPA для сайтов?

- Контент состоит из <div id="app"></div>. Получается, что на контентном сайте изначально нет контента. Краулеры, парсеры и прочие сканеры страниц ничего не видят. Google умеет обрабатывать такие сайты, но задействует специальный механизм, который работает дольше и хуже. С другими поисковиками ситуация сложнее. В итоге наработанные ранее позиции сайта в выдаче будут потеряны.

- Контент завязан на JavaScript. Если по тем или иным причинам JavaScript недоступен, сайт вы не увидите. Золотое правило веб-разработки: HTML для контента и структуры, CSS для внешнего вида, JavaScript для интерактивности. Использование JavaScript для контента добавляет больше проблем, чем даёт плюсов. Переходы между страницами без перезагрузки не стоят того.

- Плохие метрики Core Web Vitals. Конкретно у нового сайта First Contentful Paint 2.1-2.9c, Largest Contentful Paint 7.5-8.2c. То есть усреднённый пользователь видит сайт только через 2-3 секунды, а изображение на станице через 8 секунд. И это на небольшой странице. Core Web Vitals влияют на SEO и восприятие пользователей. А в будущем у сайта начнутся проблемы с производительностью, когда маркетологи добавят туда скрипты для аналитики и рекламы.

- Лишняя сложность. Для вывода статического контента зачем-то нужен условный React, хуки, JSX, для переключения страниц нужен отдельный пакет с роутером и его настройка, для стилей нужен пакет с хитрой обработкой под капотом, для работы всего этого нужен сборщик с сложной конфигурацией. И весь этот оверхед для вывода статического контента.

- Налог на фреймворк. С фреймворком приходят мегабайты зависимостей в node_modules, сложная сборка и ограничения экосистемы. Попробуйте вернуться с доработками на сайт через пол года. Получите кучу ошибок в консоли при попытке запустить всё это дело. Маленькие правки сайта превращаются в борьбу с зависимостями и инструментарием.

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

Мой посыл: не делайте контентные сайты как SPA. Отдавайте предпочтение Static Site Generation (SSG) или Server Side Rendering (SSR). Генерируйте и отдавайте с сервера готовый HTML, подключайте внешний CSS и сверху точечно добавляйте JS для интерактивных компонентов. Это во всех смыслах работает лучше и быстрее. А SPA оставьте для комплексных приложений со сложным интерфейсом и взаимодействиями.

⬆️

Забыл упомянуть про проблемы с доступностью. В SPA необходимо дополнительно управлять заголовком <noscript>, следить за положением фокуса на странице, и реализовывать механизм оповещения о перерисовке страницы. Лишняя сложность и код.

You don't know HTML: <search>

Элемент <search> — это относительно новый элемент HTML, который, как легко догадаться, предназначен для разметки поиска. Это семантический контейнер с блочным отображением (display: block) и встроенной ролью search.

Согласно спецификации WAI-ARIA, роль search — это ориентир для набора объектов пользовательского интерфейса, которые реализуют функциональность поиска. Яркий пример — это форма с полем для ввода поискового запроса и кнопкой поиска.

<search>
  <form action="/search" method="get">
    <label for="q">Поиск:</label>
    <input type="search" id="q" name="q" autocomplete="off">
    <button aria-label="Найти">🔍</button>
  </form>
</search>

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

Элемент <search> уже поддерживается во всех современных браузерах. В более старых браузерах можно использовать эквивалент <div role="search"> до более широкой поддержки <search>. Или же можно использовать <search>, но подстраховаться следующим образом:

<search role="search">
  <!-- средства поиска -->
</search>

В CSS при этом важно не забыть указать:

search {
  display: block;
}

#ydkhtml

Placeholder

У некоторых текстовых полей ввода есть возможность указать атрибут placeholder. Часто этот атрибут используется не по назначению. Основная задумка этого атрибута — предоставить пользователю короткую подсказку с образцом данных или ожидаемым форматом ввода, когда в поле нет заранее предустановленного значения (value).

Вот примеры правильного (✅) и неправильного (❌) использования атрибута:

<!-- ❌ Замена лейбла -->
<input 
  type="text"
  id="name"
  name="name"
  placeholder="Имя"
> 

<!-- ✅ Пример данных -->
<label for="name">
  Ваше имя:
</label>
<input
  type="text"
  id="name"
  name="name"
  placeholder="Алексей"
>

<!-- ... -->

<!-- ❌ Дублирование лейбла -->
<label for="email">
  Email:
</label>
<input
  type="email"
  id="email"
  name="email"
  placeholder="Email"
> 

<!-- ✅ Пример данных -->
<label for="email">
  Email:
</label>
<input
  type="email"
  id="email"
  name="email"
  placeholder="john.doe@mail.com"
> 

<!-- ... -->

<!-- ❌ Призыв к действию -->
<label for="birthdate">
  Дата рождения:
</label>
<input
  type="text"
  id="birthdate"
  name="birthdate"
  placeholder="Введите дату рождения"
> 

<!-- ✅ Ожидаемый формат -->
<label for="birthdate">
  Дата рождения:
</label>
<input
  type="text"
  id="birthdate"
  name="birthdate"
  placeholder="ДД.ММ.ГГГГ"
> 

<!-- ... -->

<!-- ❌ Маска -->
<label for="name">
  Телефон:
</label>
<input
  type="tel"
  id="phone"
  name="phone"
  placeholder="+375 (__) ___-__-__"
> 

<!-- ✅ Пример данных -->
<label for="name">
  Телефон:
</label>
<input
  type="tel"
  id="phone"
  name="phone"
  placeholder="+375 (12) 345-67-89"
> 

<!-- ... -->

<!-- ❌ Инструкция -->
<label for="passnum">
  Номер паспорта:
</label>
<input
  type="text"
  id="passnum"
  name="passnum"
  placeholder="2 буквы и 7 цифр с предпоследней страницы паспорта"
> 

<!-- ✅ Пример данных -->
<label for="passnum">
  Номер паспорта:
</label>
<input
  type="text"
  id="passnum"
  name="passnum"
  placeholder="AH1234567"
  aria-describedby="info"
> 
<p id="info">2 буквы и 7 цифр с предпоследней страницы паспорта</p>

Таким образом, placeholder не должен:

- Заменять лейбл
- Дублировать лейбл
- Призывать к действию
- Быть маской ввода
- Предоставлять инструкцию

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

input::placeholder {
  /* Стили текста placeholder */
}

input:placeholder-shown {
  /* Стили input, когда виден placeholder */
}

Автор выложил бесплатно свою книгу на сервис. При совершении "покупки" я вижу это. Сервис предлагает мне подписаться на еженедельные и ежемесячные маркетинговые рассылки.

Подробно расписано, что к чему, и есть два чекбокса, подтверждающих моё согласие на подписку. Во-первых, чекбоксы проставлены по умолчанию, но это ладно. Во-вторых, их нельзя снять! Нажатие ни к чему не приводит! То есть это выбор без выбора. Зачем тогда, спрашивается? Неужели круто, когда пользователь принудительно подписывается на то, что ему не нужно, а потом специально отписывается и кидает e-mail в спам-список?

Новые 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 по МСК трек: "Радость". Четвертая встреча посвящена тем моментам, которые приносят радость и удовлетворение в работе над цифровой доступностью.

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




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

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