We currently resolve url(...) (element) references by storing the 'id' / fragment bit in computed style. Resources are then registered during style recalc(!), and "clients" resolve/lookup references on style-recalc (or attach.)
Since resources are registered (using their layout objects) during the same phase as clients lookup references, the relative ordering of resources and their clients matter for the robustness with which these connections are made.
Also, since the resolution of references happens when creating the SVGResources, fragment identifiers can be resolved in the wrong tree scope (since the fragment identifier is what's inherited and not the actual resolved element reference.)
Change to a model where the DOM nodes are what's "registered" (should be more appropriate from a lifecycle PoV) and where references are resolved during (computed) style resolving.
This should provide a structure more suitable for implementation of additional resource features (such as issue 109212.)
Comment 1 by f...@opera.com
, Nov 13 2017