Repository navigation
Result for a value of zero for pathLength is undefined #81
Description
The pathLength attribute description states that a negative value is an error, but does not give guidance on what to do with a value of zero.
https://svgwg.org/svg2-draft/paths.html#PathLengthAttribute
A value of zero should probably be an error too since the user agent scales all distance computations by the ratio of pathLength to the user agent's own calculated length.
A value of zero for pathLength would result in a ratio of zero (pathLength / calculated length).
According to my test, implementations handle a pathLength of zero differently.
FireFox = handles as an error (ignores, gives the same result as when a negative value is used)
Chrome = disables dash array
Safari = doesn't support pathLength (at least on dasharray)
InkScape = doesn't support pathLength (at least on dasharray)
Activity
BigBadaboom commentedon Apr 11, 2016
Mostly the ratio will be used the other way around won't it? Because you will be doing:
Making 0 an error would prevent anyone from animating from n->0 or 0->n. But I'm not sure if those are even useful use cases worth protecting. And I can't think of any sensible way of defining how pathLength=0 should be treated, other than by saying that any value affected by pathLength calculations should be treated as +Infinity (or +NumberMax).
fsoder commentedon Apr 11, 2016
For pathLength=0, "Chrome" (Blink) computes a 'scale' [1] of 0, hence giving as the result a degenerate dash array, which turn results in no dash array.
[1] Loosely based on the computation of 'scale' here (I think): https://svgwg.org/svg2-draft/painting.html#StrokeShape - although arguably that's the inverse of what we actually use. Using +Infinity would however give the same visual result.
[2] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/svg/SVGPathElement.cpp&q=pathLengthScaleFactor&sq=package:chromium&type=cs&l=84 is the method that computes the 'scale' that's used.
[3] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/svg/stroke/pathlength-explicit-zero.html is our test for this case (*-expected.html being the reference)
AmeliaBR commentedon Apr 12, 2016
A declared path length of 0 is illogical if the actual length of the path is non-zero. However, since a path can be zero-length (and can have a line-cap stroke if it is), it makes sense that the
pathLengthattribute can also have a value of 0.Therefore, the main use case we need to address for this is when the computed path is almost-zero and the declared pathLength is exactly 0. It could happen because of rounding errors in an editor or script. I'm not worried if the results look weird when an author gives
pathLength="0"on a longer path.For that use case, the approach described by @fsoder (compute & propagate the infinite scaling factor, and then address it in error handling for the scaled properties) seems no better or worse than ignoring the pathLength factor altogether. However, it has the benefit of offering a continuous behavior as the pathLength approaches 0. As @BigBadaboom notes, pathLength is currently marked animatable, so this would be preferable.
More drastic would be to force the browser to actually render it as a zero-length path, thereby reflecting the original purpose of this attribute. This could create animation discontinuities, although they would be small if the author was using pathLength as intended, and only animating it down to 0 in conjunction with animating the path down to (almost) zero length.
nikosandronikos commentedon Apr 13, 2016
Agree that for dashes it makes most sense that the result should look like no dash array is applied.
For a dash pattern of "1 1" as well as "0 1", it seems somewhat logical that the on dash would fill the length of the stroke.
Also agree that dealing with this individually for each scaled property is probably a good idea.
The only other place that pathLength makes a difference at the moment is for positioned markers (I think).
In this case, given a resulting scale factor of zero, all markers would be at the start of the path.
Whereas, If a pathLength of zero is given and marker position > 0, I would expect the marker to be on the far end of the path.
AmeliaBR commentedon Apr 22, 2016
RESOLUTION: if the author gives a pathLength of zero to a path that has non zero actual length, we have a theoretical scaling factor of infinity. With this infinity factor, anything positioned at zero stays at zero; anything anywhere else gets clamped to the max possible value.
Amelia adds: (or minimum negative possible value)
Implementations can either run a specific test for pathLength=0 or preserve the calculation for infinity and test for final values of infinity, -infinity, and NaN (=0*infinity).
Bug 1815061 - Fix handling of startOffset and stroke-dasharray when t…
Bug 1815061 - Fix handling of startOffset and stroke-dasharray when t…