Editorial: Fix some links and other Bikeshed warnings (#128)

* RFC2119 "may" -> "can" in several places
* Ignore a domintro var
* Fix links around permissions/permissions policy dfn/use

NOTE: Following this change there are still some RFC2119 warnings
but some of them MAY merit moving to a normative section.

index.bs

@@ -134,7 +134,7 @@ if (window.screen.isExtended) {
 ### Detect the presence of multiple screens ### {#usage-overview-screen-extended}
 <!-- ====================================================================== -->
 
-A principal question for supporting multi-screen experiences is whether the device has multiple screens that may be used when placing content. These screens may be built-in to the device (like a laptop display panel), attached to the device by wire (like a computer and monitor attached by an HDMI cable), connected to the device by other means (like Mac and iPad Sidecar functionality), or through display device virtualization. This is provided by the {{Screen/isExtended}} boolean, exposed to secure contexts without a permission prompt.
+A principal question for supporting multi-screen experiences is whether the device has multiple screens that can be used when placing content. These screens can be built-in to the device (like a laptop display panel), attached to the device by wire (like a computer and monitor attached by an HDMI cable), connected to the device by other means (like Mac and iPad Sidecar functionality), or through display device virtualization. This is provided by the {{Screen/isExtended}} boolean, exposed to secure contexts without a permission prompt.
 
 ```js
 if (screen.isExtended) {
@@ -294,7 +294,7 @@ A [=/screen=] has <dfn>pixels</dfn>, which are the smallest screen components th
 
 Note: On a liquid-crystal display (LCD), each pixel is made up of three components. Each component is a (red, green, blue) light with variable intensity. Reasoning about pixel components (subpixel rendering) is out of scope for this specification.
 
-Note: Some screens can be configured to display content at a resolution that differs from the physical hardware's inherent composition; e.g. a monitor with a hardware resolution of 2560×1440 may be configured by the device to operate with a display resolution of 1920×1080.
+Note: Some screens can be configured to display content at a resolution that differs from the physical hardware's inherent composition; e.g. a monitor with a hardware resolution of 2560×1440 can be configured by the device to operate with a display resolution of 1920×1080.
 
 A [=screen/pixel=] has a <dfn for="pixel">color depth</dfn>, which is the number of bits used to represent the colors it can display.
 
@@ -382,9 +382,9 @@ Each [=/screen=] may be designated as <dfn>internal</dfn> or <dfn>external</dfn>
 
 Note: As an example, a desktop computer might display its visual output on an [=/external=] screen connected by an HDMI cable. The HDMI cable can be connected or disconnected while the computer is in use, and the computer will adapt its visual environment to that hardware configuration change.
 
-[=/Internal=] screens are usually attached to a device at manufacturing time. [=/Internal=] screens are not intended to be detached by users. However an [=/internal=] [=/screen=] may still be enabled or disabled while the user agent is running.
+[=/Internal=] screens are usually attached to a device at manufacturing time. [=/Internal=] screens are not intended to be detached by users. However an [=/internal=] [=/screen=] can still be enabled or disabled while the user agent is running.
 
-Note: As an example, a laptop might disable its [=/internal=] screen and input device when the lid is closed. The laptop may still be used in this configuration with an [=/external=] screen and input device. The disabled [=/internal=] screen may not be reported as a [=/screen=] used by the device while the lid is closed.
+Note: As an example, a laptop might disable its [=/internal=] screen and input device when the lid is closed. The laptop can still be used in this configuration with an [=/external=] screen and input device. The disabled [=/internal=] screen can not be reported as a [=/screen=] used by the device while the lid is closed.
 
 <!-- ====================================================================== -->
 ## Current screen ## {#concept-current-screen}
@@ -454,7 +454,7 @@ Issue: Make {{Screen}} derive from {{EventTarget}} in [[CSSOM-VIEW-1#the-screen-
 
 The <dfn attribute for=Screen>isExtended</dfn> getter steps are:
 
-1. If [=this=]'s [=relevant global object=]'s [=associated Document=] is not [=allowed to use=] the [=policy-controlled feature=] named "[=permission-policy/window-management=]", return false and abort these steps.
+1. If [=this=]'s [=relevant global object=]'s [=associated Document=] is not [=allowed to use=] the [=policy-controlled feature=] named "{{PermissionPolicy/window-management}}", return false and abort these steps.
 
 1. Return true if the device has more than one [=/screen=], and false otherwise.
 
@@ -502,11 +502,11 @@ The <dfn method for=Window>getScreenDetails()</dfn> method steps are:
 
 1. Let |promise| be [=/a new promise=].
 
-1. If [=this=]'s [=relevant global object=]'s [=associated Document=] is not [=allowed to use=] the [=policy-controlled feature=] named "[=permission-policy/window-management=]", then [=/reject=] |promise| with a {{"NotAllowedError"}} {{DOMException}} and abort these steps.
+1. If [=this=]'s [=relevant global object=]'s [=associated Document=] is not [=allowed to use=] the [=policy-controlled feature=] named "{{PermissionPolicy/window-management}}", then [=/reject=] |promise| with a {{"NotAllowedError"}} {{DOMException}} and abort these steps.
 
 1. Run the following steps [=/in parallel=]:
 
-    1. Let |permissionState| be [=/request permission to use=] `"window-management"`.
+    1. Let |permissionState| be [=/request permission to use=] "{{window-management}}".
 
     1. [=/Queue a global task=] on the [=/relevant global object=] of [=/this=] using the [=/window placement task source=] to run the following steps:
 
@@ -708,7 +708,7 @@ When any [=screen/basic observable property=] or [=screen/advanced observable pr
 
 <div class="domintro note">
 
-    : |fullscreenOptions| . {{FullscreenOptions/screen}}
+    : <var ignore>fullscreenOptions</var> . {{FullscreenOptions/screen}}
     :: Specifies a [=/screen=] for element fullscreen requests.
 
 </div>
@@ -726,7 +726,7 @@ The optional {{FullscreenOptions}} <dfn dict-member for=FullscreenOptions>screen
 <!-- ====================================================================== -->
 
 The {{Element/requestFullscreen|Element.requestFullscreen()}} method steps are updated to optionally:
-1. Take `options`["{{FullscreenOptions/screen}}"] into account when moving and resizing  `pendingDoc`’s [=/top-level browsing context=]’s [=/active document=]’s viewport. The viewport may be moved to the specified [=/screen=] as part of this modified method step.
+1. Take `options`["{{FullscreenOptions/screen}}"] into account when moving and resizing  `pendingDoc`’s [=/top-level browsing context=]’s [=navigable/active document=]’s viewport. The viewport may be moved to the specified [=/screen=] as part of this modified method step.
 1. Set the [=/this=].{{Window/[[targetScreenFullscreen]]}} internal slot to the [=/current high resolution time=] if `options`["{{FullscreenOptions/screen}}"] specifies a recognized {{ScreenDetailed}} object with a value of true for {{Screen/isExtended}}.
 
 <!-- ====================================================================== -->
@@ -737,7 +737,7 @@ This specification defines a [=/default powerful feature=] that is identified by
 
 The [[permissions]] API provides a uniform way for websites to query the state of their permissions.
 
-Note: Previously published versions of this document used the permission name "<code>window-placement</code>". User agents should carefully migrate to the updated permission string: "{{window-management}}". See [#114](https://github.com/w3c/window-placement/issues/114).
+Note: Previously published versions of this document used the permission name `"window-placement"`. User agents should carefully migrate to the updated permission string: "{{window-management}}". See [#114](https://github.com/w3c/window-placement/issues/114).
 
 Issue: Add {{window-management}} to [[permissions]] registry.
 
@@ -747,11 +747,11 @@ Issue: Define behavior of cached objects and method steps when the permission is
 ## Permission Policy integration ## {#api-permission-policy-integration}
 <!-- ====================================================================== -->
 
-This specification defines a [=/policy-controlled feature=] identified by the string "<dfn for="policy-controlled feature"><code>window-management</code></dfn>", that controls whether {{Screen/isExtended}}, {{Window/getScreenDetails}}, and dependent functionality may be used. The [=/default allowlist=] for this feature is <code>["self"]</code>. See [[permissions-policy]] and its list of [Experimental Features](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md#experimental-features).
+This specification defines a [=/policy-controlled feature=] identified by the string <dfn for=PermissionPolicy enum-value>"window-management"</dfn>, that controls whether {{Screen/isExtended}}, {{Window/getScreenDetails}}, and dependent functionality may be used. The [=policy-controlled feature/default allowlist=] for this feature is `'self'`. See [[permissions-policy]] and its list of [Experimental Features](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md#experimental-features).
 
 Note: A [=/document=]’s permissions policy determines whether any content in that document is allowed to obtain a meaningful value from {{Screen/isExtended}}, access {{ScreenDetails}}, or place content on specific screens. If disabled, {{Screen/isExtended}} will return false, promises returned by {{Window/getScreenDetails}} will be rejected, and requests to place content on specific screens will be clamped to the [=/current screen=].
 
-Issue: Move [=permission-policy/window-management=] to [Proposed](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md#proposed-features) or [Standardized](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md#proposed-features) feature lists when appropriate.
+Issue: Move {{PermissionPolicy/window-management}} to [Proposed](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md#proposed-features) or [Standardized](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md#proposed-features) feature lists when appropriate.
 
 <!-- ====================================================================== -->
 # Security Considerations # {#security}
@@ -761,13 +761,13 @@ This specification enables sites to place content on specific screens, which may
 1. Sites may attempt to prominently display sensitive content on unexpected screens
 1. Sites may attempt to surreptitiously display undesirable content on less conspicuous screens, for example:
   1. Sites may attempt to spoof the OS, browser, or other sites for phishing attacks, by drawing the user's attention to a particular screen, and use interaction signals there to show deceptive content on another screen that is less closely observed
-1. Sites may attempt to otherwise place content on specific screens to act in deceptive, abusive, or annoying manners 
+1. Sites may attempt to otherwise place content on specific screens to act in deceptive, abusive, or annoying manners
 
 To help mitigate such risks, cross-screen placement capabilities require explicit user permission (where prompting is only possible with transient user activation), are restricted to secure contexts, and are subject to permission policy. If any of these requirements are not met, placement requests may be denied or clamped to the [=/current screen=], matching pre-existing behavior of some user agents. User agents can generally measure and otherwise intervene when sites request any new capabilities.
 
 To enable this new functionality in a nested browsing context, it needs to be specifically allowed via [[permissions-policy]], either through an appropriate declaration in the `allow` attribute of the HTML `iframe` element, or through a `Permissions-Policy` HTTP header delivered with the document through which it is nested. This prevents e.g. content from third parties to place content on specific screens without explicit permission.
 
-Other points to note: 
+Other points to note:
 - Some user agents already do not constrain window placement requests to the [=/current screen=]; they interpret {{Window/open()}} and {{Window/moveTo()}} coordinates as relative to the [=/multi-screen origin=], and honor requests to place windows on screens other than the [=/current screen=].
 - Transient user activation is typically already required for {{Element/requestFullscreen()}} and {{Window/open()}}, but not for {{Window/moveTo()}}, {{Window/moveBy()}}, {{Window/resizeTo()}}, nor {{Window/resizeBy()}}.
 - Placing content on a screen other than the [=/current screen=] is unlikely to create additional clickjacking risk for users, since the user's cursor or finger is likely to be co-located with the [=/current screen=], not on a separate screen.