[selectors-4] Add pseudo-class to differentiate loading from dynamically added content

[flackr]

A common developer frustration I've heard around animations is that there's not really a good way to animate new content without also animating it when the page loads. A common way developers work around this is to add a class to the root once the page has loaded. This class can be used on animation rules so that content which was initially visible doesn't animate in.

E.g.

<style>
/* Only animate in elements added after document loads. */
.loaded .element {
  animation: entry 200ms;
}
</style>
<script>
document.addEventListener('DOMContentLoaded', () => { document.body.classList.add('loaded'); });
</script>

Seems like it would be really useful to add this as a built-in pseudo-class. My strawman proposal would be to match the pseudo-class :loaded after the load event has been dispatched. Then developers could match this pseudo to specify entry animations only when an element was not part of the original document.

[tabatkins]

What element would :loaded match on? The root, or everything?

[lilles]

How about an animation property that delays the start of the animation until the page finishes loading?

The example uses DOMContentLoaded which is different from the load event. Are both cases interesting?

What about transitions? Is this animations specific?

Chrome has had issues where we transition from initial styles if computed styles are enforced while render-blocking stylesheets load.

[bkardell]

I've always thought that we should have pseudos that correspond to the 2 major document events - DOMContentLoaded and load. I've even implemented it in some projects that used css-like languages and , as pointed out a lot of people just do it with script. That and 'javascript seems to be executing' were really common classes that got added to the root, they seem like obviously useful things to me that would be nice to just add natively.

I would totally support it and I think it should just match on the root and not on every element really - that matches more or less what people have done by attaching a class.

[ydaniv]

On page load event is nice, but in most cases it's completely impractical because what you actually want to know is when the element is visible on screen, which is already declared non-implementable as a selector.
For example, what if that element is loaded and below first fold? Usually you don't want the animation to play, unless it's set to infinite.
So this feels somewhat short of solving the common use-case.

[ydaniv]

Although, this can still be valid for top-layer-ish fixedpos components, e.g: dialogs, popups, lightboxes, cookie banners, etc.
But still limited for most of the content on the page.

[ydaniv]

@flackr if it's only animations we're dealing with, perhaps we might instead consider a new sort of a value animation-play-state that defines a "delayed" state of paused until a specified trigger? Something like delayed(loaded)?

So a delayed animation could look like:

.element {
  animation: entry 200ms delayed(loaded);
}

And the delayed() part will compute to paused until that trigger was reached, and from that point it will compute to running.

[cjpearson]

I think it might also be helpful for transitions. I've used the loaded class on body approach to apply a starting style. The goal is for the element to have a transition when shown/hidden but not on its initial appearance.

e.g.

@starting-style { 
  body.loaded .my-class {
    opacity: 0;
  }
}