Пробная версия источника для нового HTML <permission> элемент

Thomas Steiner

Существует ряд императивных методов запроса разрешения на использование таких мощных функций, как доступ к местоположению в веб-приложениях. Эти методы сопряжены с рядом проблем, поэтому команда разработчиков разрешений Chrome экспериментирует с новым декларативным методом: специальным HTML-элементом <permission> . Этот элемент находится на стадии первоначального тестирования в Chrome 126, и в конечном итоге мы надеемся стандартизировать его.

Необходимые методы запроса разрешения

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

Запрашивать информацию неявно при первом использовании, а не запрашивать её явно заранее.

API геолокации — это мощный API, основанный на принципе неявного запроса разрешений при первом использовании. Например, когда приложение вызывает метод navigator.geolocation.getCurrentPosition() , запрос на предоставление разрешений автоматически появляется при первом вызове. Другой пример — navigator.mediaDevices.getUserMedia() .

Другие API, такие как API уведомлений или API ориентации и движения устройства , обычно имеют явный способ запроса разрешения через статический метод, например, Notification.requestPermission() или DeviceMotionEvent.requestPermission() .

Проблемы, связанные с императивными методами запроса разрешения.

Спам разрешений

Раньше веб-сайты могли вызывать такие методы, как navigator.mediaDevices.getUserMedia() или Notification.requestPermission() , а также navigator.geolocation.getCurrentPosition() , сразу после загрузки сайта. Запрос на разрешение появлялся до того, как пользователь взаимодействовал с сайтом. Это иногда называют спамом разрешений, и он затрагивает оба подхода: как неявный запрос при первом использовании, так и явный запрос заранее.

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

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

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

Контекстуализация разрешений

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

Легкого решения нет.

Наконец, пользователям слишком легко попасть в тупик. Например, после блокировки доступа к какой-либо функции, пользователю приходится искать в выпадающем меню информации о сайте пункт «Сбросить разрешения» или «Включить заблокированные разрешения». В худшем случае оба варианта требуют полной перезагрузки страницы до тех пор, пока обновленные настройки не вступят в силу. Сайты не предоставляют пользователям удобного способа изменить существующее состояние разрешений и вынуждены кропотливо объяснять, как это сделать, как показано на скриншоте Google Maps внизу страницы.

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

Декларативный элемент <permission>

Для решения проблем, описанных в этом посте, команда разработчиков Chrome, отвечающая за разрешения, запустила пробную версию нового HTML-элемента <permission> . Этот элемент позволяет разработчикам декларативно запрашивать разрешение на использование, пока что, лишь части мощных функций, доступных веб-сайтам. В простейшем виде он используется, как показано в следующем примере:

<permission type="camera" />

До сих пор активно обсуждается вопрос о том, должен ли элемент <permission> быть пустым элементом или нет. Пустой элемент — это самозакрывающийся элемент в HTML, который не может иметь дочерних узлов, что в HTML означает, что он не может иметь закрывающего тега.

Атрибут type

Атрибут type содержит список запрашиваемых разрешений, разделённых пробелами. На момент написания этой статьи допустимыми значениями являются 'camera' , 'microphone' и camera microphone (разделённые пробелами). По умолчанию этот элемент отображается аналогично кнопкам с минимальным стилем пользовательского агента.

Атрибут type-ext

Для некоторых разрешений, допускающих дополнительные параметры, атрибут type-ext принимает пары ключ-значение, разделенные пробелами, например, precise:true для разрешения геолокации.

Атрибут lang

Текст кнопки предоставляется браузером и должен быть единообразным, поэтому его нельзя изменить напрямую. Браузер изменяет язык текста в зависимости от унаследованного языка документа или цепочки родительских элементов, либо от необязательного атрибута lang . Это означает, что разработчикам не нужно самостоятельно локализовать элемент <permission> . Если элемент <permission> выйдет за рамки первоначального этапа тестирования, для каждого типа разрешения может быть предусмотрено несколько строк или значков для повышения гибкости. Если вас интересует использование элемента <permission> и вам нужна конкретная строка или значок, свяжитесь с нами !

Поведение

При взаимодействии пользователя с элементом <permission> он может переключаться между различными этапами:

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

  

• Если они разрешали эту функцию раньше, они могут продолжать разрешать её или прекратить её разрешать.

  

• Если они ранее запрещали какую-либо функцию, они могут продолжать запрещать её или разрешить её на этот раз.

  

Текст элемента <permission> автоматически обновляется в зависимости от статуса. Например, если разрешение на использование функции было предоставлено, текст меняется на «Использование функции разрешено». Если же сначала необходимо предоставить разрешение, текст меняется на «Приглашение пользователя к использованию функции». Сравните предыдущий снимок экрана со следующим, чтобы увидеть два состояния.

