Convert "ignore" into a nesting mode, and add variants.

[mmocny]

Right now we have containertiming-ignore and containertiming-nesting strategy. I think you could just merge these together as a single "nesting strategy" but help disambiguate "ignore" mode.

I think there are two forms of "ignore":

1. "Not interested in any timings, for self or ancestors" (performance optimization?)
2. "This is a container root, and I don't want to report paints up" ("isolated" component or something?)

Consider using names such as: disabled and private to differentiate (bikeshed!).

[jdapena]

containertiming-ignore may go in any node, and blocks sending events to its containertiming ancestors. The intent of this is inhibiting parts of the tree that could actually report paints, but are not expected to be reported. A typical case is: if you add containertiming to the body, and a part of the tree is actually an overlay with the paint data. This does not match cases 1 or 2. Did you actually mean "not interested in any timings for self or descendants"?

containertiming-nesting is only used in a node with containertiming, and defines if it is going to use information from its containertiming descendants or not. This does not match cases 1 or 2 either.

Now, nesting is about which paint events from descendant container roots will be actually processed. It may be interesting to be able to block a containertiming from sending events to its ancestors, from the actual element. Curiously we have a combination of attributes that could express that well: containertiming and containertiming-ignore. Right now the ignore will be... ignored, as containertiming has precendence. But... it looks to me it would make more sense that containertiming-ignore would block from emiting paints to its ancestors, and still get the events for that containertiming root. That would allow to do some component encapsulation, so a specific node root could intentionally inhibit its paints to be used in container timing roots above in the tree, and still have the container timing root generating events.

So, in any case, about this specific proposal... I would prefer to not merge both, as they are completely different aspects: one related to ancestors, the other related to descendants.

About the names of the attributes... containertiming-ignore is somehow fine to me: it determines a part of the tree to be ignored. containertiming-nesting is... less intuitive. We could try to find a better name.

(And we have the thing that these attributes have a dash in the middle. Not many attributes have that, and I suspect this is something the standard may not like?).

[mmocny]

For the overlay case:

• If you want to measure paint for the overlay, but want to keep these separate and not report up to body, then containertiming should be sufficient (because containertiming-nesting="ignore" is the default).
• If you want to just ignore all the paints inside the overlay for every observer, you should be able to apply containertiming-nesting="disabled" (or, perhaps ignore without containertiming attribute implies disabled?)

(2) above would need support for containertiming-nesting on nodes without containertiming (perhaps one implies the other?)

[mmocny]

...and in that case, the term "nesting" might need some iteration. As you say, CT is about descendants, nesting is above anscestors.

And it's really less about literal ct's nesting, too, except in that the current default CT attribute changes paint reporting and so nesting becomes important.

I think its more about: how should you report paints up from this element? Regardless of CT attribute settings on it or below.

Is this dom tree:

• logically a single visual component with a single painted area (shadowed)
• Just a "div" grouping things together, and should report all child paints (transparent)
  • this is the default for all elements without CT attribute
• Visual component, but distinct from parent, collect but don't report paints up (ignore)
• Non-visual component, don't collect and don't report paints (disabled)

My 2cents.

[mmocny]

With that framework in mind, I could see policies like the following:

• Components like <table> and <svg> start to get a containertiming-mode=shadowed by default (needs new name?), but don't get a containertiming attribute.
  • Still, api's like LCP might still report timings for these, even without explicit name
• Components like <dialog> start to get containertimeing-mode=ignore by default
  • Again, might still get reported without explicit name

