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.
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
SnapEventfor which the selected snap target is a pseudo-element will have itsSnapEvent.snapTargetBlock(orsnapTargetInline) as null.From a developer’s point of view, this means there is some ambiguity about what a null
SnapEvent.snapTargetBlockmeans, 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:If the thing that was snapped to is a pseudo element, the code would not know to achieve
DoVisualEffecton 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.snapTargetBlockbe slightly more abstract than an Element, e.g. aSnapEventTargetinterface such as:would give the developer a little more information about the thing that was snapped to such that they could modify the earlier example with:
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)
:snappedfeature 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 ofsnapchangedand notsnapchanging. Perhaps an equivalent:snappingCSS selector would be worth considering.