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: Tue, 30 Oct 2012 00:44:02 -0700
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: Karl Dubost <karld@opera.com>, www-svg <www-svg@w3.org>, www-style <www-style@w3.org>
Message-ID: <081BC22C-FBE9-4B84-82E5-A3F0F91D6A0C@adobe.com>

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

> On Tue, Oct 30, 2012 at 10:48 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> He suggests not doing any heuristics, but follow a predefined default behavior. 'fill', 'stroke', 'mask', 'clip-path' always assume that fragments (which are no media fragments) are treated as resources. For all other properties, they are treated as images.
> 
> This approach seems at least acceptable. I'm not sure that it's optimal. It does need to be fleshed out a little bit.
> 
>> For CSS Masking that would mean:
>> 
>>         mask: url(image.svg#id) is assumed to be a mask resource. At least if it is the only reference. If it has more than one list item, it is treated as image again.
>> 
>>         mask-image: url(image.svg#id) is assumed to be an image, since the property, by default, takes CSS Images.
> 
> This is a problem. I don't think we can, according to the architecture of CSS, make the interpretation of a CSS property value depend on whether it came from a shorthand or not. I also think it would be awfully confusing for authors. And consider the CSSOM implications if you set 'mask' and then read the computed value of 'mask-image'.
You are right, WebKit would have the same problem.

> 
> My best idea there would be to make 'mask-image' default to a paint-server. So the proposal would be:
> Given a url() value in the context of a property P:
> a) if the URI has no fragment identifier, treat it as an image load.
> b) if the URI has a fragment identifier, treat it as an external resource reference if P is 'mask-image', 'fill', 'stroke', 'clip-path', 'filter' (... extensible list of SVG CSS properties here), otherwise treat it as an image load.
> 
> This means that background-image etc can only refer to a paint server using the element() syntax, not the url() syntax; CSS image-value syntax is not fully unified across properties. This proposal may be more confusing to authors than my property-independent proposal, I'm not sure. This proposal is more compatible with SVG stacks. Overall, I'd be happy with either proposal. Someone please make a decision! :-)
Sounds like a good compromise. For all non-SVG-properties, we have element() to reference a paint server.

Greetings,
Dirk

> 
> Rob
> -- 
> Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
> 
Received on Tuesday, 30 October 2012 07:44:57 GMT

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