I cannot think of any content that would be `disabled by default...

[jdapena]

I like the idea of containertiming-mode name, and the proposed values (and even the default behavior depending on the component). Is it something that new or do we have other attributes that can change their default value depending on the element type?

Anyway, it looks to me the propagation rules are way different. Let's imagine how a containertiming-mode could work, that can be added to any node. First, it looks to me, once we have containertiming-mode we just need 3 types:

• ignore: stop upwards propagation (it works exactly as containertiming-ignore).
• transparent: upwards propagation preserves the downwards node.
• shadowed: the node shadows downwards node information, and replace it with itself.

We don't need a disabled mode, as it would be equivalent to containertiming-mode=ignored without containertiming.

Algorithm

Attention flag

The flag we use to know if a node needs to report its paints:

• Any element with containertiming would be reported.
• When we have a node with containertiming-mode=ignored its children would not get the flag. In this case it would work exactly as containertiming-ignore=true.
• Transparent, shadowed, do not modify the attention flag propagation.

Paint notification

When we get a paint in a node we report to its node (in case it is containertiming). Then, we start propagation upwards.

For each node (including the initial):

• if mode is "ignored" then we don't propagate further.
• Mode is transparent, we continue propagating upwards with the same painted node information.
• Mode is shadowed: we continue propagating upwards, but replace the painted node information with the current one (the node shadows the contained nodes).

Default values for mode

I'd just keep what you said, and we would progressively iterate on nodes as we find more useful default modes.

Other possible names

• containertiming-send-up: "yes" (requivalent to transparent), "no" (equivalent to ignore), "shadow" (equivalent to shadowed).

[mmocny]

Is it something that new or do we have other attributes that can change their default value depending on the element type?

I asked gemini and got the following:

• value and type can change depending on element and its markup (i.e. <button> vs <input type=button>
• Some elements get a default target
• Some elements get a default crossorigin

However I admit this isn't that common.

I'll add on top of that: perhaps default accessibility/ARIA and role values, which are designed to match the element/UX semantics, are a good comparison to make?

However I admit this isn't that common.

---

We don't need a disabled mode, as it would be equivalent to containertiming-mode=ignored without containertiming.

I was making a distinction between:

• Don't even mark timings inside this tree (perf optimization), vs
• Measure this tree (perhaps to report timings to itself), but don't propagate paints up to anscestors

However, perhaps you are right. disabled can be inferred by UA's for all trees that are both ignored and not themselves opted into measurement.

---

Modified algorithm LGTM and is I think similar to what we have now just merged.

---

Regarding "other possible names", I think we can fork the conversation to its own issue-- but I'm considering a world where Container and Element timing merge. In such a world, I wonder if "transparent" vs "shadowed" should really mark a node either as an "element" vs "container".

[jasonwilliams]

So how about this? (we can bikeshed names).

We can change "nesting" to "mode" (these all apply to container roots only) so:

• containertiming-mode="transparent": upwards propagation preserves the downwards node. (Default)
• containertiming-mode="private": stop upwards propagation (it works exactly as containertiming-ignore).
• containertiming-mode-"shadowed": the node shadows downwards node information, and replace it with itself.

I've changed "ignore" to "private" above as "ignore" doesn't really make sense (the container itself isn't ignoring anything, however, events are encapsulated to this container root).

That leaves the problem of how do you ignore a sub part of the DOM without it recording internally?

Don't even mark timings inside this tree (perf optimization), vs
Measure this tree (perhaps to report timings to itself), but don't propagate paints up to ancestors

We will need a new attribute for this scenario and it shouldn't be a containertiming-mode=* attribute as so far, those are only for containertiming roots. So maybe we need containertiming-ignore?

We can also allow svg and Shadow DOM elements to have containertiming-mode="shadowed" by default (im not sure if we need to offer some escape hatch to override this or not).

[jasonwilliams]

https://github.com/bloomberg/container-timing/blob/main/docs/container-definitions.md should addresss the issue here. It explores the idea of removing modes entirely and instead defining each container in isolation, then the pros and cons of doing that vs what we have now. Please take a look at let me know your thoughts

[jdapena]

I think we need to apply the container timing mode changes before the origin trial. And make the transparent mode the default as Jason proposed. To me the current nesting implementation is confusing, and does not allow the shadowed mode to work as expected. And, on top of that, our paint events are not supporting shadow DOM at all (explicitely skipping it).

So, we can completely remove the nesting mode, and make all container roots transparent.

Then, when we have a solution for shadow roots, we apply whatever we decide later. This will not be needed for the origin trial.

[mmocny]

(sgtm)

[jdapena]

Oh, and a corner case, that I think we need to change, as with current implementation it does not do what is expected.

When we have a node that is a container timing root, and has the containertiming-ignore attribute, that should mean the paints inside that container timing root (including itself) will be reported to that root, but not propagated upwards. This is important for when we have a specific part of the screen we may want to report separately (i.e. an overlay). This will behave like containertiming-nesting=ignore in the past, allowing to isolate (and still report) specific parts of the tree.

What it does right now? It will still propagate to the ancestor container timing root if there is no ignore in the middle. So that ignore is useless.

This is interesting as, before, containertiming-ignore was... ignored... if it was set to a containertiming root element, and now it again make it more intuitive than when we had nesting modes.