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

On Nov 21, 2012, at 9:34 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Nov 20, 2012 at 11:05 PM, Philip Rogers <pdr@google.com> wrote:
>> Was this ratified?
> 
> Pending review of WebKit's code to verify that the change isn't too
> crazy to make, yes.
> 
>> 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.

Philip is not the only developer I spoke with, which asked to unify the URL parsing and interpretation across all properties. Means a fragment in the url() function would always cause loading the reference as a document and references without fragment as image (this is one of the first proposals). And generally speaking, this could allow a bunch of possibilities in the future:

'background-image: url(resource.svg#pattern)' could allow filling the background with an SVG pattern, or could reference a SVG gradient or SVG mesh gradient. And these SVG resources could be in a different document; something that is not possible with the 'element()' function yet.

> 
> An SVG Stack doesn't work in 'fill' at all anyway.  The only property
> with an ambiguity so far is the new 'mask'.  Soonish I hope to have
> the ambiguity spread to all CSS properties that take an image, but
> they'll default to images as they currently do, so it'll be fine
> (you'll have to use element() to refer to an external resource).

The proposal above would definitely mean that fragments can not be used for SVG stacks or media fragments. Media fragments would still be supported with the image() function then. This would be against my previous wish to support SVG stacks for URLs, but it might be a consensus that we all can live with.

> 
>> 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.
> 
> Not really; at least, Stacks are an easier way to reference sprites.
> Names are always simpler than coordinates, if you can get them.

It is actually the only benefit. Creating a SVG stack is a lot more difficult, since you need to deal with different viewports to archive your goal and need to be careful to set the right class and look for the right class definitions. Creating an SVG sprite is a lot easier and their already exist tools for it. Maybe it might be ok to to kill SVG stacks for CSS. Philip convinced me on this point.

Greetings,
Dirk

> 
> ~TJ

Received on Sunday, 2 December 2012 03:22:27 UTC