RE: Does PATH need a new attribute?

I like this solution, as it does address the more generalized problem of changing more of the stroke attributes on an edge-segment by edge-segment basis.

What would we need to do to move this concept along?  Come up with a proposed superpath syntax, and then cajole a browser provider to test-implement?

Thomas

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com]
Sent: Thursday, April 16, 2015 17:36
To: www-svg
Cc: Smailus, Thomas O
Subject: Re: Does PATH need a new attribute?

To focus on the core issue (and not the specific example Thomas provided), the question really comes down to:

Can we make it possible in SVG to create stroke effects that apply to only certain segments in a complex shape?

In CGM, as I understand it, this particular on/off stroking effect is included within the basic path geometry instructions.  However, there are many more general cases as well.  In data viz/d3, we often get people asking if it is possible to color one section of a polyline-type path differently than the others.

The solution that currently exists is the same solution that Thomas is using for his CGM conversions: create two (or more) paths, one to draw the fill, and the other(s) to draw the line segments.  But as Thomas pointed out, that loses the "connectedness" of the strokes, which can have effects e.g. in linejoins.

I'm somewhat concerned about the idea of mixing stroking instructions in with path data because it muddles up geometry and painting styles.

In my mind, the best approach--in the sense of most generalizable--would be to use the "superpath" idea, where you could construct a single filled shape as the concatenation of multiple segments.  Fill styles would apply to the entire shape, but stroke styles (including stroke: none) could apply to subpaths.  (We'd probably be able to poach a lot of the CSS border style rules for defining how to connect two stroke segments with different styles.)

I confess I haven't had a chance to look through the various proposals for superpath-type elements carefully, so I don't know if any of them currently include the option of styling the strokes on subpaths individually.  But, I don't expect that it would be a major conflict to try to integrate the idea.  After all, since stroke styles are inherited, you would always be able to stroke the entire superpath shape as normal just by setting the stroke styles on it and not on the subpaths.

AmeliaBR