Proposals/Vector effects
New values for paint
Vector effects proposes a way to access the fill and stroke of elements (for example, to make the fill on markers be the same paint as the stroke on the path where the markers are used). While this concept started with vector effects, I believe that its should be generalised and made available throughout SVG2.
Also, SVG 1.1 describes in prose how property inheritance can come from the place of use, rather than the position in the tree where the element is defined. I think this could be generalised too.
Currently we have (in SVG 1.1 and 1.2T):
- currentColor
The animated value of the color property at this point in the tree (onDefine)
I propose expanding this to six values, three for the current positon in the tree and three for the values on use. In each case its the animated value that is used.
- currentColor
- currentFillPaint
- currentStrokePaint
- useColor
- useFillPaint
- useStrokePaint
So for example one could say <marker fill="useStrokePaint" ... />.
Resolved in favor at 29 July 2011 telcon
Resolved to change use* to context* at 18 Sept 2012 f2f
See ACTION-3364 Chris Lilley to write up contextFill(Paint), contextStroke(Paint) proposal in coordination with Cameron
Constructive geometry
The main expressive value of the vector effects specification is the constructive geometry - union and intersection of paths to create new, derived paths. Other functionality like stroke to path,altering the order of fill and stroke, or creating multiple copies of strokes is handy, but mainly as an input to the constructive geometry operations.
There is a concern that the union and intersection operations may be performance intensive, and the exact generated path is underspecified which makes it hard to subsequently animate (given the current restriction on animating paths in terms of matching number and type of nodes). On the other hand, this is a common operation in 3D graphics and 2D graphics could benefit from the same expressive power.
I would like to see discussion and agreement on either moving forward with specifying and test implementing union and intersection (perhaps with a restriction on animation), or dropping it (and then finding some other way to alter fill/stroke order, get multiple strokes, etc).
Resolved in favor at 29 July 2011 telcon