Apply (easy) suggestions from code review

Co-authored-by: Chris Mills <chrisdavidmills@gmail.com>

Author: hamishwillee

files/en-us/web/api/permissionspolicyviolationreport/index.md

@@ -11,7 +11,7 @@ browser-compat: api.ReportingObserver.ReportingObserver.options_parameter.types_
 
 The `PermissionsPolicyViolationReport` dictionary of the [Reporting API](/en-US/docs/Web/API/Reporting_API) represents a report that is generated when a document violates its [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy).
 
-Reports of this type can be observed from within a page using a {{domxref("ReportingObserver")}}, and a serialized version can be sent to a reporting endpoint server.
+Reports of this type can be observed from within a page using a {{domxref("ReportingObserver")}}, and a serialized version can be sent to a reporting server endpoint.
 
 ## Instance properties
 
@@ -52,7 +52,7 @@ Violations of the policy may also be reported but not enforced using the {{httph
 You can monitor for Permissions-Policy violation reports within the page that sets the policy using the [Reporting API](/en-US/docs/Web/API/Reporting_API).
 To do this you create a {{domxref("ReportingObserver")}} object to listen for reports, passing a callback method and an (optional) `options` property specifying the types of reports that you want to report on.
 The callback method is then called with reports of the requested types, passing a report object.
-For `Permissions-Policy` or `Permissions-Policy-Report-Only` violations, the object will be a `PermissionsPolicyViolationReport` instance with `PermissionsPolicyViolationReport.type == "permissions-policy-violation"`.
+For `Permissions-Policy` or `Permissions-Policy-Report-Only` violations, the object will be a `PermissionsPolicyViolationReport` instance with `PermissionsPolicyViolationReport.type === "permissions-policy-violation"`.
 
 The structure of a typical in-page report is shown below.
 Note that we can see the URL of the page that had its policy violated (`url`), and from `body.featureId` we can see which feature was blocked.
@@ -167,7 +167,7 @@ Note that the `type` is `"permissions-policy-violation"` and `body.featureId` id
 This example shows how to configure reporting of `Permissions-Policy` violations to a server endpoint.
 
 The response headers below block geolocation and define the reporting endpoint name for the feature as "geo_endpoint".
-The {{HTTPHeader("Reporting-Endpoints")}} HTTP response header is used to define URL of this endpoint name.
+The {{HTTPHeader("Reporting-Endpoints")}} HTTP response header is used to define the URL of this endpoint name.
 
 ```http
 Reporting-Endpoints: geo_endpoint="https://example.com/reports"

files/en-us/web/api/reporting_api/index.md

@@ -31,7 +31,7 @@ There are several different features and problems on the web platform that gener
 
 The purpose of the Reporting API is to provide a consistent reporting mechanism that can be used to make such information available to developers in the form of reports represented by JavaScript objects.
 
-Reports can be obtained within a page using JavaScript via reporting observers, or can be sent to a remote server endpoint.
+Reports can be retrieved via JavaScript reporting observers or sent to a remote server endpoint.
 The types of reports and the two reporting approaches are detailed in the sections below.
 
 ### Report types
@@ -43,12 +43,12 @@ The type of report can be determined from its `type` property, which for the rep
 Reports sent to reporting endpoints and reporting observers are essentially the same.
 The only difference is that server reports are JSON serializations of the objects that have additional `user_agent` and `age` fields.
 
-A list of documented report types and their corresponding report dictionary are given in the [`options.types`](/en-US/docs/Web/API/ReportingObserver/ReportingObserver#types) parameter passed to the `ReportingObserver()` constructor.
+A list of documented report types and their corresponding report dictionaries is given in the [`options.types`](/en-US/docs/Web/API/ReportingObserver/ReportingObserver#types) parameter passed to the `ReportingObserver()` constructor.
 
 ### Reporting observers
 
 Reports can be obtained via {{domxref("ReportingObserver")}} objects created via JavaScript inside the website you are aiming to get reports on.
-This method is not as failsafe as sending reports to the server because any page crash could stop you retrieving the reports — but it is easier to set up, and more flexible.
+This method is not as failsafe as sending reports to the server because any page crash could stop you from retrieving the reports; it is, however, easier to set up, and more flexible.
 
 A `ReportingObserver` object is created using the {{domxref("ReportingObserver.ReportingObserver", "ReportingObserver()")}} constructor, which is passed two parameters:
 
@@ -69,10 +69,10 @@ Reports sent to endpoints can be retrieved independently of the running of the w
 > There is no absolute guarantee of report delivery — a report could still fail to be collected if a serious error occurs.
 
 The {{httpheader("Reporting-Endpoints")}} HTTP header is used to specify the name and URL for different endpoints that a user-agent has available to it for delivering reports.
-The endpoints can then be used on particular HTTP response headers to indicate the specific endpoint (or in some cases endpoints) that will be used for the associated report.
+The endpoints can then be specified within particular HTTP response headers to indicate the endpoint (or in some cases, endpoints) that associated reports will be delivered to.
 Report types that don't have an associated HTTP header, such as `crash`, `deprecation`, and `intervention` reports, will usually send reports to the [`"default"` reporting endpoint](/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints#default_reporting_endpoint) (this is just an endpoint named "default" specified using the `Reporting-Endpoints` header).
 
-The mechanism to specify server endpoint for each report is listed below.
+The mechanism to specify server endpoints for each report is listed below.
 
 - `coep`
   - `report-to` parameter on {{HTTPHeader("Cross-Origin-Embedder-Policy")}} or {{HTTPHeader("Cross-Origin-Embedder-Policy-Report-Only")}}

files/en-us/web/http/reference/headers/permissions-policy-report-only/index.md

@@ -12,12 +12,12 @@ sidebar: http
 {{SeeCompatTable}}
 
 The HTTP **`Permissions-Policy-Report-Only`** {{Glossary("response header")}} provides a mechanism for website administrators to report on violations of a {{HTTPHeader("Permissions-Policy")}} without enforcing them.
-This allows testing and fixing of a [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy) issues before a policy is deployed.
+This allows testing and fixing of [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy) issues before a policy is deployed.
 
 The syntax and behavior is exactly the same as for `Permissions-Policy` except:
 
 - The policy is not enforced.
-- Policy violation report objects ({{domxref("PermissionsPolicyViolationReport")}}) have the value `body.disposition="report"` (instead of `"enforce"`).
+- Policy violation report objects ({{domxref("PermissionsPolicyViolationReport")}}) have a `body.disposition` value of `"report"` instead of `"enforce"`.
 
 See {{HTTPHeader("Permissions-Policy")}} for more information (most of its content has not been duplicated below).
 
@@ -55,7 +55,7 @@ Reporting-Endpoints: geo_endpoint="https://example.com/reports"
 Permissions-Policy-Report-Only: geolocation=();report-to=geo_endpoint
 ```
 
-By specifying `geolocation=()` for the origin list, it is violation to access geolocation for all browsing contexts (this includes all `<iframe>`s), regardless of their origin.
+By specifying `geolocation=()` for the origin list, it is a violation for any browsing context to access geolocation (this includes `<iframe>`s), regardless of origin.
 The `report-to` parameter indicates that reports will be sent to the endpoint named `geo_endpoint`.
 The mapping between `geo_endpoint` and the URL where reports are to be sent is provided in `Reporting-Endpoints`.
 
@@ -68,7 +68,7 @@ navigator.geolocation.getCurrentPosition(
 );
 ```
 
-The [report payload](/en-US/docs/Web/API/Reporting_API#reporting_server_endpoints) sent to the endpoint might look like the JSON below.
+The [report payload](/en-US/docs/Web/API/Reporting_API#reporting_server_endpoints) sent to the endpoint will have the same structure as the JSON sample shown below.
 This is the same as a report for `Permissions-Policy` except for the value of `body.disposition`.
 
 ```json
@@ -77,7 +77,7 @@ This is the same as a report for `Permissions-Policy` except for the value of `b
     "age": 48512,
     "body": {
       "columnNumber": 29,
-      "disposition": "report", // A violation that is reported and not enforced
+      "disposition": "report", // A violation that is reported but not enforced
       "lineNumber": 44,
       "message": "Permissions policy violation: geolocation access has been blocked because of a permissions policy applied to the current document.",
       "featureId": "geolocation",

files/en-us/web/http/reference/headers/permissions-policy/index.md

@@ -42,7 +42,7 @@ Permissions-Policy: <directive>=<allowlist>;report-to=<endpoint>
 Permissions-Policy: <directive>=<allowlist>, <directive>=<allowlist>;report-to=<endpoint>, ...
 ```
 
-The header can be used to set the allowlists for one or more directives, and optionally a per-directive `report-to` parameter indicating the server endpoint for reporting violations of the policy.
+The header can be used to set the allowlists for one or more directives, and optionally a per-directive `report-to` parameter indicating the server endpoint to send policy violation reports to.
 The entries for each directive are comma separated.
 
 - `<directive>`