- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Aug 2016 23:17:44 +0000
- To: public-css-archive@w3.org
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [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 `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](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 account
Received on Thursday, 4 August 2016 23:17:51 UTC