Enhancements to the proposed <permission> element

Thomas Steiner

Published: May 12, 2025

The proposed HTML <permission> element is still in origin trial, as the Chrome team refines it, building upon the foundation laid in our initial origin trial. This post shares enhancements that aim to provide you with more flexibility and control when requesting permissions within web applications. For a comprehensive overview of the <permission> element's introduction and its initial capabilities, refer to our earlier article An origin trial for a new HTML <permission> element.

Content support for fallback UX

The <permission> element was initially defined as a void element without content until Chrome 136. From Chrome 137 it supports content, which means it's now required to mark it up with opening and closing tags:

<permission>
  <!-- optional content -->
</permission>

This change lets you include fallback user interfaces within the element's content. These fallbacks are displayed in browsers that don't support the <permission> element or when an unsupported type attribute is specified. This ensures a more graceful degradation and improved user experience across different browser environments.

<!-- Invalid `type` attribute value -->
<permission type="not-supported">
  <p>Your browser does not support the specified <code>type</code>.</p>
</permission>

More detailed programmatic feature detection

To help you determine support for specific permission types, we've introduced a static method, isTypeSupported():

HTMLPermissionElement.isTypeSupported('geolocation');

This method returns a boolean indicating whether the specified permission type is supported. Combined with the existing feature detection, typeof HTMLPermissionElement !== 'undefined', you can now programmatically make sure both support for the <permission> element and support for specific permission types.

Note that you can also pass multiple space-separated permission types (for example, "camera microphone") and it will return whether the overall string is a valid "type" value. For example, calling isTypeSupported() with the following parameters returns these results:

• "camera" → true
• "geolocation" → true
• "camera geolocation" → false (Even though the types are individually supported, the combination is not.)

Updated event names

In Chrome 136, we introduced two new events to replace the earlier ones:

• onpromptdismiss (replaces ondismiss)
• onpromptaction (replaces onresolve)

These new events provide clearer semantics and better align with the element's behavior. The older events will be deprecated in Chrome 138, so we recommend updating your event handlers accordingly.

Icon support

We're working towards enabling icon support within the <permission> element, targeted for Chrome 138. This feature will let you display predefined icons corresponding to the permission type, with limited styling options such as color and size adjustments. The exact API details are still being finalized. 

The following examples show the default, a different fill color, and no fill color but with a black outline.

Default styling

Modified styling

The following examples show exemplary modifications to the default styling.

Change of the icon color

::permission-icon {
  fill: blue;
}

Change of the icon outline

::permission-icon {
  fill: white;
  stroke: black;
  stroke-width: 20px;
}

Style guidelines

For comprehensive guidance on styling the <permission> element, including best practices and restrictions, refer to the <permission> styling guidelines. This resource provides detailed instructions to help you effectively style the element within your applications.

Expanded platform and capability support

The <permission> element now supports additional platforms and capabilities:

• Android support: The element is now functional on Android devices, broadening its applicability across different user platforms.
• Geolocation support: You can now request type="geolocation" permissions using the <permission> element with an additional preciselocation boolean attribute. While the preciselocation attribute affects only the prompt's wording, we're actively working on differentiating between coarse and precise location permissions in future updates.

Conclusions

These enhancements to the <permission> element are part of our ongoing efforts to streamline permission requests and improve user experience on the web. We encourage you to experiment with these new features and provide feedback to help us refine and evolve this capability.