- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 5 Nov 2012 15:51:47 -0800
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, Karl Dubost <karld@opera.com>, www-svg <www-svg@w3.org>, www-style <www-style@w3.org>
On Tue, Oct 30, 2012 at 12:44 AM, Dirk Schulze <dschulze@adobe.com> wrote: > On Oct 29, 2012, at 11:35 PM, Robert O'Callahan <robert@ocallahan.org> wrote: >> 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. I agree, this sounds fine. It avoids the more complicated heuristics that roc first suggested, but still usually gets the right answer. When the handful of SVG properties on the list want to reference an SVG Stack, they can use image() to force it, and when a general CSS property wants to reference a paint server, it can use element() to force it. Let's ratify this in the SVG call this week. Hmm, I wonder where this should be defined? Image Values (as it defines <image>), or Values & Units? ~TJ
Received on Monday, 5 November 2012 23:52:35 UTC