W3C home > Mailing lists > Public > www-svg@w3.org > January 2014

Re: fill and stroke properties with CSS <image> values

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 23 Jan 2014 13:03:51 +0000
To: Erik Dahlström <ed@opera.com>
CC: Jeremie Patonnier <jeremie.patonnier@gmail.com>, Tab Atkins Jr. <jackalmage@gmail.com>, www-svg <www-svg@w3.org>, public-fx <public-fx@w3.org>
Message-ID: <FDBCEA04-B41F-4DC9-9AC3-B828B65B49CE@adobe.com>

On Jan 23, 2014, at 1:02 PM, Erik Dahlström <ed@opera.com> wrote:

> On Thu, 23 Jan 2014 11:45:03 +0100, Jeremie Patonnier <jeremie.patonnier@gmail.com> wrote:
>> Hi!
>> 2014/1/23 Erik Dahlström <ed@opera.com>
>>> I'm wondering how much of a need there really is to have the fallback
>>> color in the first place, maybe this is something we should revisit?
>> Let's imagine the following use case:
>>   1. You have an SVG image with a white background
>>   2. I have a rect fill with a dark image (fill: url("stuff.png"))
>>   3. I write some text on top of the rect which color is white
>>   4. If for some reason the image is not loading, the text become not
>>   visible (white text on a white background)
>> Having a fallback color (let's say black) is a safety for such cases.
> My next sentence was: "There might be a better alternative".
> In other words, what if there was another way to address this use-case? Why would it necessarily have to use the current syntax?

Beside that… The HMTL world managed to deal with this situation without a fallback color for more than a decade now. HTML has much more likely content that would be affected than SVG.

That said, Tab mentioned that there is a way to fill a layer with a color: image(<color>). Therefore, keeping the last color value as fallback might not be a big deal anyway. I personally have no strong opinion the one or the other way.


>> Another case is if you want to have an image that fade to a colored
>> background. In such case, it's better to fill with an image as small as
>> possible and fill the blank with the appropriate color instead of having a
>> large image mostly full of a plain color. This is more efficient in term of
>> network performance (we load a smaller resource) and rendering performance
>> (the color can be paint immediately, even if the image take some time to
>> load).
> I don't understand the point you're trying to make, why wouldn't this also be true for an alternative?
> Multiple paints, e.g "fill: url(foo), url(bar)", is in the SVG2 spec already (currently just as an example, the <paint> grammar doesn't yet cover this), but the WG has resolved to have this feature[1]. I guess it still remains to be decided, but I would not expect rendering to stall just because all of the paints weren't fully loaded. Draw what there is, and update as needed.
> I would imagine your example being e.g "fill: url(foo.png), green" or perhaps "fill: url(bar.png), image(yellow)".
> [1] http://www.w3.org/2013/06/03-svg-minutes.html#item10
> -- 
> Erik Dahlstrom, Web Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
Received on Thursday, 23 January 2014 13:04:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:50 UTC