Skip to content

[css-animations-1][css-transitions-1] Add .pseudoTarget to AnimationEvent and TransitionEvent#13603

Open
danielsakhapov wants to merge 3 commits intow3c:mainfrom
danielsakhapov:spec_edit_for_css_12163
Open

[css-animations-1][css-transitions-1] Add .pseudoTarget to AnimationEvent and TransitionEvent#13603
danielsakhapov wants to merge 3 commits intow3c:mainfrom
danielsakhapov:spec_edit_for_css_12163

Conversation

@danielsakhapov
Copy link
Contributor

As resolved in #12163, add .pseudoTarget to selected event types and describe the initialization process for it.

As resolved in w3c#12163, add .pseudoTarget to selected
event types and describe the initialization process for it.
@danielsakhapov danielsakhapov requested a review from dbaron March 5, 2026 10:38
@danielsakhapov
Copy link
Contributor Author

The spec text is mostly shaped and influenced by w3c/uievents#413

@danielsakhapov
Copy link
Contributor Author

Copy link
Member

@dbaron dbaron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments below. I commented on the animations spec, but I think the same comments also apply to the transitions spec.

runs (in which case the target of the event is that pseudo-element's corresponding
element), or the empty string if the animation runs on an element (which means the
target of the event is that element).
<dt><dfn>pseudoTarget</dfn>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the definitions of pseudoTarget and pseudoElement should probably be equivalent, in that I would expect that pseudoElement and pseudoTarget.type should be the same.

However, the definitions seems sufficiently different right now that I wonder if that's actually the case, for example, if the pseudo-element is in a shadow tree and the retargeting algorithm affects things.

Are they intended to be equivalent as I would expect, or are they intended to be different? (I think it should be clear either way.)

1. Let |origin| be the [=AnimationEvent/pseudoTargetOrigin=] internal slot.
1. Let |retargeted| be the result of [=retarget=]ing |origin| against |currentTarget|.
1. If |retargeted| is not |origin|, then return <code>null</code>.
1. Return {{AnimationEvent/pseudoTarget}}.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this is formally correct. This seems to be treating pseudoTarget as an internal slot in addition to being a property, but it doesn't really describe it as an internal slot. (Someone more familiar with these concepts should probably review.)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is similar to CommandEvent.source.
See the red box there

@danielsakhapov danielsakhapov requested a review from dbaron March 17, 2026 14:45
Copy link
Member

@dbaron dbaron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, with one comment below. Hopefully @smaug---- can review as well.


Note: {{AnimationEvent/pseudoTarget}} and {{AnimationEvent/pseudoElement}} are intentionally
not equivalent. Because {{AnimationEvent/pseudoTarget}} returns a {{CSSPseudoElement}}
object, it is subject to retargeting and encapsulation. Therefore, if the event's target
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what the "and encapsulation" means here -- I think the underlying purpose of the retargeting could be described as encapsulation but I don't think there are two separate things happening here (unless I'm missing something).

(same below for TransitionEvent)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants