Skip to content

[css-animations-2] List of pseudo-elements in composite order is non-exhaustive #4502

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
george-steel opened this issue Nov 8, 2019 · 5 comments · Fixed by #4616
Closed

Comments

@george-steel
Copy link
Contributor

In the definition of Animation composite order, the list of pseudo-elements only includes ::marker, ::before, and ::after. Since many other pseudo-elements exist, and there is no section of the spec restricting animations to these particular pseudo-elements, How should we resolve this? I can think of a few possibilities.

  1. Replace the specific list with "pseudo-elements in alphabetical order by selector", as is done to order transitions by property.
  2. Add an entry for "other pseudo-elements in alphabetical order by selector".
  3. Add a canonical ordering to the pseudo-element spec and reference it. This would have to keep up with changes.
  4. Add a restriction on which pseudo-elements may be animated to css-animations-1 and web-animations
@george-steel
Copy link
Contributor Author

@birtles @stephenmcgruer

@birtles
Copy link
Contributor

birtles commented Nov 9, 2019

At this point I tend to lean towards (4) (and work out the ordering for other pseudos once UAs actually need to animate them).

I don't particularly like (1) since I believe the ::marker, ::before, ::after ordering makes most sense when authoring.

@george-steel
Copy link
Contributor Author

My personal leaning is towards 2.

In the current spec, all pseudo-elements should be able to be targeted for animations (since we removed the requirement for EventTarget to make sense for the pseudo-element) and only animating before, after, and marker is a partial implementation. Restricting which pseudo-elements may be animated seems rather arbitrary.

@birtles
Copy link
Contributor

birtles commented Nov 11, 2019

I guess the question is, is Blink looking to implement animation for other pseudos in the near future? If not, I don't think we should spec it yet.

@george-steel
Copy link
Contributor Author

george-steel commented Nov 11, 2019

I'm hoping to do so as long as the code doesn't fight back too much. Our current implementation of hanging Animations off of blink::PseudoElement objects (likely the source of the restriction) has lifecycle issues and needs refactoring anyways, fixing it might make all pseudo-elements animatable. I don't think we should de-spec it just now.

george-steel added a commit to george-steel/csswg-drafts that referenced this issue Jan 24, 2020
Fixup of w3c#4437 addressing w3c#4301.

* Add pseudoElement option to KeyframeEffect constructor body
* Fix w3c#4502 adding catch-all pseudo-element case to composite order
* Fix w3c#4586 adding error handling to KeyframeEffect.pseudoElement
* Fix w3c#4701 making note of case when property values cannot be calculated
stephenmcgruer pushed a commit that referenced this issue Jan 30, 2020
…change. (#4616)

Fixup of #4437 addressing #4301.

* Add pseudoElement option to KeyframeEffect constructor body
* Fixes #4502 by adding catch-all pseudo-element case to composite order
* Fixes #4586 by adding error handling to KeyframeEffect.pseudoElement
* Fixes #4701 by handling cases when property values cannot be calculated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants