What happens when multiple container roots share the same identifier?

[mmocny]

My read of the spec (see below) an testing in chromium, suggests that identifiers are not actually required (i.e. <div containertiming> works), nor do they need to be unique.

However, every unique container (node) creates its own unique Container Timing Record.

It seems equally viable to me to consider sharing Records based on the string identifier, rather than the unique node. (Thought I do like that all unnamed nodes always just create a new root).

---

• a containertiming attribute will mark a node as a root, and add the node to a global map or roots.

  container root records map that maps container root Elements to Container Timing Record objects.

• Whenever any element paint happens, we merely walk up to the nearest root (https://wicg.github.io/container-timing/#handle-element-painted), add attribute the paint to that root.

[jasonwilliams]

My read of the spec (see below) an testing in chromium, suggests that identifiers are not actually required (i.e.

works), nor do they need to be unique.

Yes the identifiers effectively followed the same model as elementtiming where they are optional, then you can pull them out from the performanceObserver. I believe even for elementtiming they don't need to be unique. We can advise that they should be unique, but i don't think we can ensure that's the case (similar to the general id attribute)

I'm struggling to understand the benefit of sharing records based on the identifier, if anything i think it would cause buggy behavior if someone forgets they used the same identifier in another place. Records being tied to nodes makes sense to me as visually (imagining the tree structure), nodes are what act as the container, not the identifiers.

[jdapena]

Because of how the propagation works, we traverse all ancestors. The container timing id is for having an easy way to associate the record with a specific container (if it is unique), though now we also offer containerTimingRoot.

The reason we keep the id is for container timing roots that may go away after generating paints. They can be unique or not, and they are not mandatory. But we are binding each event to a specific root, not to a specific id. I don't see a clear benefit for unifying the notifications for a container timing root. And I see a lot of complexity for understanding what same id means.

In general, I'd say a good practice for IDs is making them unique. Specially for container timing roots that may be destroyed before processing the events.

[mmocny]

It depends on your mental model for what this feature is meant to be used for.

You describe a model where each container is a single ~component, logically occupying a single contiguous block of space.

I understand this model and I think it is a good one.

Of course, a single dom tree can actually be visually rendered into any part of the page and we don't force any restrictions on how the region is divided or overlaps with other content.

I'm struggling to understand the benefit of sharing records based on the identifier

You could imagine some feature developer may want to understand the loading performance of a set of related updates to the page-- perhaps a single logical feature that needs to add content in multiple places, or a single client side re-render that updates multiple parts of the page, yet wants to understand its rendering latency.

The current model is an improvement on element timing, but suffers from similar issues for such use cases-- you would have to maintain a set unique ids, and manually process the raw timing entries. Similar to your original polyfill.

if anything i think it would cause buggy behavior if someone forgets they used the same identifier in another place

The reason we keep the id is for container timing roots that may go away after generating paints

That's why I asked what the identifier is for. Based on the above, re-using the same identifier in multiple places would be already be buggy in these cases. And if content is not removed, you don't need it since you have rootElement.

---

My mental model is framed by a different use case: A single User Interaction updates multiple parts of the page, and these should all form a single shared paint attribution.

• Although multiple different dom nodes may be independent container roots, we merge the timing records into a single attribution entry.
• Conceptually it's similar to what would happen if you put the whole <body> into a container, and then applied containertiming-ignore to everything you don't care about. But you wouldn't want to do it this way with container timing, since this a global singleton.

Container Timing could model this behaviour by just supporting an id -> record map, and do the rest all the same as you do now.