Re: [w3c/permissions] Editorial: clean up Relationship to Permissions Policy (PR #351)

@miketaylr approved this pull request.



>        </p>
       <p>
         On the one hand, this specification exclusively concerns itself with [=powerful features=]
         whose access is managed through a user-agent mediated permissions UI (i.e., permissions
         where the user gives express consent before that feature can be used, and where the user
         retains the ability to deny that permission at any time for any reason). These powerful
-        features are explicitly identified by this specification's {{PermissionName}} enum.
+        features are registered in the [[[powerful-feature-registry]]].

I guess we're blocked on this reference meaning something.

>        </p>
       <p>
-        A powerful feature that has been disabled by the Permissions Policy specification always
-        has its permission state reflected as "denied" by this specification. This occurs because
-        reading the current permission state relies on [[HTML]]'s "[=allowed to use=]" check, which
-        itself calls into the Permissions Policy specification. Important to note here is the
-        sharing of permission names across both specifications. Where this specification has the
-        {{PermissionName}} enum, the Permissions Policy specification relies on other
-        specifications defining the names of the permissions (e.g., the permission "gamepad" is
-        defined in [[Gamepad]], and so on).
+        A powerful feature that has been disabled by the [[[Permissions-Policy]]] specification
+        always has its permission state reflected as "denied" by this specification. This occurs

```suggestion
        always has its [=permission state=] reflected as "denied" by this specification. This occurs
```

>        </p>
       <p>
-        A powerful feature that has been disabled by the Permissions Policy specification always
-        has its permission state reflected as "denied" by this specification. This occurs because
-        reading the current permission state relies on [[HTML]]'s "[=allowed to use=]" check, which
-        itself calls into the Permissions Policy specification. Important to note here is the
-        sharing of permission names across both specifications. Where this specification has the
-        {{PermissionName}} enum, the Permissions Policy specification relies on other
-        specifications defining the names of the permissions (e.g., the permission "gamepad" is
-        defined in [[Gamepad]], and so on).
+        A powerful feature that has been disabled by the [[[Permissions-Policy]]] specification
+        always has its permission state reflected as "denied" by this specification. This occurs
+        because reading the current permission state relies on [[HTML]]'s "[=allowed to use=]"

```suggestion
        because [=getting the current permission state|reading the current permission=] relies on [[HTML]]'s "[=allowed to use=]"
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/pull/351#pullrequestreview-873276161
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/permissions/pull/351/review/873276161@github.com>