Allow stroke-dasharray/dashoffset % to be specified relative to path length

[AmeliaBR]

This is a frequent author request, and is much simpler than the full set of stroke-dashing options proposed in the SVG Strokes module. I'd like to get it into SVG 2.

Simple backwards & forewards compatible syntax is to add an optional path keyword at the beginning or end of either property's value grammar. In future, we can still add segment-relative dashing or space/round keywords to adjust dash length to fit. I was going to suggest segment-relative percentages as well, but that gets into the messy issue of how to restart the dash pattern for each segment, which was a problem for implementations that use underlying libraries without that feature.

Path-length relative percentages are a simple implementation, in contrast: just need to calculate total path length and use that to resolve the author-specified values into absolute used lengths.

[BigBadaboom]

Possible alternatives:

1. stroke-dashunits="pathLength"
2. stroke-dasharray="0.5pl 0.5pl"

[tabatkins]

New units are much better than context switches, yes.

[nikosandronikos]

stroke-dasharray="0.5pl 0.5pl"

I like that. Could we add pl to CSS Units? Then the already specified length would just work.

[BigBadaboom]

It just occurred to me that it might be better as:

stroke-dasharray="50pl 50pl"

Ie. as a percent value. The numbers are easier to read and it has a precedent in vw/vh.

[tabatkins]

Yeah, standard approach for "percent-like" units is to make 100 of them equal the desired length; that's what the viewport units do already.

I'll open an issue on CSS for a pl unit.

[AmeliaBR]

Adding a new unit does not allow extension to segment-based dashing, as part of a more complex SVG Strokes proposal.

(The segment vs path switch doesn't seem to be in the current draft, but I know we'd discussed it. Or maybe we'd only discussed it for markers, but I'd like to have it for both.)

I also just find new acronyms horribly obscure, while stroke-dasharray: 5% 5% path; seems pretty self-explanatory.

[tabatkins]

I don't understand. What part of a new unit doesn't allow that, that a % with a switch does?

[AmeliaBR]

@tabatkins It doesn't prohibit it. We'd just need another new unit, which seems a lot more complicated than a new keyword.

More generally: units are defined globally. What would 5pl mean anywhere other than in a stroke dashing property?

[nikosandronikos]

@AmeliaBR Do you actually mean segment-based, or subpath-based?
Both would probably be interesting.

[AmeliaBR]

@nikosandronikos I mean segment-based (e.g., sides of a polygon). But sub-path is another use case that it would be nice to include. Again, easier to add that in with a keyword than another unit.

[AmeliaBR]

Since there wasn't a clear consensus on syntax, I'm removing the milestone & leaving this as a new feature for the SVG Strokes module. Don't want to lock in to a sub-optimal syntax without thinking it through.

[Tavmjong]

I still believe the best solution is to redefine % as relative to path length. This is consistent with how the attribute 'startOffset' is defined. The amount of content this would break must be insignificant compared (next to zero as the current definition is essentially useless) to what we are breaking with other changes. Introducing a new keyword or unit seems to be overkill.

[AmeliaBR]

I'm not sure how insignificant it would be. There are some cases where you do want to set stroke-width as a percentage length. In that case, you would need to set stroke-dashes using percentage lengths in order to have the dash length scale proportionally to its width.

E.g., Kevin Mark's sparklines library uses percentages in stroke width to keep a reasonable stroke width for the size of the chart even though the viewBox & coordinates are scaled to the data.

The use case may be small compared to the path-drawing-dashes effect, but it's realistic enough not to want to break it.

[AmeliaBR]

From a test by Ana Tudor I am reminded that the default behavior in all major browsers is to re-start stroke dash patterns for each sub-path, not to continue them for the entire path. So that would be another aspect that it would be nice to control with extra keywords.