做过摄像头、麦克风或者定位功能的前端，应该都经历过一种熟悉的痛苦：明明只是想向用户要个权限，最后却写了一大堆 JavaScript。
以前网页想访问摄像头、麦克风或者地理位置，整个授权流程基本都得靠 JS 自己处理。你得调用权限 API，写异步逻辑，处理用户同意、拒绝以及各种异常，还得一直监听权限状态有没有变化。功能本身可能没几行，围绕“权限”写出来的样板代码却越来越多。更麻烦的是，这件事不仅开发体验不好，用户体验也一直很别扭。
很多网站最经典的做法是什么？用户刚打开页面，啪，一个权限弹窗直接糊到脸上：“是否允许此网站使用您的摄像头？”用户甚至还没搞明白你的网站是干什么的，第一反应往往就是拒绝。
然后真正麻烦的事情才开始。一旦权限被阻止，浏览器后面可能不会再按照原来的方式弹出授权提示。等用户真正想用视频、定位或者语音功能时，你只能告诉他：“请打开浏览器设置，然后找到网站权限，再找到摄像头……”普通用户看到这里基本已经开始迷路了。最后的结果通常不是用户成功打开权限，而是：“算了，这功能不用了。”
但现在，这件事可能终于要简单一些了。WICG 带来了一个实验性的新 HTML 标签：<permission>。按照目前的方案，它从 Chrome 144 开始获得支持。以后申请设备权限这件事，有机会直接通过一个 HTML 标签完成，不是再写几十行 JS 去控制整个授权流程，而是——声明一个标签，就这么简单。
一个 HTML 标签，把权限交互接管了
在 <permission> 出现以前，如果想实现类似效果，很多东西都需要自己封装，比如自定义一个 Permission Element：
classPermissionElementextendsHTMLElement{
constructor() {
// super must be called first
super();
// You can add custom logic here
// For example, setting the element's inner HTML structure or binding event listeners
this.innerHTML = '<p>This is a custom Permission element</p>';
}
}
// Define the new element
window.customElements.define('permission', PermissionElement);
但问题是：这只是第一步。真正做权限申请时，后面还得继续处理浏览器 API、状态变化、用户拒绝、异常情况以及 更新 UI。
而 <permission> 想解决的，恰恰就是这些重复工作。以前是：“我要写一套逻辑，告诉浏览器怎么申请权限。”现在变成：“我要摄像头权限。”然后让浏览器自己处理剩下的事情。这种变化看起来不大，但对于前端来说，开发体验完全不是一回事。
这个标签真正爽在哪里？
1. 一行 HTML，替掉一堆 JS
最明显的变化就是：声明式。过去你得主动调用浏览器权限相关 API，再围绕调用结果写各种处理逻辑。现在只需要声明：
<permissiontype="camera"></permission>
浏览器就知道：这个位置需要请求摄像头权限。从“写流程”变成“描述需求”，这其实也是 HTML 最擅长的事情。
2. 浏览器自己渲染授权控件
以前授权按钮长什么样、显示什么文字、不同权限状态下怎么变化，往往都得自己处理。<permission> 则可以让浏览器生成原生授权控件，而且它会根据当前权限状态自动调整显示内容。没授权是一种状态，已经授权是另一种状态，被拒绝又会进入另外一种状态。也就是说，很多原本需要前端自己维护的 UI 状态，现在可以直接交给浏览器。
3. 最重要的变化：不再上来就吓用户
这一点我觉得比“少写几十行代码”更重要。新的交互方式强调：只有用户主动点击授权按钮以后，权限弹窗才出现。这其实更符合正常人的使用逻辑。
比如一个在线视频会议网站，用户刚进首页时，你根本没必要立刻问“允许摄像头吗？允许麦克风吗？”他可能只是想看看页面。真正合理的流程应该是：用户点击“加入视频会议”，看到需要摄像头和麦克风，主动点击授权，然后浏览器再弹出权限确认。授权发生在用户理解“为什么需要这个权限”之后，拒绝率自然也有机会下降。
而且，即使之前拒绝过权限，用户之后仍然可以通过对应控件再次尝试触发授权流程，而不用一上来就教用户钻进浏览器层层设置里找入口。
4. 事件系统也准备好了
当然，真实业务不可能只做到“拿到权限，结束”。你肯定还需要知道用户到底做了什么：授权成功以后可能要启动摄像头；拒绝以后可能要展示提示；用户直接关掉弹窗，也可能需要更新页面状态。所以 <permission> 同样提供了对应的事件回调。授权、拒绝、关闭弹窗，都可以继续接自己的业务逻辑。
这意味着它并不是把 JavaScript 完全赶走，而是把最麻烦、最通用的权限交互交给浏览器，JS 只需要继续处理真正属于业务的部分。
实战：基本可以直接抄
先来看最简单的。
▸ 请求单个权限
只需要在 type 中写清楚你想申请什么权限。
申请摄像头：
<!-- Request camera permission -->
<permissiontype="camera"></permission>
申请麦克风：
<!-- Request microphone permission -->
<permissiontype="microphone"></permission>
获取高精度地理位置：
<!-- Get high-precision geolocation -->
<permission
type="geolocation"
preciseLocation="true">
</permission>
没有一大堆异步调用，也没有先写按钮再手动绑定权限请求。HTML 本身就在表达这个元素的用途。
▸ 一次申请多个权限
比如做视频通话，通常摄像头和麦克风是一起要的。以前你可能需要分别处理两套权限状态，现在只需要把权限类型用空格隔开：
<permissiontype="camera microphone"></permission>
一个元素，同时处理 Camera + Microphone。对于在线会议、视频客服、网页录制这类产品，这种写法确实省事很多。
▸ 配合 JS 监听授权状态
当然，真正开发产品时，我们肯定还是需要 JavaScript。区别只是：JS 不再负责从头造一套权限系统，而是负责监听结果。比如：
<permissionid="perm-camera"type="camera"></permission>
<pid="status"></p>
<script>
const permEl = document.getElementById('perm-camera');
const statusEl = document.getElementById('status');
// User grants permission
permEl.addEventListener('grant', () => {
statusEl.textContent = '✅ Camera permission enabled successfully';
});
// User denies permission
permEl.addEventListener('deny', () => {
statusEl.textContent = '❌ Camera permission has been denied';
});
// User directly closes the popup
permEl.addEventListener('promptdismiss', () => {
statusEl.textContent = 'ℹ️ Permission popup closed';
});
</script>
这里分别监听了三个事件：
grant：用户成功授权。deny：用户拒绝授权。promptdismiss：用户没有明确选择允许或拒绝，而是直接关闭了权限弹窗。
这样页面就可以根据用户操作实时更新状态。例如授权成功后启动视频预览；拒绝后告诉用户为什么这个功能需要摄像头；关闭弹窗以后，则暂时保持当前页面，不继续打扰。整个逻辑会清晰很多。
核心属性其实不多
目前真正需要重点关注的属性主要有几个。
type
必填，用来指定申请什么权限。目前包括：
camera、microphone、geolocation
如果需要一次申请多个权限，就使用空格隔开，例如：
<permissiontype="camera microphone"></permission>
preciseLocation
可选，主要配合 geolocation 使用，用于开启高精度位置获取。例如：
<permission
type="geolocation"
preciseLocation="true">
</permission>
isValid
这是一个只读属性。可以用它判断当前 <permission> 元素是否满足触发授权的条件。换句话说，在真正执行权限相关操作之前，可以先确认当前元素是不是处于有效状态。
先别急着扔进生产环境
看到这里，可能已经有人准备：
git add .、git commit、git push
先等等。现在还不是直接裸奔上生产的时候。因为 <permission> 目前仍然处于实验性草案阶段，当前支持范围也有限，文中方案针对的是 Chrome 144+。
所以更稳妥的做法应该是：渐进增强。支持 <permission> 的浏览器，就直接使用新的原生方式；不支持的浏览器，继续展示传统按钮，再走原来的 JavaScript 权限申请流程。
例如：
<permissionid="geo-perm"type="geolocation"></permission>
<buttonid="geo-fallback"style="display:none;">
Get Location
</button>
<script>
// Detect whether the browser supports the permission tag
if (!window.customElements.get('permission')) {
document.getElementById('geo-perm').style.display = 'none';
document.getElementById('geo-fallback').style.display = 'inline-block';
// Traditional JS permission-fetching logic can be written here
}
</script>
思路很简单：先检测浏览器支不支持；支持就直接显示 <permission>；不支持就隐藏新元素，把传统的“获取位置”按钮显示出来，然后继续走原来的 JS 实现。
这样至少不会出现很尴尬的情况：开发者自己用最新版 Chrome 测试，哇，完美！一上线，用户打开 Safari：这是什么？实验性 Web API 最重要的一条原则一直没变：新功能可以用，但老路最好先留着。
为什么我觉得它比“少写代码”更重要？
如果只从代码量来看，<permission> 好像只是又一个帮前端减少 Boilerplate 的 HTML 标签。但我觉得真正值得关注的其实是：权限申请正在从“开发者主动触发”，变成“用户主动发起”。
以前的思路是：页面加载，JavaScript 判断需要权限，立即弹窗，用户决定给不给。这套逻辑的问题在于，开发者知道为什么需要权限，但用户不知道。于是用户刚进网站，什么都没看明白，浏览器已经开始问“给不给摄像头？”站在用户角度，最安全的选择当然是不给。
而 <permission> 这种设计把顺序反过来了：先告诉用户这里有一个需要摄像头、麦克风或者定位的功能；用户决定使用；主动点击；然后浏览器才询问授权。先建立意图，再申请权限，这个顺序其实合理得多。
前端正在越来越“声明式”
再往大一点看，这个标签还有一个挺有意思的趋势。过去很多浏览器能力最终都会落到 JavaScript，于是前端代码很容易变成：查询状态、判断条件、调用 API、监听变化、更新 UI、处理异常、恢复状态。业务逻辑没写多少，控制流程先写了一大堆。
而 Web 平台这些年的一个明显方向，就是不断把一些通用能力重新收回到浏览器原生层。开发者只需要告诉浏览器“我要什么”，至于具体怎么实现，则尽可能交给浏览器。<permission> 本质上也是这种思路。不是“请执行下面 30 行代码帮我申请摄像头”，而是：
<permissiontype="camera"></permission>
“这里需要摄像头权限。”至于按钮怎么表现、当前权限是什么状态、什么时候应该弹窗，让浏览器参与处理。对于开发者来说，代码更少；对于浏览器来说，交互更加统一；而对于用户来说，权限什么时候出现，也变得更容易理解。
最后
网页权限申请这件事，前端已经折腾很多年了。代码麻烦只是其中一部分，真正难受的，其实一直是授权体验。页面一打开就弹权限，用户条件反射地点拒绝；真正需要功能时才发现用不了；然后开发者又得写一大段教程：“点击浏览器右上角……”“进入网站设置……”“找到摄像头……”“改成允许……”很多普通用户看到第二步就已经放弃了。
而 <permission> 真正有价值的地方，就是试图把这件事情重新拉回到一个更自然的流程：用户想使用功能 → 主动点击 → 浏览器申请权限 → 页面根据结果继续执行。同时，原本散落在 JavaScript 里的大量权限样板代码，也有机会被一个声明式 HTML 标签替代。
当然，它现在还处于实验阶段，浏览器兼容性决定了短期内传统方案不会消失。所以现阶段最合理的姿势不是“终于可以把权限 JS 全删了”，而是“可以开始为下一套权限交互方式做准备了”。
等浏览器支持逐渐完善以后，网页定位、视频会议、语音输入、在线录制这些高度依赖设备权限的场景，开发体验很可能都会舒服不少。有时候前端真正让人兴奋的新功能，并不是什么全新的框架，而是某一天你突然发现：以前必须写几十行 JavaScript 的东西，现在 HTML 一行就够了。
发表于 1 小时前
|
查看: 5|
回复: 0
