Currently, we use Fragment::UniqueID[1] as the "ElementId" of composited elements[2]. This changes every time the element is detached/reattached or simply removed from layout (e.g. display: none) or a non-trivial relayout occurs resulting in a temporary loss of layout state and means that changes to the fragment id need to be tracked and sent in the commit anytime this changes and tracked per tree (pending / active) as it may be different in each.

However, we could associate the ID with Element (or the Node superclass), where it would remain stable for the lifetime of that element (which is semantically consistent with how its used on the compositor).

In Slack, Philip and Chris raised concerns about multiple fragments generated from the same Element. These could be handled in one of two ways.
a. If we don't need to target specific fragments, we can change our structures to allow multiple fragments associated with the same element id.
b. If we do need to target particular fragments, depending on the use case we could alias it with an additional component for the fragment (either an enum of particular targets or another autogenerated id).

This would greatly simplify tracking all things element related, i.e. from element creation you could track when the layout was done for that element, when it is and isn't composited, etc without needing to have additional data structures to detect and track changes to the id due to rendering implementation details.

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/fragment_data.h?type=cs&g=0&l=46
[2] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/compositing/composited_layer_mapping.cc?type=cs&g=0&l=2349