Web Haptics API – очень ждём?

04.09.2026 • api

Введение

Нет, пока ещё ничего не реализовали. Есть только документ, в котором описывается прототип спеки.

Что это, какие проблемы решает, и почему мне кажется важным это АПИ?

Проблема

Мобильные приложения за годы установили новый “стандарт” взаимодействия с пользователем – обратная связь на разнообразные действия. Потянули к экрану поиска – вибрация. Нажали какой-то элемент – тоже. Поскроллили выбор месяца – снова маленькое подтверждение, что произошёл сдвиг на 1 элемент.

Эти вибрации обычно зовут “хаптиками”, а обратную связь – haptic feedback. Они поддержаны и на Андроиде, и на iOS.

Что же до веба, то там этого нет (со звёздочкой). Если речь о вебвью для какого-то приложения, то одна из самых частых апишек, которые прокидываются от натива в веб – как раз-таки хаптики. Мы годами обсуждаем функции веб-платформы, чтобы достичь возможностей полноценных приложений. MIDI, Bluetooth, USB и прочие файловые системы – а реакции на взаимодействие от пользователя всё ещё нет.

Читатели могут вспомнить navigator.vibrate:

navigator.vibrate

Плашка неточная – в Файерфоксе уже удалено. В Сафари поддержки никогда не было. Давайте попробуем теоретизировать, почему Apple так и не добавила поддержку:

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

О последнем подробнее. Думаю, те, кто не сталкивался, могут задать резонный вопрос – функция вибрации есть, настройка интенсивности и шаблон есть, что ещё нужно? А дело в том, что вибрация из vibrate работает… как молоток. Иными словами, грубо, резко, однобоко и совсем не похоже на системные хаптики. Нельзя толком добиться ни схожей длительности, ни похожего эффекта.

Поэтому, если мы говорим об единственном поддерживаемом браузерном движке – Хромиуме, то даже в нём есть смысл не использовать vibrate, а прокидывать реализацию вибрации из натива.

Прототип апи

Спека описывает две части апи – JS и CSS. Начнём с JS.

navigator.playHaptics(effect, intensity);

Дальше мой вольный перевод таблички из доки с вариантами effect:

effect	Описание	Когда использовать
hint	Лёгкая подсказка, что элемент интерактивен или может последовать действие	Фокус поля ввода или перенос над областью во время драг-н-дропа
edge	Жёсткий сигнал о том, что достигнута граница / лимит	Ошибка валидации, достаточный скролл для pull-to-refresh, граница скролла
tick	Заметное “биение” о шаге или смене переключателя	Смена значения в переключателе, остановка scroll snap
align	Чёткое подтверждение, что элемент закреплён на месте или выровнен по направляющей	Перемещение около направляющих, “растягивание” окон около границ экрана, достижение зума в 100%

Все значения так или иначе маппятся в нативные из операционной системы. intensity – число от 0 до 1, необязательное.

Функция ничего не возвращает, и это важно. Тем самым пользователей нельзя “зафингерпринтить” (отследить), есть ли у них поддержка хаптиков на уровне устройства. Поэтому просто вызываем функцию и надеемся, что она что-то сделает. Также важно и то, что функцию можно вызвать только по действию пользователя.

Теперь к CSS. Авторы предлагают интересный подход с директивой @haptic, которая бы находилась внутри блока:

button:hover {
    color: blue;
    @haptic tick;
}

Через пробел можно задать и intensity: @haptic tick 0.8. Данная конструкция должна работать, когда блок стал срабатывать по селектору, а до этого не работал. Можно провести некие аналии с @starting-style.

Авторы предлагают и возможность использовать псевдоклассы (от :active до :snapped), и положить директиву @haptic внутрь @keyframes, и возможность отреагировать на настройки пользователя через prefers-haptics.

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

Какие проблемы были решены?

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

Что для меня остаётся чужеродным, так это вариант синтаксиса с @haptic в CSS. В любом случае, какой бы вариант не был выбран, синтаксис в CSS решает проблему декларативного подхода, в том числе с низкими задержками (в теории, код на JS может выполняться с задержкой после события).

Уважение к настройкам пользователя и к окружению. Хаптики – системные, настройки – тоже. Авторы даже упоминают десктопы, но тут уже я не очень понимаю, о чём речь)

Почему может получиться?

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

Учтены минусы прошлых подходов.

Авторы с команды Edge, а не из Chrome или Safari. Возможно, был нужен кто-то из третьей стороны, чтобы всех помирить и чтобы АПИ всё же появилось?

Итого

С учётом текущего развития веб-платформы, мы можем получить вариант Web Haptics уже в следующем году. А с ним – и новые ощущения от привычных сайтов, новое взаимодействие с пользователем и новые “стандарты” по разработке сайтов.

Очень хочу, чтобы всё получилось. Ну или кто-то придумает ещё какой-то вариант апи, больно насущная проблема.

Обсудить в Telegram