CSS дизайн

Чтобы пользователи могли легко распознать кнопку как поверхность для доступа к мощным функциям, стилизация элемента <permission> ограничена. Если ограничения на стилизацию не подходят для вашего случая, мы будем рады узнать , как и почему! Хотя не все потребности в стилизации могут быть удовлетворены, мы надеемся найти безопасные способы разрешить более широкую стилизацию элемента <permission> после первоначального тестирования. В следующей таблице подробно описаны некоторые свойства, к которым применяются ограничения или специальные правила. В случае нарушения любого из правил элемент <permission> будет отключен, и с ним нельзя будет взаимодействовать. Любые попытки взаимодействия с ним приведут к исключениям, которые можно перехватить с помощью JavaScript. Сообщение об ошибке будет содержать более подробную информацию об обнаруженном нарушении.

Следующие свойства CSS можно использовать как обычно:

• font-kerning
• font-optical-sizing
• font-stretch
• font-synthesis-weight
• font-synthesis-style
• font-synthesis-small-caps
• font-feature-settings
• forced-color-adjust
• text-rendering
• align-self
• anchor-name aspect-ratio
• border (и все свойства border-* )
• clear
• color-scheme
• contain
• contain-intrinsic-width
• contain-intrinsic-height
• container-name
• container-type
• counter-*
• flex-*
• float
• height
• isolation
• justify-self
• left
• order
• orphans
• outline-* (за исключением отмеченного ранее параметра outline-offset )
• overflow-anchor
• overscroll-behavior-*
• page
• position
• position-anchor
• content-visibility
• right
• scroll-margin-*
• scroll-padding-*
• text-spacing-trim
• top
• visibility
• x
• y
• ruby-position
• user-select
• width
• will-change
• z-index

Кроме того, можно использовать все логически эквивалентные свойства (например, inline-size эквивалентно width ), следуя тем же правилам, что и их эквиваленты.

Псевдоклассы

Существуют два специальных псевдокласса, которые позволяют стилизовать элемент <permission> в зависимости от его состояния:

• :granted : Псевдокласс :granted позволяет применять специальные стили при предоставлении разрешения.
• :invalid : Псевдокласс :invalid позволяет применять специальные стили к элементу, находящемуся в недопустимом состоянии, например, при отображении в iframe, доступном из другого источника.

permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

События JavaScript

Элемент <permission> предназначен для использования совместно с API разрешений . Можно отслеживать ряд событий:

• onpromptdismiss : Это событие срабатывает, когда пользователь закрывает запрос на разрешение, инициированный элементом (например, нажав кнопку закрытия или щелкнув вне запроса).

• onpromptaction : Это событие срабатывает, когда запрос на разрешение, инициированный элементом, был обработан пользователем путем выполнения каких-либо действий в отношении самого запроса. Это не обязательно означает, что состояние разрешения изменилось; пользователь мог выполнить действие, которое поддерживает статус-кво (например, продолжить разрешать доступ).

• onvalidationstatuschange : Это событие срабатывает, когда элемент переходит из состояния "valid" в состояние "invalid" . Элемент считается "valid" если браузер доверяет целостности сигнала, если пользователь щелкнет по нему, и "invalid" в противном случае, например, если элемент частично закрыт другим HTML-контентом.

Вы можете зарегистрировать обработчики событий для этих событий непосредственно в HTML-коде ( <permission type="…" onpromptdismiss="alert('The prompt was dismissed');" /> ), или с помощью addEventListener() для элемента <permission> , как показано в следующем примере.

<permission type="camera" />
<script>
  const permission = document.querySelector('permission');
  permission.addEventListener('promptdismiss', showCameraWarning);

  function showCameraWarning() {
    // Show warning that the app isn't fully usable
    // unless the camera permission is granted.
  }

  const permissionStatus = await navigator.permissions.query({name: "camera"});
  
  permissionStatus.addEventListener('change', () => {
    // Run the check when the status changes.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
  });

  // Run the initial check.
  if (permissionStatus.state === "granted") {
    useCamera();
  }
</script>

Обнаружение признаков

Если браузер не поддерживает HTML-элемент, он его не отобразит. Это означает, что если в вашем HTML-коде есть элемент <permission> , ничего не произойдет, если браузер о нем не знает. Тем не менее, вы можете отслеживать поддержку с помощью JavaScript, например, чтобы создать запрос на разрешение, запускаемый при нажатии обычной <button> .

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

Испытание происхождения

