@wbamberg defaultTab is added and this at-rule is fully working on modern browsers. Could you take some time to review it please?

This works fine. The only reservation I have is that I'm a bit uncomfortable when we have animations that play by default, as animations can be very distracting. Most (but not all!) of our examples for CSS animation properties are triggered by a button, so the user can choose when (and whether) to see the animation.

I wondered if we could do something like:

@keyframes bounce {
    from {
        margin-top: 0;
        background-color: #1766aa;
    }
    to {
        margin-top: 40%;
        background-color: #078372;
    }
}

.animating {
    border-radius: 50%;
    border: 5px solid #333;
    height: 150px;
    width: 150px;
    background-color: #1766aa;
}

div:hover > .animating {
    animation: bounce alternate 1s infinite;
}

?

A couple of issues with this:

• if we did this we should probably change the class name to animatable or something like that
• it makes the example longer, so we would need the taller editor
• would users figure out that they have to hover to see the effect, or should we add a label, which would make things even more complicated? I think they should figure it out probably.

What do you think? Honestly I'm not sure if it is worth adding this or if your PR is fine as it is.

@wbamberg I don't think using hover is a good idea, because it wouldn't work on smart phones and even PC users might not notice that placing a mouse over example is required for it to work.

I reworked example so user needs to click on the box to start or stop animation.

JavaScript code sets animationPlayState values, so CSS is not cluttered and we can keep current window height. Unfortunately it also requires Shadow DOM PR.

@wbamberg I don't think using hover is a good idea, because it wouldn't work on smart phones and even PC users might not notice that placing a mouse over example is required for it to work.

I reworked example so user needs to click on the box to start or stop animation.

JavaScript code sets animationPlayState values, so CSS is not cluttered and we can keep current window height. Unfortunately it also requires Shadow DOM PR.

This approach looks good to me. I wonder if we should label PRs that are blocked by the shadow DOM PR.

instead of using JS to pause and play, we can use hover and focus-within - activating the animation when the user is either hovering the example (for pointer users) or has entered the widget (for keyboard users)

instead of using JS to pause and play, we can use hover and focus-within - activating the animation when the user is either hovering the example (for pointer users) or has entered the widget (for keyboard users)

It would make the code of the example significantly longer. I also think that clicking is more convenient for users, especially those who use smartphones.