[csswg-drafts] [css-images][css-masking][paint] Ambiguities in handling url()

tabatkins has just created a new issue for 

== [css-images][css-masking][paint] Ambiguities in handling url() ==
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() 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 

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](https://hofmannsven.com/2013/laboratory/svg-stacking/) 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.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/383 using your GitHub 

Received on Thursday, 4 August 2016 23:17:51 UTC