You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We resolved in #9908 to add a pseudo element to getAnimations which shifts the target of the call to the pseudo element instead of the originating element.
In the PR #11050 a question came up of what to do if it's invalid. Other web animation functions throw an exception which is what we added in the PR. Then, checking getComputedStyle MDN says that it throws, but neither @flackr nor I couldn't spot anything in the spec that would say it throws.
Filing this to resolve on consistent treatment and proposing that we throw a SyntaxError DOMException if the pseudo element is invalid.
birtles
changed the title
[cssom][web-animation-1] Consistent behavior for invalid pseudos in getComputedStyle/getAnimations
[cssom][web-animations-1] Consistent behavior for invalid pseudos in getComputedStyle/getAnimations
Oct 25, 2024
Throwing is not web compatible for getComputedStyle, see #6501
Thanks for the reference. We should still resolve whether or not we want to throw here, and if it makes sense that we throw when trying to set the target or contruct an animation for an invalid pseudo elment selector.
My read of the linked discussion is that we decided not to throw for getComputedStyle for compat reasons only, so I guess I'd propose that we throw for Element.getAnimations({pseudoElement: <invalid>}) to be self consistent within web-animations with setting an invalid target pseudo and make it likely developers would see the error.
We resolved in #9908 to add a pseudo element to getAnimations which shifts the target of the call to the pseudo element instead of the originating element.
In the PR #11050 a question came up of what to do if it's invalid. Other web animation functions throw an exception which is what we added in the PR. Then, checking getComputedStyle MDN says that it throws, but neither @flackr nor I couldn't spot anything in the spec that would say it throws.
Filing this to resolve on consistent treatment and proposing that we throw a SyntaxError DOMException if the pseudo element is invalid.
/cc @flackr
The text was updated successfully, but these errors were encountered: