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

Thinking about SVG and not really CSS (since I don't know how that is
supposed to preserve the semantics of SVG anyhow -- I suppose it isn't), it
seems that filling a shape with an image is not just more convenient than
using clippaths:

<someshape fill="url(image)"/>

Vs

 <clipPath id="q"><someshape/></clipPath>
<image clip-path="url(q)"/>
[exact syntax here may be screwy]

But, as argued in http://cs.sru.edu/~ddailey/svg/GeometricAccessibility.html
a pentagon filled with a picture is semantically, it seems, more likely to
be thought of as a pentagon, rather than as a picture clipped by a pentagon.
Certainly, it makes a difference what the shape is and what the picture is,
and I suppose one can argue that sometimes it really is, first and foremost
a picture, and other times, first and foremost, a shape.  For accessibility
purposes, authors  should be able to make that choice and this idea would
further that goal.

It simply makes sense, and while one might argue that SVG already has
multiple ways to do several things, many of those alternate ways are only
the same on the surface, and have different meanings.

By the same token one could fill a pentagon with a gradual blend
transitioning from one bitmap to another by overlaying one image on another
using a mask and then clipping the result via a shape. Semantically, it
might really be that the shape is pre-eminent and that allowing the stops of
a gradient to be able to be filled with images would be more semantically
accurate. While we are at it, can we have that too?

<linearGradient>
<stop offset="0" stop-color="url(image1)"/>
<stop offset="1" stop-color=" url(image2)"/>
</linearGradient>

Cheers
David

-----Original Message-----
From: Dirk Schulze [mailto:dschulze@adobe.com] 
Sent: Wednesday, January 22, 2014 4:18 AM
To: www-svg; public-fx
Subject: fill and stroke properties with CSS <image> values

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.

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

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

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.

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>

<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

Received on Thursday, 23 January 2014 14:56:56 UTC