[css-ui-4] Define 'pointer-events'

As resolved in #6685 (comment)

css-ui-4/Overview.bs

@@ -1793,6 +1793,69 @@ However, UAs supporting ''-webkit-user-select'' as an alias of 'user-select' thr
 without adverse consequences to compatibility,
 so this specification allows flexibility.
 
+<h3 id="pointer-events-control">Controlling Interactability</h3>
+
+Issue: While this property modifies the normal behavior of hit-testing,
+this normal <dfn>hit-testing</dfn> is currently not specified.
+There is broad interoperability about the seemingly obvious parts of this problem,
+but there are countless nuances and corner cases that would greatly benefit
+from a detailed specification.
+The CSS-WG would hugely appreciate
+help with writing such a specification.
+
+<pre class=propdef>
+Name: pointer-events
+Value: auto | none
+Initial: ''pointer-events/auto''
+Applies to: all elements
+Inherited: yes
+Percentages: N/A
+Computed value: specified keyword
+Canonical order: per grammar
+Animation type: by computed value type
+</pre>
+
+The 'pointer-events' property defines whether an element's boxes can be targeted point pointer events.
+Values have the following meanings:
+
+<dl dfn-for=pointer-events dfn-type=value>
+	<dt><dfn>auto</dfn>
+	<dd>
+		[=Hit-testing=] occurs normally.
+
+	<dt><dfn>none</dfn>
+	<dd>
+		[=Hit-testing=] acts as if the boxes generated by the element
+		(see [[CSS-DISPLAY-3]])
+		were not there,
+		effectively causing the element behind the ''pointer-events: none'' element
+		to become the target of [=hit-testing=] based events instead.
+
+		Issue: The statement above needs to be be qualified;
+		for some purposes,
+		hit-testing continues to take the element into account.
+		For instance, clicking and dragging to start a text selection will continue to work as usual.
+		What is the precise set of things for which hit-testing is affected by 'pointer-events'?
+
+</dl>
+
+''pointer-events: none'' does not inhibit [=sequential focus navigation=].
+
+Note: This ''pointer-events: none'' only excludes the element itself from [=hit-testing=],
+not the whole subtree.
+While this property propagates to descendants via inheritance,
+''pointer-events: auto'' can be specified on a descendant of a ''pointer-events: none'' element,
+and such an element will participate normally in [=hit-testing=].
+
+Note: Events that target a ''pointer-events: auto'' descendant of a ''pointer-events: none'' element
+can still be caught by event handlers on ''pointer-events: none'' ancestors
+of the targeted element during the bubbling or capturing phases
+(see [[DOM#events]]).
+
+Note: [[SVG2#PointerEventsProp]] defines a variant of this property for SVG elements,
+with more possible values.
+The effect of such values outside of SVG is currently not defined.
+
 <h2 id="styling-widgets" oldids="form-styling, control-styling">Styling Widgets</h2>
 
 <h3 id="widget-accent">Widget Accent Colors: the 'accent-color' property</h3>
@@ -2367,7 +2430,13 @@ This appendix is <em>informative</em>.
 <h3 id=changes-2021-03-16 class=no-num>Changes from the
 <a href="https://www.w3.org/TR/2021/WD-css-ui-4-20210316/">16 March 2021 Working Draft</a></h3>
 
-None yet.
+In addition to a number of editorial adjustments,
+the following normative changes have been made:
+
+<ul>
+	<li>
+		Introduce a definition for the 'pointer-events' property.
+</ul>
 
 <h3 id=changes-24-1-2020 class=no-num>Changes from the
 <a href="https://www.w3.org/TR/2020/WD-css-ui-4-20200124/">24 January 2020 Working Draft</a></h3>