[css-scroll-snap-2] Should pseudo-elements show up as null SnapEvent.snapTargetBlock/Inline

[DavMila]

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.

[flackr]

I think that if a pseudoElement is targeted by a snap event, we should handle this similar to a pseudoElement targeted by other targeted events (e.g. pointerevents / ui-events) where the target is the owning element of the pseudoElement, e.g. try clicking on the ::before or ::marker objects in https://codepen.io/flackr/pen/NWmyRra

If in the future developers need to know which pseudo-element was the target we could follow the precedent of animation events and add a string pseudoElement representing the targeted pseudo element but I think we probably don't need to add this yet as we don't have this for most events.

More generally I think we do want to be able to target pseudo elements, and there is an interface for them to be event targets defined in pseudo-4, but this will be a backwards incompatible change for other targeted events.

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-snap-2] Should pseudo-elements show up as null SnapEvent.snapTargetBlock/Inline, and agreed to the following:

• RESOLVED: Dispatch scroll snap events on pseudo elements by targetting the ultimate originating element

The full IRC log of that discussion

<fantasai> s/Topic/Subtopic/
<fantasai> i/Subtopic/Topic: Scroll Snap 2/
<fantasai> flackr: You can set scroll-snap-align on pseudo-elements, and UA snaps to them
<fantasai> flackr: what should we do for the events we're defining?
<fantasai> flackr: my proposal is to treat just like other targetted events, and dispatch at owning eleent
<fantasai> flackr: just like click etc.
<fantasai> flackr: Dev won't have any way to know which pseudo was targetted
<fantasai> flackr: could expand similar to Animations to add a string saying which pseudo
<fantasai> Rossen: Are there use cases for such dispatching?
<fantasai> flackr: Pseudo-elements can be snapped to, want to tell dev that we've snapped to something
<fantasai> flackr: we just don't have a way to reference the pseudo without the pseudo IDL in css-pseudo-4 which nobody has shipped
<fantasai> flackr: the dev will know that we snapped to something, just won't know which
<fantasai> flackr: could get complicated in combination with some of the ongoing current proposals
<fantasai> flackr: like adding snap areas to fragments etc.
<florian> q+
<fantasai> flackr: but for things like ::after/::before, probably don't need to care
<fantasai> florian: Seems more typical than if you snap to pseudo *and* element
<astearns> +1 to consistency with other targeted events (even though it isn’t entirely useful)
<fantasai> florian: [missed]
<khush> q+
<fantasai> florian: I would hope that we explore sooner than later how to target pseudos in general
<fantasai> florian: if we think the most promising approach doesn't work, then we paint ourselves into a corner this way
<fantasai> florian: so if we expect it to be the way forward, should make sure it is the way forward
<Rossen__> ack florian
<fantasai> flackr: I have some ideas on supporting generic events, but point taken
<fantasai> khush: With all the other places we've worked around lack of expressing pseudo in JS by using its originating element and string saying which pseudo
<fantasai> khush: noted we could give that string here
<fantasai> flackr: I'm proposing that just like with other events, says target is the owning eleent
<fantasai> flackr: if we extend later, propose matching Animations string, says targetting this pseudo with this string
<fantasai> khush: so right now no use case for knowing whether element or pseudo?
<florian> s/[missed]/and if the pseudo is the only possible target on this element, there's not much of a mistery what you snapped to. But authors are infinitely creative, so my expectation of what's typical is not necessarily warranted]
<fantasai> flackr: ...
<fantasai> Rossen: Sounds we can resolve, unless other comments?
<astearns> s/.../no strong use cases/
<fantasai> PROPOSED: dispatch events on pseudo by targetting the originating element
<fantasai> khush: "ultimate originating element"
<fantasai> RESOLVED: Dispatch scroll snap events on pseudo elements by targetting the ultimate originating element