Чтобы протестировать элемент <permission> на вашем сайте с реальными пользователями, зарегистрируйтесь для участия в пробной версии . Инструкции по подготовке сайта к использованию пробной версии см. в разделе «Начало работы с пробными версиями». Пробная версия будет запущена для Chrome версий 126–131 (19 февраля 2025 г.).

Демо

Ознакомьтесь с демоверсией и исходным кодом на GitHub. Вот скриншот работы приложения в поддерживаемом браузере.

Обратная связь

Мы будем рады узнать, как <permission> работает в вашем случае. Не стесняйтесь ответить на один из вопросов в репозитории или создать новый. Публичные сигналы в репозитории для элемента <permission> позволят нам и другим браузерам узнать о вашем интересе к нему.

Часто задаваемые вопросы

• Чем это лучше обычной <button> в сочетании с API разрешений? Нажатие <button> — это действие пользователя, но браузеры не могут проверить, связано ли оно с запросом на разрешение. Если пользователь нажал на <permission> , браузер может быть уверен, что нажатие связано с запросом на разрешение. Это позволяет браузеру упростить процессы, которые в противном случае были бы гораздо более рискованными. Например, позволяя пользователю легко отменить блокировку разрешения.
• Что делать, если другие браузеры не поддерживают элемент <permission> ? Элемент <permission> можно использовать в качестве поэтапного улучшения. В браузерах, не поддерживающих этот элемент, можно использовать классический процесс получения разрешений. Например, на основе нажатия обычной <button> . Команда разработчиков, занимающаяся вопросами разрешений, также работает над полифилом. Отметьте репозиторий GitHub звездочкой, чтобы получать уведомления о его готовности.
• Обсуждалось ли это с другими производителями браузеров? Элемент <permission> активно обсуждался на конференции W3C TPAC в 2023 году на секционном заседании . Вы можете ознакомиться с публичными заметками с заседания . Команда Chrome также запросила официальные позиции по стандартам у обоих производителей, см. раздел «Ссылки по теме» . Элемент <permission> является предметом постоянных обсуждений с другими браузерами, и мы надеемся стандартизировать его.
• Действительно ли это должен быть пустой элемент? Вопрос о том, должен ли элемент <permission> быть пустым элементом, до сих пор активно обсуждается . Если у вас есть замечания, пожалуйста, оставьте свой комментарий в соответствующем разделе.

Ссылки по теме

• Пояснительная записка
• Позиция стандартов WebKit
• Позиция Mozilla по стандартам

Благодарности

Данный документ был проверен Балажем Энгеди , Томасом Нгуеном , Пенелопой Маклаклан , Мариан Харбах , Дэвидом Уорреном и Рэйчел Эндрю .

Thomas Steiner

Существует ряд императивных методов запроса разрешения на использование таких мощных функций, как доступ к местоположению в веб-приложениях. Эти методы сопряжены с рядом проблем, поэтому команда разработчиков разрешений Chrome экспериментирует с новым декларативным методом: специальным HTML-элементом <permission> . Этот элемент находится на стадии первоначального тестирования в Chrome 126, и в конечном итоге мы надеемся стандартизировать его.

Необходимые методы запроса разрешения

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

Запрашивать информацию неявно при первом использовании, а не запрашивать её явно заранее.

API геолокации — это мощный API, основанный на принципе неявного запроса разрешений при первом использовании. Например, когда приложение вызывает метод navigator.geolocation.getCurrentPosition() , запрос на предоставление разрешений автоматически появляется при первом вызове. Другой пример — navigator.mediaDevices.getUserMedia() .

Другие API, такие как API уведомлений или API ориентации и движения устройства , обычно имеют явный способ запроса разрешения через статический метод, например, Notification.requestPermission() или DeviceMotionEvent.requestPermission() .

Проблемы, связанные с императивными методами запроса разрешения.

Спам разрешений

Раньше веб-сайты могли вызывать такие методы, как navigator.mediaDevices.getUserMedia() или Notification.requestPermission() , а также navigator.geolocation.getCurrentPosition() , сразу после загрузки сайта. Запрос на разрешение появлялся до того, как пользователь взаимодействовал с сайтом. Это иногда называют спамом разрешений, и он затрагивает оба подхода: как неявный запрос при первом использовании, так и явный запрос заранее.

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

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

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

Контекстуализация разрешений

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

Легкого решения нет.

Наконец, пользователям слишком легко попасть в тупик. Например, после блокировки доступа к какой-либо функции, пользователю приходится искать в выпадающем меню информации о сайте пункт «Сбросить разрешения» или «Включить заблокированные разрешения». В худшем случае оба варианта требуют полной перезагрузки страницы до тех пор, пока обновленные настройки не вступят в силу. Сайты не предоставляют пользователям удобного способа изменить существующее состояние разрешений и вынуждены кропотливо объяснять, как это сделать, как показано на скриншоте Google Maps внизу страницы.

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

