Skip to content

Commit

Permalink
Fix stale text around click, auxclick and contextmenu events (#456)
Browse files Browse the repository at this point in the history 
* Fix old text treating click, auxclick and contextmenu as MouseEvents

* Small language tweaks

Co-authored-by: Patrick H. Lauke <[email protected]>
  • Loading branch information
@mustaqahmed @patrickhlauke
mustaqahmed and patrickhlauke authored Sep 11, 2022
1 parent 47b8524 commit f035350
Showing 1 changed file with 11 additions and 11 deletions.
22 changes: 11 additions & 11 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -647,8 +647,9 @@ <h3>The <dfn data-dfn-for="GlobalEventHandlers" data-dfn-type="event">lostpointe
<h3>The <dfn><code>click</code>, <code>auxclick</code>, and <code>contextmenu</code> events</dfn></h3>
<p>This section is an addition to <a data-cite="uievents/#event-type-click">click</a>,
<a data-cite="uievents/#event-type-auxclick">auxclick</a> and <a data-cite="uievents/#event-type-contextmenu">contextmenu</a>
events defined in [[UIEVENTS]]. The type of these events MUST be <code>PointerEvent</code>,
but the dispatch process is going to match that of the original specification.</p>
events defined in [[UIEVENTS]]. The type of these events MUST be <code>PointerEvent</code>, but the dispatch process is going
to match that of the original specification. These events are typically tied to user interface activation, and are fired even
from non-pointer input devices, such as keyboards.</p>
<p>For these events, all <code>PointerEvent</code> specific attributes (defined in this spec) other than <code>pointerId</code> and <code>pointerType</code> will have their default values. In addition:</p>
<ul>
<li>If the events are generated by a pointing device, their <code>pointerId</code> and <code>pointerType</code> MUST be the same as the PointerEvents that caused these events.</li>
Expand Down Expand Up @@ -946,10 +947,10 @@ <h3><dfn data-lt="implicitly release the pointer capture|implicitly releasing po
After running <a>process pending pointer capture</a> steps,
if the pointer supports hover, user agent MUST also send corresponding boundary events necessary
to reflect the current position of the pointer with no capture.</p>
<p>If the user agent supports firing the <code>click</code> event
(see <a>compatibility mouse events</a>),
and if in an implicit release scenario both <code>click</code> and {{GlobalEventHandlers/lostpointercapture}} events are fired,
<code>click</code> SHOULD be fired before {{GlobalEventHandlers/lostpointercapture}}.</p>
<p>If the user agent supports firing the <code>click</code> or <code>auxclick</code> event,
and if in an implicit release scenario both that (<code>click</code> or <code>auxclick</code>)
event and a {{GlobalEventHandlers/lostpointercapture}} event are fired,
the <code>click</code> or <code>auxclick</code> event SHOULD be fired before {{GlobalEventHandlers/lostpointercapture}}.</p>
<p>When the <a>pointer capture target override</a> is no longer [=connected=] [[DOM]],
the <a>pending pointer capture target override</a> and <a>pointer capture target override</a> nodes SHOULD be cleared
and also a PointerEvent named {{GlobalEventHandlers/lostpointercapture}} corresponding to the captured pointer SHOULD be fired at the document.</p>
Expand Down Expand Up @@ -1180,12 +1181,11 @@ <h2>Populating and maintaining the coalesced and predicted events lists</h2>
<section>
<h1><dfn data-lt="compatibility mouse events">Compatibility mapping with mouse events</dfn></h1>
<p>The vast majority of web content existing today codes only to Mouse Events. The following describes an algorithm for how the user agent MAY map generic pointer input to mouse events for compatibility with this content.</p>
<p>The compatibility mapping with mouse events is an OPTIONAL feature of this specification. User agents are encouraged to support the feature for best compatibility with existing legacy content. User agents that do not support compatibility mouse events are still encouraged to support the <code>click</code> and <code>contextmenu</code> events (see the note below).</p>
<p>The <code>click</code> and <code>contextmenu</code> events, defined in [[UIEVENTS]], are not considered <a>compatibility mouse events</a> as they are typically tied to user interface activation, and are fired from other (non-pointer) input devices, such as keyboards.</p>
<p>The compatibility mapping with mouse events is an OPTIONAL feature of this specification. User agents are encouraged to support the feature for best compatibility with existing legacy content.</p>
<p>Regardless of their support for compatibility mouse events, the user agents MUST always support the <a data-lt="click, auxclick and contextmenu events"><code>click</code>, <code>auxclick</code> and <code>contextmenu</code> events</a> because these events are of type <code>PointerEvent</code> and are therefore not <a>compatibility mouse events</a>. Calling <code>preventDefault</code> during a pointer event MUST NOT have an effect on whether <code>click</code>, <code>auxclick</code>, or <code>contextmenu</code> are fired or not.</p>
<div class="note">
<p>In user agents that support firing <code>click</code> and/or <code>contextmenu</code>, calling <code>preventDefault</code> during a pointer event typically does not have an effect on whether <code>click</code> and/or <code>contextmenu</code> are fired or not. Because they are not compatibility mouse events, user agents typically fire <code>click</code> and <code>contextmenu</code> for all pointing devices, including pointers that are not primary pointers.</p>
<p>The relative ordering of these high-level events (<code>click</code>, <code>contextmenu</code>, <code>focus</code>, <code>blur</code>, etc.) with pointer events is undefined and varies between user agents. For example, in some user agents <code>contextmenu</code> will often follow a {{GlobalEventHandlers/pointerup}}, in others it'll often precede a {{GlobalEventHandlers/pointerup}} or {{GlobalEventHandlers/pointercancel}}, and in some situations it may be fired without any corresponding pointer event (such as a keyboard shortcut).</p>
<p>In addition, user agents may apply their own heuristics to determine whether or not a <code>click</code> or <code>contextmenu</code> event should be fired. Some user agents may only fire these events for a primary pointer, and even then they may choose not to fire these events if there are other (non-primary) pointers of the same type, or other primary pointers of a different type. User agents may determine that a particular action was not a "clean" tap, click or long-press — for instance, if an interaction with a finger on a touch screen includes too much movement while the finger is in contact with the screen — and decide not to fire a <code>click</code> or <code>contextmenu</code> event. These aspects of user agent behavior are not defined in this specification, and they may differ between implementations.</p>
<p>The relative order of some of these high-level events (<code>contextmenu</code>, <code>focus</code>, <code>blur</code>, etc.) with pointer events is undefined and varies between user agents. For example, in some user agents <code>contextmenu</code> will often follow a {{GlobalEventHandlers/pointerup}}, while in others it'll often precede a {{GlobalEventHandlers/pointerup}} or {{GlobalEventHandlers/pointercancel}}, and in some situations it may be fired without any corresponding pointer event (for instance, as a result of a keyboard interaction).</p>
<p>In addition, user agents may apply their own heuristics to determine whether or not a <code>click</code>, <code>auxclick</code>, or <code>contextmenu</code> event should be fired. Some user agents may choose not to fire these events if there are other (non-primary) pointers of the same type, or other primary pointers of a different type. User agents may determine that a particular action was not a "clean" tap, click, or long-press (for instance, if an interaction with a finger on a touch screen includes too much movement while the finger is in contact with the screen) and decide not to fire a <code>click</code>, <code>auxclick</code>, or <code>contextmenu</code> event. These aspects of user agent behavior are not defined in this specification, and they may differ between implementations.</p>
</div>
<p>Unless otherwise noted, the target of any mapped mouse event SHOULD be the same target as the respective pointer event unless the target is no longer participating in its <code>ownerDocument</code>'s tree. In this case, the mouse event should be fired at the original target's nearest ancestor node (at the time it was removed from the tree) that still participates in its <code>ownerDocument</code>'s tree, meaning that a new event path (based on the new target node) is built for the mouse event.</p>
<p>Authors can prevent the production of certain compatibility mouse events by canceling the {{GlobalEventHandlers/pointerdown}} event.</p>
Expand Down

0 comments on commit f035350

Please sign in to comment.