[css-view-transitions-1] domUpdated isn't the right term

[annevk]

Apart from a couple of events that are prefixed with DOM*, we don't really expose DOM as a term to web content and I think we should keep it that way.

Either keep this somewhat more abstract or go with nodeTreeChanged or some such.

cc @jakearchibald @domenic

[jakearchibald]

The developer provides a callback that updates the state of the page in some way that forms the 'after' state of a transition.

domUpdated relates to the success/failure of that update.

It doesn't need to be a tree change. It can be a class name changing, an inline style, a CSSOM change etc etc.

Some other name ideas:

• stateUpdated
• viewUpdated
• updateHandled
• changeHandled

I'll try and think up more options.

Although, I think domUpdated works pretty well. The developer updates the DOM, therefore the DOM is updated.

[annevk]

It sounds like you and I have a different understanding of what DOM means. If the overall feature is called view transitions, viewUpdated makes some sense to me.

[jakearchibald]

The problem with viewUpdated, is… what the user sees isn't updated yet.

Here's a diagram I've been working on to go in the spec that tries to explain the phases of a view transition.

out.mp4

The three promises map to those phases:

• domUpdated - once "developer updates DOM"
• ready - once "transition layer populated"
• finished - once "transition layer cleared"

I had assumed that a change to styling counted as a DOM change, as text content of a style would have changed, or a rule in CSSOM would have changed etc etc. My assumption is that CSSOM was a subset of the DOM, since it's properties that hang off nodes that are part of the document.

viewUpdated seems wrong, because the user may not see it yet. It's the document model that's updated.

[annevk]

How about something like stateChanged?

I think there's quite distinct ideas about the scope of the term DOM and as such I'd rather also not have it as a term-of-art in APIs or even prose.

[jakearchibald]

I thought you were saying 'state' was problematic in #8143?

[jakearchibald]

Ah, ok, I think I understand what you mean in #8143 now.

stateChanged is vague, and clashes with state updates in frameworks (which happen before DOM updates). I'll have a think.

[jakearchibald]

@vmpstr suggested the name should reflect that it's linked to the callback passed to startViewTransition.

So:

• callbackDone
• updateCallbackDone

I prefer the latter, in case we add other callbacks in future.

[tbondwilkinson]

From an API perspective:

startViewTransition(callback);

There's nothing about the API shape right now that implies a name for the callback parameter passed to startViewTransition. The spec does call it a UpdateDOMCallback, but that doesn't appear in the API. If Anne has an issue with DOM appearing in the API, perhaps the spec should also be changed to a more neutral name?

You could consider using "render," as I believe that's a term unrelated to DOM but reflects that the operation is to change the rendered content.

renderViewCallback, perhaps.

[jakearchibald]

There's nothing about the API shape right now that implies a name for the callback

There might in future, if the API changes to a dictionary to allow for options, and perhaps other callbacks.

perhaps the spec should also be changed to a more neutral name?

Yep, it will be, to reflect the name we decide here. But the developer-facing name is more important.

You could consider using "render,"

See the video in #8144 (comment). I don't think "render" is a good choice because the change is not rendered visually.

[tbondwilkinson]

updateCallbackDone just feels so generic. :( Is there really no verb commonly used for the modification of HTML elements on the page?

[annevk]

Mutations (see MutationObserver), but those exclude changes to style sheets.

[jakearchibald]

The nice thing about updateCallbackDone is it's clear it's related to whatever you did in the callback.

If you mutate the DOM, change a style, and then (for whatever reason) await something unrelated in the callback, a name like domUpdated, viewUpdated, mutated etc etc might suggest that the promise is related to a subset of things you did in the callback, but it isn't.