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

On Mon, 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'.
>
> 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! :-)

Cool.  We'll make a final decision next week in SVGWG, and record it
in an appropriate spec.

~TJ

Received on Monday, 29 October 2012 22:54:32 UTC