The snap events spec indicates that a user-agent should identify the “element” to which a snap container snaps. Since pseudo-elements can also be snap targets and are not elements, this means that a SnapEvent for which the selected snap target is a pseudo-element will have its SnapEvent.snapTargetBlock (or snapTargetInline) as null.

From a developer’s point of view, this means there is some ambiguity about what a null SnapEvent.snapTargetBlock means, i.e. it could be mean that a pseudo-element was snapped to or that nothing was snapped to. For example, if a developer wishes to do some visual effect on the item that was snapped to, they might write something like:

scroller.addEventListener(“snapchanged”, (evt) => {
  if (evt.snapTargetBlock) {
    DoVisualEffect(evt.snapTargetBlock);
  }
);

If the thing that was snapped to is a pseudo element, the code would not know to achieve DoVisualEffect on that pseudo-element.

Perhaps this is okay and developers simply need to be a bit careful about using pseudo elements as snap targets where they expect to interact with snap targets via JavaScript which currently can't interact with pseudo-elements as it can with elements.

Alternatively, we could have the type of SnapEvent.snapTargetBlock be slightly more abstract than an Element, e.g. a SnapEventTarget interface such as:

interface SnapEventTarget {
  bool isPseudo;
  Element target;
}

interface SnapEvent {
  SnapEventTarget snapTargetBlock;
  SnapEventTarget snapTargetInline;
}

would give the developer a little more information about the thing that was snapped to such that they could modify the earlier example with:

scroller.addEventListener(“snapchanged”, (evt) => {
  if (evt.snapTargetBlock.target) {
    DoVisualEffect(evt.snapTargetBlock);
  } else if (evt.snapTargetBlock.isPseudo) {
    DoVisualEffectOnPseudoSnapTarget()
  }
);

The obvious problem with this approach is that a scroller may have multiple pseudo-elements which are snap targets and there would not be a straightforward way of knowing which of those the snap event was referring to.

Another point of consideration is that the (yet-to-be-spec'd) :snapped feature would be able to bridge this gap for pseudo-elements as far as style-related changes that can be accomplished by CSS. However, it would only be the equivalent of snapchanged and not snapchanging. Perhaps an equivalent :snapping CSS selector would be worth considering.