While investigating a failure in the /inert/inert-pseudo-element-hittest.html test case on WebKit-based browsers, we determined that this occurs because WebKit doesn't consider an inert element to be in view because it has pointer-events: none. We are returning an element not interactable error code because of this. Other engines to not exhibit this behavior.
An element is said to have pointer events disabled if the resolved value of its "pointer-events" style property is "none".
@gsnedders and I are both unclear on what the intention of "given the pretense that its pointer events are not disabled" is. Should we be assuming that the pointer-events state is supposed to be ignored based on that, or does "given the pretense that" just mean "and".
Once we understand what the intention here is, we should clarify the spec itself to know if this is really just an "and" or if this is a "ignore this other thing".
While investigating a failure in the
/inert/inert-pseudo-element-hittest.htmltest case on WebKit-based browsers, we determined that this occurs because WebKit doesn't consider aninertelement to bein viewbecause it haspointer-events: none. We are returning anelement not interactableerror code because of this. Other engines to not exhibit this behavior.The spec says
and
@gsnedders and I are both unclear on what the intention of "given the pretense that its pointer events are not disabled" is. Should we be assuming that the
pointer-eventsstate is supposed to be ignored based on that, or does "given the pretense that" just mean "and".Once we understand what the intention here is, we should clarify the spec itself to know if this is really just an "and" or if this is a "ignore this other thing".