Cull excessive tags.

Author: NickFitz

index.html

@@ -5539,26 +5539,10 @@ <h5>Conclusion</h5>
 <ul data-ucr-role="conclusion-notes">
 <!-- bullet-point notes summarizing implementation details / blocking issues.
 Add tags to the start of a point with an empty `<a data-ucr-role="tag"></a>` where the text content or href matches a tag `id` value. -->
-<li><a data-ucr-role="tag">privacy-fingerprinting</a>
-As scripts may be loaded from arbitrary origins (depending on cross-origin restrictions),
-an event object including information about a map might allow deductions to be made about a viewer's device.
-For example, the bounds of a map in a responsive design could vary depending on the device on which it is viewed,
-allowing a third-party script to determine that a user is on a handheld device such as a phone.
-</li>
-<li><a data-ucr-role="tag" href="">security-ui</a>
-Use of the event system's <code>stopPropagation()</code> and <code>preventDefault()</code> methods
-could allow a third-party script to prevent a user from viewing particular areas, or more generally
-interfere with correct operation of the map's UI.
-</li>
 <li><a data-ucr-role="tag" href="">privacy-sensitive-data-revealed</a>
 Collating the positions on which a user centres the map could allow a script to infer an interest
 in a particular region and, for example, target advertising accordingly.
 </li>
-<li><a data-ucr-role="tag" href="">security-potential</a>
-By appropriately restricting scripted access to event properties, a built-in browser map implementation
-could prevent leakage to cross-origin scripts of the kind of information outlined in the above points,
-in a way not achievable by existing implementations.
-</li>
 <li><a data-ucr-role="tag" href="">accessibility-potential</a>
 If events from maps and map interface elements are exposed to assistive technologies via the browser's
 existing accessibility mechanisms, it would be easier for those technologies to present them in a way
@@ -5569,14 +5553,11 @@ <h5>Conclusion</h5>
 in order to provide such data in enhanced event objects.
 Native implementations could be expected to provide significantly better performance.
 </li>
-<li><a data-ucr-role="tag" href="">author-simplicity</a>
-Consistency of the event interface with other HTML elements would simplify coding.
-</li>
 <li><a data-ucr-role="tag" href="">author-extensibility</a>
-The abilty to respond to user interaction is crucial in building rich application interfaces that include embedded maps.
+The ability to respond to user interaction is crucial in building rich application interfaces that include embedded maps.
 </li>
 <li><a data-ucr-role="tag" href="">author-cost-cutting</a>
-A standard interface against which to write event-driven mapping applications reduces the amount of time developers
+A standardised interface against which to write event-driven mapping applications reduces the amount of time developers
 need to spend becoming competent and productive.
 </li>
 <li><a data-ucr-role="tag" href="">consistency-match</a>