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

On Oct 25, 2012, at 12:10 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> Dirk Schulze mentioned that the SVG WG wants to allow 'fill' and 'stroke' to accept both CSS image values and SVG paint-server values. This means that "fill:url(abc.svg#ref)" could refer to either part of an SVG image (via http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers ), or to a paint server. The user-agent would have to resolve the ambiguity by loading the resource to determine whether the element with id 'ref' is a valid paint server, and presumably treat it as a paint server if possible, otherwise a link into an SVG image.
> 
> Unfortunately that would be a real pain to implement in Gecko, because our code for loading SVG images is separate from our code for loading external resource documents, and we need to know at the start of the load which path to take. Also, we treat the loaded documents differently. We impose a same-origin restriction on external resource document loads but not on SVG image loads. SVG images are not allowed to refer to external resources for security reasons, but external resource documents can. SVG image documents can be shared between different users of the same SVG image (even from different domains), but external resource documents are not. Etc.
> 
> The best implementation approach for us might be to try loading the URI as an external resource document, and if that fails or the element turns out not to be a paint server, try to load it as an SVG image instead. But that seems slow, hacky and it could easily confuse authors.
The approach as well as the difficulty with doing that look reasonable. We have the same problem with the 'mask' shorthand on CSS Masking (see discussion on www-style).

WebKit seems not to have a widely implemented property that would require CORS check. I actually can't tell how we would implement it in WebKit.

> 
> AFAIK Webkit doesn't have this problem because it doesn't support references to paint servers in external resource documents. I don't know about other engines.
Yes, WebKit does not support external resources like mask, clip-path or paint servers.

> 
> I'm also concerned that requiring SVG images and external resource documents to be treated in a uniform way could blow up in our faces later since both of those are extremely underspecified right now and have security requirements that are not very well understood.
I separated the CORS problem for resources in a different thread. This is indeed a complex topic and needs further discussions. It would be great if someone with implementation details from Mozilla on SVG resources could join the next call (Thursday/Friday in two weeks). It would be interesting to hear about the concerns from an implementer. But it would still be great if you can send as much details as possible.

I would also like to hear more about the possible blow up with using SVG images as paint sever. Obviously we have the recursion problem (self referencing). This is nothing new in SVG :/. Do you see further problems?

Greetings,
Dirk


> 
> 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 Saturday, 27 October 2012 00:57:57 UTC