Декларативный элемент <permission>

Для решения проблем, описанных в этом посте, команда разработчиков Chrome, отвечающая за разрешения, запустила пробную версию нового HTML-элемента <permission> . Этот элемент позволяет разработчикам декларативно запрашивать разрешение на использование, пока что, лишь части мощных функций, доступных веб-сайтам. В простейшем виде он используется, как показано в следующем примере:

<permission type="camera" />

До сих пор активно обсуждается вопрос о том, должен ли элемент <permission> быть пустым элементом или нет. Пустой элемент — это самозакрывающийся элемент в HTML, который не может иметь дочерних узлов, что в HTML означает, что он не может иметь закрывающего тега.

Атрибут type

Атрибут type содержит список запрашиваемых разрешений, разделённых пробелами. На момент написания этой статьи допустимыми значениями являются 'camera' , 'microphone' и camera microphone (разделённые пробелами). По умолчанию этот элемент отображается аналогично кнопкам с минимальным стилем пользовательского агента.

Атрибут type-ext

Для некоторых разрешений, допускающих дополнительные параметры, атрибут type-ext принимает пары ключ-значение, разделенные пробелами, например, precise:true для разрешения геолокации.

Атрибут lang

Текст кнопки предоставляется браузером и должен быть единообразным, поэтому его нельзя изменить напрямую. Браузер изменяет язык текста в зависимости от унаследованного языка документа или цепочки родительских элементов, либо от необязательного атрибута lang . Это означает, что разработчикам не нужно самостоятельно локализовать элемент <permission> . Если элемент <permission> выйдет за рамки первоначального этапа тестирования, для каждого типа разрешения может быть предусмотрено несколько строк или значков для повышения гибкости. Если вас интересует использование элемента <permission> и вам нужна конкретная строка или значок, свяжитесь с нами !

Поведение

При взаимодействии пользователя с элементом <permission> он может переключаться между различными этапами:

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

  

• Если они разрешали эту функцию раньше, они могут продолжать разрешать её или прекратить её разрешать.

  

• Если они ранее запрещали какую-либо функцию, они могут продолжать запрещать её или разрешить её на этот раз.

  

Текст элемента <permission> автоматически обновляется в зависимости от статуса. Например, если разрешение на использование функции было предоставлено, текст меняется на «Использование функции разрешено». Если же сначала необходимо предоставить разрешение, текст меняется на «Приглашение пользователя к использованию функции». Сравните предыдущий снимок экрана со следующим, чтобы увидеть два состояния.

CSS дизайн

Чтобы пользователи могли легко распознать кнопку как поверхность для доступа к мощным функциям, стилизация элемента <permission> ограничена. Если ограничения на стилизацию не подходят для вашего случая, мы будем рады узнать , как и почему! Хотя не все потребности в стилизации могут быть удовлетворены, мы надеемся найти безопасные способы разрешить более широкую стилизацию элемента <permission> после первоначального тестирования. В следующей таблице подробно описаны некоторые свойства, к которым применяются ограничения или специальные правила. В случае нарушения любого из правил элемент <permission> будет отключен, и с ним нельзя будет взаимодействовать. Любые попытки взаимодействия с ним приведут к исключениям, которые можно перехватить с помощью JavaScript. Сообщение об ошибке будет содержать более подробную информацию об обнаруженном нарушении.

Следующие свойства CSS можно использовать как обычно:

• font-kerning
• font-optical-sizing
• font-stretch
• font-synthesis-weight
• font-synthesis-style
• font-synthesis-small-caps
• font-feature-settings
• forced-color-adjust
• text-rendering
• align-self
• anchor-name aspect-ratio
• border (и все свойства border-* )
• clear
• color-scheme
• contain
• contain-intrinsic-width
• contain-intrinsic-height
• container-name
• container-type
• counter-*
• flex-*
• float
• height
• isolation
• justify-self
• left
• order
• orphans
• outline-* (за исключением отмеченного ранее параметра outline-offset )
• overflow-anchor
• overscroll-behavior-*
• page
• position
• position-anchor
• content-visibility
• right
• scroll-margin-*
• scroll-padding-*
• text-spacing-trim
• top
• visibility
• x
• y
• ruby-position
• user-select
• width
• will-change
• z-index

Кроме того, можно использовать все логически эквивалентные свойства (например, inline-size эквивалентно width ), следуя тем же правилам, что и их эквиваленты.

