Re: [w3c/pointerlock] Remove redundant user activation text from PointerLock spec. (PR #76)

@domenic approved this pull request.

LGTM with nits. An algorithm with steps would of course be nicer, but this is a definite improvement :)

> -              Conversely, if pointer lock is exited via {{exitPointerLock()}}
-              no <a>engagement gesture</a> is required to reenter pointer lock.
-              This enables applications that frequently move between
-              interaction modes, and ones that may do so based on a timer or
-              remote network activity.
-            </p>
-            <p data-link-for="Element">
-              Pointer lock is commonly combined with fullscreen [[FULLSCREEN]],
-              and if an <a>engagement gesture</a> is used to enter fullscreen
-              it is sufficient for a subsequent {{requestPointerLock()}}.
-            </p>
+          <aside class="note">
+            When a single <a>user activation</a> initiates both pointer lock and
+            fullscreen [[FULLSCREEN]], the {{requestPointerLock()}} call
+            succeeds only when it is made before a fullscreen request because
+            fullscreen is a <a>transient activation-consuming api</a>.

```suggestion
            fullscreen is a <a>transient activation-consuming API</a>.
```

>              <a>shadow-including root</a> is the <a>active document</a> of a
             [=Document/browsing context=] which is (or has an <a>ancestor
             browsing context</a> which is) in focus by a window which is in
             focus by the operating system's window manager. The <a>target</a>
             element and its [=Document/browsing context=] need not be in focus.
           </p>
           <p>
-            If a user has exited pointer lock via the <a>default unlock
-            gesture</a>, or pointer lock has not previously been entered for
-            this document, an event generated as a result of an <a>engagement
-            gesture</a> must be received by the document before
-            {{requestPointerLock()}} will succeed.
+            Pointer lock is a <a>transient activation-gated API</a>, therefore a
+            {{requestPointerLock()}} call MUST fail if <a>transient
+            activation</a> is not available.  This prevents locking upon initial

Maybe be more specific, i.e. say that it must fail if this's relevant global object does not have transient activation?

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