Re: Ambiguities in fill:url() / stroke:url() syntax

On Oct 29, 2012, at 3:38 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

>> On Mon, Oct 29, 2012 at 12:18 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> SVG fragments work with CSS Images on three different browsers (IE, FF, Opera) and will work in the near future in WebKit. So either CSS Images or Mediafragments should deal with it.
>> 
>> I personally don't see a disadvantage to reference images as paint server with a new 'image()' function: image(url(externel.svg#id)). Specific functions could be used directly like gradients or (later) element().
> 
> The problem is that for 'fill', 'stroke' and 'mask' properties, existing SVG specs and content require that url(foo.svg#abc) be interpreted as a paint-server reference. We can't requiring all existing content using 'fill', 'stroke' and 'mask' with url() paint-server references be updated to use different syntax. So making 'fill', 'stroke' and 'mask' accept url() CSS image values is a non-starter without some way of disambiguating the reference. The 'mask' problem is particularly acute since -webkit-mask *already* accepts CSS image values so simply unprefixing it would hit this problem.

Yes, I understand that. We can't change legacy content. My suggestion is that we keep going to reference current paint severs with url directly:

	fill: url(image.svg#id)

must either be a <color>, <linearGradient>, <radialGradient> or <pattern> element.

	mask: url(image.svg#id)

just can be a reference to a <mask> element.

	clip-path: url(image.svg#id)

must be a reference to a <clipPath> element.

Now to CSS Images on 'fill' and 'stroke'. If you really want to reference an image, or interpret an SVG as image (and not as resource). And if you want this image as paint server (we don't allow it currently; would be new), then you need the image() function.

	fill: image(url(image.svg#id))

image.svg#id gets now interpreted as image. It can not be an <color>, <linearGradient>, <radialGradient> or <pattern> anymore. And if it is, we don't care, but render the whole SVG (still depends on CSS and :target pseudo element if we paint something at all). Note, this is just for 'fill' and 'stroke'.
Not all CSS images would need the image() function: element(), linear-gradient(), radial-gradient() would not need it, image() would still accept it. The definition would be:

	image(<image>)

For masking, I opened a different thread "[css-masking] 'mask' with resource and image references". I think we have two possibilities (that are not hacky):
1) 'mask-image' does not get a short hand
2) The short hand for 'mask-image' gets renamed and  splitter from 'mask'. 'mask' will continue to just use <mask> references.

Greetings,
Dirk

PS: After discussing all these issues, does it mean that we can't extend element() to reference external documents?

> 
> Rob
> -- 
> “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others?" [Matthew 5:43-47]
>

Received on Monday, 29 October 2012 03:08:44 UTC