There seems to be a gap in the standards algorithm for delivering PointerEvents.

The event properties offsetX and offsetXYshould yield local coordinates from the border-box origin of the closest element which has a box in which to report offsets.

If the original target was a pseudo element inside a display:contents element, offsetX and offsetY are reported as clientX and clientY (Maybe they are pageX and pageY - I haven't tested scroll).

This means processing which utilizes the target and offsetX and offsetY has to do some gymnastics to arrive at the information it wants. It's workaroundable, but should not have to be.

There is a Chromium issue covering this here with some discussion: https://bugs.chromium.org/p/chromium/issues/detail?id=1518093#c11

It can be illustrated in this Codepen: https://codepen.io/Animal-Nige/pen/qBvqxjz

Clicking in the center of the red box logs to the console and reports the event's offsetX and offsetY (which should be around the 50s) as clientX and clientY.

This behaviour is the same in Chromium and Safari, so has probably always been in WebKit. Safari report: https://bugs.webkit.org/show_bug.cgi?id=267815

Firefox also returns unexpected results, but in a different way. Firefox report: https://bugzilla.mozilla.org/show_bug.cgi?id=1875617

So I think the spec must be ambiguous here. The spec needs an extra step when describing how to ascertain the offsetX and offsetY:

"If the element has no box, find the closest parent element which has a box."

Where "closest" is in the sense of the Element#closest method. The closest ancestor.