本文介绍一个全新的HTML元素<permission>元素，与浏览器权限申请与使用相关，同时介绍Permissions API。
年纪上去了，精力有限，本文就不扯淡了，直接讲最核心的东西。
一、permission元素的作用
在Web开发的时候，我们会经常用到权限申请，比方说摄像头，访问相册，是否允许通知，又或者地理位置信息等。
在过去，这种申请都是通过JavaScript代码触发的，使用各种权限专门的API，或者使用统一的Permissions API。
但是，JavaScript触发的这种权限选择会有个问题，那就是如果用户不小心点击了拒绝怎么办？
这个其实还挺常见，或者有时候用户正好和女朋友吵架，心情不好，这个时候出现个提示，想都不想就拒绝，也是很有可能的，对吧。
此时，想要恢复权限，就很麻烦，需要去浏览器设置里面去处理。
这个对于那种非互联网重度用户而言，太难了。
于是，就有了<permission>元素。
权限按钮直接暴露在网页中，直接让用户点击就好了。
比方说下面的代码：
<permission type="camera" />
实时渲染效果如下（浏览器不支持会只有虚框）：
在我windows chrome浏览器下的渲染效果则是：
对应的HTML源码结构参见：
此时，用户点击此按钮，就会自动呼起权限选择的框框，例如：
此时，我们点击右上角的叉叉，不做任何选择，紧接着在点击此按钮，依然会出现提示。
这就避免了上面提到的用户权限选择拒绝后无法再次权限申请的问题。
眼见为实，您可以狠狠地点击这里：HTML permission元素不同类型展示效果demo
浏览器是否支持的检测
判断浏览器是否支持元素，可以使用下面展示的JS代码：
if ('HTMLPermissionElement' in window) {
// The `<permission>` 元素支持
}
二、Permissions API又是什么
在不过去，不同类型的权限申请回使用各自专门的API去进行，比方说地址位置的申请使用navigator.geolocation，摄像头权限申请使用navigator.getUserMedia()等。
这就会导致开始使用的学习和使用成本比较高。
既然都是权限申请，且系统出现的提示UI都近似，何必来个大统一呢？在这种背景下，Permissions API被提出来了。
所有的权限申请全都使用一个统一的API名称入口，使用的方法是Permissions.query()，直接看案例，地址位置权限申请。
navigator.permissions.query({ name: "geolocation" }).then((result) => {
if (result.state === "granted") {
showLocalNewsWithGeolocation();
} else if (result.state === "prompt") {
showButtonToEnableLocalNews();
}
// 如果权限没通过就不执行任何操作
});
下面列表显示了各类权限API预支对应的权限名称：
- Background Synchronization API:
background-sync(这个结果应该都是granted) - Clipboard_API:
clipboard-read,clipboard-write - Compute Pressure API:
compute-pressure - Geolocation API:
geolocation - Local Font Access API:
local-fonts - Media Capture and Streams API:
microphone,camera - Notifications API:
notifications - Payment Handler API:
payment-handler - Push API:
push - Screen Wake Lock API:
screen-wake-lock - Sensor APIs:
accelerometer,gyroscope,magnetometer,ambient-light-sensor - Storage Access API:
storage-access,top-level-storage-access - Storage API:
persistent-storage - Web Bluetooth API:
bluetooth - Web MIDI API:
midi - Window Management API:
window-management
不展开介绍。
三、两者结合使用？
既然都是与权限上面，那个HTML的这个和JS的这个是不是可以组合使用，没错，还真是，而且推荐这么处理。
下面是个案例，摄像头权限申请处理，看代码，先是HTML部分：
<permission type="camera" />然后接下来看看实操的JS代码：
// 获取permission元素 const permission = document.querySelector('permission'); // 绑定事件 permission.addEventListener('promptdismiss', showCameraWarning); function showCameraWarning() { // 显示摄像头会获取授权的提醒 } // 使用Permissions API申请权限 const permissionStatus = await navigator.permissions.query({name: "camera"}); // 权限状态变化的处理 permissionStatus.addEventListener('change', () => { // 如果权限允许，使用相机该干嘛就干嘛 if (permissionStatus.state === "granted") { useCamera(); } }); // 运行初始检查，如果用户之前已经通过，直接处理 if (permissionStatus.state === "granted") { useCamera(); }
大家平时开发的时候，就参照上面的案例处理就好了。
permission元素事件
上面代码出现的promptdismiss事件就是permission元素支持的事件类型之一。
具体有这么几个：
- onpromptdismiss
- 用户关闭权限提示的时候触发。使用
addEventListener绑定事件的时候，'on'需要省略，下同。在浏览器开启实验支持阶段，也可能使用的是ondismiss名称。 - onpromptaction
- 当用户对元素触发的权限提示执行某些操作来解除该提示时，系统会触发此事件。这并不一定意味着权限状态已更改，用户可能已执行某项操作来维持现状（例如继续允许使用某项权限）。在非正式阶段，事件名称为
onresolve。 - onvalidationstatuschange
- 当元素从
valid状态切换成invalid时触发。默认情况下都是valid状态，但是，如果当前的permission元素被其他元素遮挡，则被视为invalid。
PS：本来想测试下事件支持的名称，发现浏览器版本升级到最新之后，反而无法正常渲染permission元素了，怪哉，难道放弃支持了？
四、其他权限相关说明
目前Permissions API是可以放心使用的，浏览器支持有一段时日了，截图参考：
但是对于HTML <permission>元素，目前没有任何兼容性相关的数据，MDN上连个文档都没有，我怀疑，这个元素很有可能会中道崩殂。
另外 <permission>元素的样式是无法完全自定义的，毕竟与安全相关，仅有部分样式支持，综合上述，大家目前了解下即可。
好，就介绍这么多，希望可以对大家的工作与学习有所帮助。
也欢迎点赞，转发，一键……不好意思，说顺口，没有一键三连，转发就好了！
页面下部广告