W3C home > Mailing lists > Public > www-style@w3.org > October 2012

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Sun, 28 Oct 2012 16:18:07 -0700
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, www-svg <www-svg@w3.org>, www-style <www-style@w3.org>
Message-ID: <438F07FB-6B9A-4CD1-A68B-3D04BCC45928@adobe.com>

On Oct 28, 2012, at 11:52 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Mon, Oct 29, 2012 at 11:26 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Oct 28, 2012, at 10:06 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote:
>> On Mon, Oct 29, 2012 at 2:40 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> In that case, as long as we're *able* to head off SVG Stacks at the
>> pass, I'm cool with your alternate approach, suitably expanded to
>> disallow all things that *look* like MFs in step a (that is,
>> everything with an ident followed by an = sign).
>> 
>> Can we simplify it to just exclude =, ( and ) characters from external resource references? That also excludes functional syntax like SVG 1.1 cooked up for svgView(). It also gives SVG Stacks users a workaround: use identifiers such as "=bar" in their images.
>> 
>> How will we know if we're "able to head off SVG Stacks"? I'm not entirely comfortable with just disabling them in Firefox without a commitment from other browser vendors to do the same.
> 
> Firefox supports it, opera supports it, won't take to long for WebKit to have fragments either. And there is already use of fragments, which makes it harder to restrict fragments at this time. (Filter Effects use them). It doesn't make sense to restrict them, just because we have a use case in mind where we could use a workaround. After all we mainly have fragments for resources, why would they still be allowed to use any fragment? Unless I did not misunderstand the proposal (may did not get all emails), I don't think this is a good idea at this point.
> 
> Do you have an alternative proposal for solving the problem, then?

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().

If we do it in SVG 2 at all. One thing that bothers me, is that we don't have the same technologies like the background properties, to stretch, clip and repeat images. So I think it won't do what you want most of the time. If we specify it, it might be delayed to SVG 2+ anyway since browsers will need some time to implement it.

Greetings,
Dirk

PS: Sorry, send last message with my phone which gets indentation wrong.
> 
> 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 Sunday, 28 October 2012 23:19:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT