[css-view-transitions-1] Is "named elements" map in the right order after "capture new state" algorithm?

[nt1m]

In "capture new state", there is this step:

If namedElements[transitionName] does not exist, then set namedElements[transitionName] to a new captured element struct.

However, it doesn't mention where to insert the element, which means by default we would be adding it at the end of the ordered map. It is the more convenient default to implement, but is this correct? You might expect to want to preserve the paint order or such (slightly more of a pain to do, but possible)

cc @noamr @khushalsagar @fantasai @tabatkins @vmpstr

[nt1m]

(This is of course an edge case, but it would be good to clarify still)

[noamr]

In "capture new state", there is this step:

If namedElements[transitionName] does not exist, then set namedElements[transitionName] to a new captured element struct.

However, it doesn't mention where to insert the element, which means by default we would be adding it at the end of the ordered map. It is the more convenient default to implement, but is this correct? You might expect to want to preserve the paint order or such (slightly more of a pain to do, but possible)

cc @noamr @khushalsagar @fantasai @tabatkins @vmpstr

The spec says here that the iteration on elements should be according to paint order.

[nt1m]

The spec says here that the iteration on elements should be according to paint order.

That doesn't really answer my question. I'm talking about step 4.6 of "capture new state":

For each element of every element that is connected, and has a node document equal to to document, in paint order:
[...]

• If namedElements[transitionName] does not exist, then set namedElements[transitionName] to a new captured element struct.

If namedElements[transitionName] does not exist, then where in the map do we set this new struct? By default it will be at the end of the map, and it doesn't matter in which order you iterate.

I'm aware that case is a super edge case, because most of the map will be populated by "capture old state", in the right order, but where the step 4.6. of "capture new state" appends in the map makes a difference visually.

[noamr]

The spec says here that the iteration on elements should be according to paint order.

That doesn't really answer my question. I'm talking about step 4.6 of "capture new state":

Oops, missed this, sorry.

I'm aware that case is a super edge case, because most of the map will be populated by "capture old state", in the right order, but where the step 4.6. of "capture new state" appends in the map makes a difference visually.

Yea, this would be an entry animation, which might be more than an edge case.
@vmpstr did we have prior discussions about this?
Also re. what happens when the paint order changes between old & new?

[vmpstr]

Yeah, there's a non-normative note that says that we're ensuring the named elements map has the same order as the paint order. This implies that the new elements that don't exist in the old state are painted as if they had higher paint order (ie paint on top). This is intentional.

I can't find the issue where we discussed this, so it may have been discussed in the PR as part of the initial draft, but here's a summary comment from Khushal: #8941 (comment) Essentially, we have to pick some order, and the one we have is as good as any, and not too complicated.

[nt1m]

I'm OK with how the current spec is written (it's actually easier to implement), but I think it would be good to add a note in "Capture new state" as well that this is an intentional choice.

[khushalsagar]

Thanks for the suggestion @nt1m. Here's the PR: #9768