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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 29 Oct 2012 23:53:44 +0100
Message-ID: <CAAWBYDB1Z1=A5kP=_5_498=+UUVk-JSpFCi4QAhqBDJvZ7xnwg@mail.gmail.com>
To: robert@ocallahan.org
Cc: Dirk Schulze <dschulze@adobe.com>, Karl Dubost <karld@opera.com>, www-svg <www-svg@w3.org>, www-style <www-style@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC