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

On Wed, 22 Jan 2014 10:18:01 +0100, Dirk Schulze <dschulze@adobe.com>  
wrote:

> Hi,
>
> I would like to follow up on a discussion we had in the SVG WG about  
> adding <image>[1] as value for ‘fill’ and ‘stroke’.
>
> This becomes more relevant now because first implementations are  
> experimenting with it. (Erik has a prototype for Blink, I was recently  
> looking at it for WebKit.)
>
> The problem that came up before is the reference box used for <image>.  
> While it makes sense to use objectBoundingBox for ‘fill’ it looks a bit  
> more pleasant to use strokeBBox for the ’stroke’ property.

Agreed.

> However, pixel images already have a specific size. Iit can be hard to  
> align images/gradients between fill and stroke though, since the origin  
> differs. (Imagine you use and image for the ‘stroke’ and the same image  
> but with saturate on the ‘fill’ but want both be aligned and sized the  
> same.)

It's more intuitive to let the default be that the boxes used for  
computing the gradient differ for fill and stroke (oBB for fill, strokeBB  
for stroke). Allowing the author to opt-in to using another box for the  
computation is fine with me, but I think it will be less common to want to  
do so.

> Additionally, it was not clear what happens with images that do not fill  
> the whole area. Do we repeat the image? Will the area around the image  
> be transparent (black)?

Ideally this should be subject to author control. My first instinct for a  
default would be not to tile the image, and to render as transparent if  
there's no gradient/image content for a part of the fill/stroke.

> Tab came up with a solution that is rather drastic. He suggested to use  
> the syntax of ‘background’ [2] to allow users to specify origin,  
> clipping, repeat and size of image values. I was skeptical at the time  
> if the increase of complexity to the syntax is worth it.

It might mean less duplication of code as SVG could hopefully then just  
reuse the same parsers and representation as for the background property.  
It should also make things slightly more consistent between svg and css,  
e.g people could expect that things that work in background immidiately  
also works the same in svg's fill/stroke.

> Since the CSS WG agreed to use ‘fill’ and ’stroke’ on text (for all  
> markup languages including HTML), there might be a more web authors who  
> would really like to have the same capabilities as background. Even  
> attached images are a common use case where people use  
> -webkit-background-clip: text; at the moment to archive it.
>
> Therefore, I suggest to use the following syntax for <image> and  
> possibly paint servers as well:
>
> fill/stroke = <final-bg-layer> | <the-rest>
> <final-bg-layer> = <image> || <position> [ / <bg-size> ]? ||  
> <repeat-style> || <attachment> || <box>{1,2} || <color>

The grammar would require some more thought. "none" is part of the syntax  
in more than one place, and how icccolor is to be meshed into this isn't  
clear. Also, there's a requirement listed for having multiple paints, so  
it would be more natural to use the same syntax as for background:

   fill/stroke =[ <bg-layer> , ]* <final-bg-layer> | <the-rest>.

> <box> at the moment consists of content-box, padding-box and border-box.  
> I would suggest to use the same keywords as for clip-path[3]. Note: The  
> discussion about the box values is still ongoing and might change.  
> Therefore, we should keep fill and stroke in mind.
>
> Greetings,
> Dirk
>
> [1] http://dev.w3.org/csswg/css-images-3/#image-values
> [2] http://www.w3.org/TR/css3-background/#ltfinal-bg-layergt
> [3] http://dev.w3.org/fxtf/css-masking-1/#the-clip-path


-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

Received on Wednesday, 22 January 2014 10:21:06 UTC