- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 21 Nov 2012 09:34:27 -0800
- To: Philip Rogers <pdr@google.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "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, 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. 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 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. ~TJ
Received on Wednesday, 21 November 2012 17:35:18 UTC