Editorial: Align with Web IDL specification

Author: autokagami

index.bs

@@ -6,7 +6,7 @@ Status: ED
 Group: dap
 ED: https://w3c.github.io/sensors/
 TR: https://www.w3.org/TR/generic-sensor/
-Previous Version: https://www.w3.org/TR/2018/CR-generic-sensor-20180320/
+Previous Version: https://www.w3.org/TR/2019/WD-generic-sensor-20190307/
 Editor: Rick Waldron 50572, Bocoup, formerly on behalf of JS Foundation
 Former Editor: Mikhail Pozdnyakov 78325, Intel Corporation, https://intel.com/
 Former Editor: Alexander Shalamov 78335, Intel Corporation, https://intel.com/
@@ -27,6 +27,13 @@ Boilerplate: omit issues-index, omit conformance, omit feedback-header
 Ignored Vars: activated_sensors
 Inline GitHub Issues: yes
 Default Biblio Status: current
+Status Text:
+  Further implementation experience is being gathered for the
+  [=permission request algorithm=] and specification clarifications
+  informed by this experience are being discussed in
+  <a href="https://github.com/w3c/sensors/issues/397">GitHub issue #397</a>.
+  The group does not expect to advance this specification beyond CR until
+  [[PERMISSIONS-REQUEST]] moves beyond incubation.
 </pre>
 <pre class="anchors">
 urlPrefix: https://dom.spec.whatwg.org; spec: DOM
@@ -351,17 +358,6 @@ and defensive programming which includes:
 The judgement on how to communicate to the user the known [[#main-privacy-security-threats|threats]]
 is up to the implementer. The implementation of the [[#mitigation-strategies|mitigations]] is
 mandatory, however.
-
-The Generic Sensor API and its [=extension specifications=] are agnostic with respect to any user
-interface aspects. This specification defines an [[#request-sensor-access|integration point]] to the
-Permissions API [[PERMISSIONS]] that implementers can use for [=new information about the user's intent|
-explicit or implicit user consenting=]. In addition, implementers are encouraged to use additional
-privacy-enhancing mechanisms inline with their product requirements to provide a consistent and
-cohesive experience. Such mechanisms can include, for example, global and per-origin access controls,
-page info dialogs, location bar indicators, or other disclosure user interface elements.
-
-The Generic Sensor API provides flexibility to implementers to make user consenting and
-disclosure user interface design decisions on a concrete sensor basis as needed.
 </div>
 
 [=sensor readings|Sensor readings=] are sensitive data and could become a subject of
@@ -497,9 +493,6 @@ is "visible".
 <h4 id="permissions" oldids="permissioning">Permissions API</h4>
 
 Access to [=sensor readings=] are controlled by the Permissions API [[!PERMISSIONS]].
-User agents use a [=new information about the user's intent|number of criteria=]
-to grant access to the [=sensor readings|readings=].
-Note that access can be granted without prompting the user.
 
 <h3 id="mitigation-strategies-case-by-case">Mitigation strategies applied on a case by case basis</h3>
 
@@ -846,6 +839,8 @@ A [=sensor type=] has a [=permission revocation algorithm=].
             1.  Invoke [=revoke sensor permission=] with |sensor| as argument.
 </div>
 
+A [=sensor type=] has a [=permission request algorithm=].
+
 A [=sensor type=] has a [=set/is empty|nonempty=] [=ordered set|set=] of associated
 [=policy-controlled feature=] tokens referred to as <dfn export>sensor feature names</dfn>.
 
@@ -938,8 +933,8 @@ interface Sensor : EventTarget {
   readonly attribute boolean activated;
   readonly attribute boolean hasReading;
   readonly attribute DOMHighResTimeStamp? timestamp;
-  void start();
-  void stop();
+  undefined start();
+  undefined stop();
   attribute EventHandler onreading;
   attribute EventHandler onactivate;
   attribute EventHandler onerror;
@@ -2162,7 +2157,7 @@ The accelerometer feature is selectively enabled for third-party origin by addin
 A sensor usage is disabled completely by specifying the feature policy in a HTTP
 response header:
 <pre highlight="js">
- Feature-Policy: {"accelerometer": []}
+ Feature-Policy: accelerometer 'none'
 </pre>
 </div>
 
@@ -2184,9 +2179,9 @@ Here's an example WebIDL for a possible extension of this specification
 for proximity [=device sensor|sensors=].
 
 <pre class=example>
-    [Constructor(optional ProximitySensorOptions proximitySensorOptions = {}),
-     SecureContext, Exposed=Window]
+    [SecureContext, Exposed=Window]
     interface ProximitySensor : Sensor {
+        constructor(optional ProximitySensorOptions proximitySensorOptions = {});
         readonly attribute double? distance;
     };