Back in 2012, roc raised this issue about an ambiguity in handling url()s that might refer to an image or an SVG element reference: https://lists.w3.org/Archives/Public/www-svg/2012Oct/0019.html In particular, giving a url like "mask-image: url(foo.svg#bar)", do we load that as an SVG image with a fragment of #bar, or do we load it as an SVG document and retrieve the id=bar element (which might be a <mask> element)? This also infects all CSS-<image>-taking properties, if we let CSS refer to SVG paint servers.

There was a lot of discussion and seemingly consensus, but nothing ever got formally decided, and several of the affected specs (Images, Masking, etc) weren't edited to take this into account. Let's fix that! The conclusion seemed to be:

1. url()s without a fragment are always interpreted as images.
2. url()s with a fragment vary slightly based on property: CSS-defined properties default to interpreting it as an image, while SVG-defined properties default to interpreting it as an element reference. You can force the image interpretation by instead loading it with image(), and the element interpretation by loading it as element().

This means that background-image can only refer to a paint server by using element("foo.svg#bar"), while mask-image can only use an SVG Stack by using image("foo.svg#bar").

It also means that in our new attempt to define fill and stroke for CSS, it'll default fragment urls to being element references, as that's their current behavior in SVG.

Let's please put this 4-year-old issue to rest - I can do the edits to the necessary specs.