diff --git a/dom.bs b/dom.bs index 99850bd42..dd796242f 100644 --- a/dom.bs +++ b/dom.bs @@ -102,6 +102,8 @@ urlPrefix: https://html.spec.whatwg.org/multipage/ text: effective script origin text: origin alias; url: #concept-origin-alias text: Unicode serialization of an origin + urlPrefix: infrastructure.html + text: in parallel urlPrefix: https://w3c.github.io/webcomponents/spec/shadow/ type: dfn; urlPrefix: #dfn- text: shadow root @@ -988,8 +990,9 @@ dictionary EventListenerOptions { invoked if event's {{Event/eventPhase}} attribute value is {{Event/AT_TARGET}}.
{{EventListenerOptions/passive}} -
When the passive member is set to true, it indicates that the listener's - callback will not cancel the event by invoking {{preventDefault()}}. +
When the passive member is set to true, it indicates that the listener + is passive + in that it's callback will not cancel the event by invoking {{preventDefault()}}. Invoking {{preventDefault()}} from within such a callback will have no effect.

Setting passive to true can enable the user agent to perform performance @@ -1135,21 +1138,21 @@ method must run these steps:

Observing event listeners

-In general, developers don't expect the presence of an event listener to be -observable. The impact of an event listener is determined by it's callback. -That is, a developer adding a no-op event listener would not expect it to have +In general, developers do not expect the presence of an event listener to be +observable. The impact of an event listener is determined by its callback. +That is, a developer adding a no-op event listener would not expect it to have any side effects. Unfortunately, some event APIs have been designed such that implementing them -efficiently requires observing event listeners. For example, sensor APIs which +efficiently requires observing event listeners. For example, sensor APIs which enable an underlying device sensor, and touch APIs which can be used to block -async scrolling. In some cases this problem can be mitigated by specifying +asynchronous scrolling. In some cases this problem can be mitigated by specifying the event to be {{Event/cancelable}} only when there is at least one -non-{{EventListenerOptions/passive}} listener. For example, non-passive +non-passive listener. For example, non-passive {{TouchEvent}} listeners must block scrolling, but if all listeners are passive then -scrolling can be allowed to start asynchronously by making the {{TouchEvent}} +scrolling can be allowed to start in parallel by making the {{TouchEvent}} uncancelable (so that calls to {{Event/preventDefault()}} are ignored). -New event types should be defined such that they don't need this +Ideally, any new event types are defined such that they don't need this property (use public-scrip-coord@w3.org for discussion). diff --git a/dom.html b/dom.html index c44c0f3e3..5e5079b05 100644 --- a/dom.html +++ b/dom.html @@ -687,7 +687,8 @@

event’s eventPhase attribute value is AT_TARGET.
passive
- When the passive member is set to true, it indicates that the listener’s callback will not cancel the event by invoking preventDefault(). + When the passive member is set to true, it indicates that the listener + is passive in that it’s callback will not cancel the event by invoking preventDefault(). Invoking preventDefault() from within such a callback will have no effect.

Setting passive to true can enable the user agent to perform performance optimizations described in §3.8 Observing event listeners.

@@ -767,18 +768,18 @@

Dispatch the event and return the value that returns.

3.8. Observing event listeners

- In general, developers don’t expect the presence of an event listener to be -observable. The impact of an event listener is determined by it’s callback. -That is, a developer adding a no-op event listener would not expect it to have + In general, developers do not expect the presence of an event listener to be +observable. The impact of an event listener is determined by its callback. +That is, a developer adding a no-op event listener would not expect it to have any side effects.

Unfortunately, some event APIs have been designed such that implementing them -efficiently requires observing event listeners. For example, sensor APIs which +efficiently requires observing event listeners. For example, sensor APIs which enable an underlying device sensor, and touch APIs which can be used to block -async scrolling. In some cases this problem can be mitigated by specifying +asynchronous scrolling. In some cases this problem can be mitigated by specifying the event to be cancelable only when there is at least one -non-passive listener. For example, non-passive TouchEvent listeners must block scrolling, but if all listeners are passive then -scrolling can be allowed to start asynchronously by making the TouchEvent uncancelable (so that calls to preventDefault() are ignored). -New event types should be defined such that they don’t need this +non-passive listener. For example, non-passive TouchEvent listeners must block scrolling, but if all listeners are passive then +scrolling can be allowed to start in parallel by making the TouchEvent uncancelable (so that calls to preventDefault() are ignored). +Ideally, any new event types are defined such that they don’t need this property (use public-scrip-coord@w3.org for discussion).

3.9. Dispatching events

To dispatch an event to a @@ -5106,7 +5107,12 @@

parentNode(), in §6.2
  • partially contained, in §5.2
  • participate, in §2.1 -
  • passive, in §3.6 +
  • + passive +
  • passive flag, in §3.2
  • pointerBeforeReferenceNode, in §6.1
  • position, in §5.2