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

Was this ratified?

I saw a codereview for this and I am worried that property-based url()
differences are going to confuse developers. It will be non-obvious to end
users why their copy&pasted stacks url() image works differently in 'fill'
and 'background-image' contexts. I don't think SVG stacks are worth
sacrificing url() property consistency; the property-independent proposal
seems more reasonable for long-term sanity.

The spatial dimension of media fragments seems to supplant the stacks
usecase anyway. With the special '=', '(' or ')' parsing suggested by ROC,
there seems to be a path forward for media fragment sprites that works in
both CSS and SVG url() images.

Philip


On Mon, Nov 5, 2012 at 3:51 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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
>
>