Псевдоклассы

Существуют два специальных псевдокласса, которые позволяют стилизовать элемент <permission> в зависимости от его состояния:

• :granted : Псевдокласс :granted позволяет применять специальные стили при предоставлении разрешения.
• :invalid : Псевдокласс :invalid позволяет применять специальные стили к элементу, находящемуся в недопустимом состоянии, например, при отображении в iframe, доступном из другого источника.

permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

События JavaScript

Элемент <permission> предназначен для использования совместно с API разрешений . Можно отслеживать ряд событий:

• onpromptdismiss : Это событие срабатывает, когда пользователь закрывает запрос на разрешение, инициированный элементом (например, нажав кнопку закрытия или щелкнув вне запроса).

• onpromptaction : Это событие срабатывает, когда запрос на разрешение, инициированный элементом, был обработан пользователем путем выполнения каких-либо действий в отношении самого запроса. Это не обязательно означает, что состояние разрешения изменилось; пользователь мог выполнить действие, которое поддерживает статус-кво (например, продолжить разрешать доступ).

• onvalidationstatuschange : Это событие срабатывает, когда элемент переходит из состояния "valid" в состояние "invalid" . Элемент считается "valid" если браузер доверяет целостности сигнала, если пользователь щелкнет по нему, и "invalid" в противном случае, например, если элемент частично закрыт другим HTML-контентом.

Вы можете зарегистрировать обработчики событий для этих событий непосредственно в HTML-коде ( <permission type="…" onpromptdismiss="alert('The prompt was dismissed');" /> ), или с помощью addEventListener() для элемента <permission> , как показано в следующем примере.

<permission type="camera" />
<script>
  const permission = document.querySelector('permission');
  permission.addEventListener('promptdismiss', showCameraWarning);

  function showCameraWarning() {
    // Show warning that the app isn't fully usable
    // unless the camera permission is granted.
  }

  const permissionStatus = await navigator.permissions.query({name: "camera"});
  
  permissionStatus.addEventListener('change', () => {
    // Run the check when the status changes.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
  });

  // Run the initial check.
  if (permissionStatus.state === "granted") {
    useCamera();
  }
</script>

Обнаружение признаков

Если браузер не поддерживает HTML-элемент, он его не отобразит. Это означает, что если в вашем HTML-коде есть элемент <permission> , ничего не произойдет, если браузер о нем не знает. Тем не менее, вы можете отслеживать поддержку с помощью JavaScript, например, чтобы создать запрос на разрешение, запускаемый при нажатии обычной <button> .

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

Испытание происхождения

Чтобы протестировать элемент <permission> на вашем сайте с реальными пользователями, зарегистрируйтесь для участия в пробной версии . Инструкции по подготовке сайта к использованию пробной версии см. в разделе «Начало работы с пробными версиями». Пробная версия будет запущена для Chrome версий 126–131 (19 февраля 2025 г.).

Демо

Ознакомьтесь с демоверсией и исходным кодом на GitHub. Вот скриншот работы приложения в поддерживаемом браузере.

Обратная связь

We would love to hear from you how <permission> works for your use case. Feel free to respond to one of the Issues in the repository , or file a new one. Public signals in the repo for the <permission> element will let us and other browsers know you're interested in it.

Часто задаваемые вопросы

• How is this better than a regular <button> paired with the Permissions API? A click of a <button> is a user gesture, but browsers have no way of verifying that it's connected to the request for asking for permission. If the user has clicked a <permission> , the browser can be sure that the click is related to a permission request. This allows the browser to facilitate flows that otherwise would be a lot more risky. For example, allowing the user to easily undo the blocking of a permission.
• What if other browsers don't support the <permission> element? The <permission> element can be used as a progressive enhancement. On non-supporting browsers, a classic permission flow can be used. For example, based on the click of a regular <button> . The permissions team are also working on a polyfill. Star the GitHub repo to be notified when it's ready.
• Was this discussed with other browser vendors? The <permission> element was actively discussed at W3C TPAC in 2023 in a breakout session . You can read the public session notes . The Chrome team has also asked for formal Standards Positions from both vendors, see the Related links section. The <permission> element is an ongoing topic of discussions with other browsers and we're hoping to standardize it.
• Should this actually be a void element? It's still being actively debated whether <permission> should be a void element or not. If you have feedback, chime in on the Issue.

Ссылки по теме

• Пояснительная записка
• Позиция стандартов WebKit
• Позиция Mozilla по стандартам

Благодарности

This document was reviewed by Balázs Engedy , Thomas Nguyen , Penelope McLachlan , Marian Harbach , David Warren , and Rachel Andrew .