Re: Allow getTotalLength() and getPointAtLength() for <circle>, <rect> etc

+1  to that idea.  I had been thinking about this myself just last week.

I don't see a problem with allowing the same methods for text elements,
since they too can be stroked and the Working Group has already agreed to
implement a text-to-path method.  At worst, an implementation would have to
run their text-to-path method, then run the length computations.  The
generic getTotalLength() name might be a little confusing for text
elements, but there is already the getComputedTextLength() and other
methods for text length in the normal sense.

On that note, I don't think the text-to-path method has been specifically
defined yet.  It could also be defined as a generic method on the
SVGGeometryElement interface, so that shapes could also be converted to
paths easily.  If it was called getNormalizedPath(), the method could also
replace the live-updating normalized path properties on path elements,
which browsers never implemented because of performance issues.  It could
maybe be  getNormalizedPath(boolean animated) to flag whether you wanted to
convert the current animated state of the path, text, or shape versus the
base state.

Sorry, that was a bit of a tangent:  On Paul's main idea, I say: sounds
great!

ABR

On 28 April 2015 at 00:17, Paul LeBeau <paul.lebeau@gmail.com> wrote:

> Hi all
>
> Given that we are now defining a "start point" for dashing for elements
> other than path (circle, rect, etc).  Would it not now also make sense to
> allow getTotalLength() and getPointAtLength() for these elements?
>
> Among other things, it would be useful for people who want to use the
> dasharray trick to animate the line drawing of shapes other than paths.
>
> Moving these methods to the SVGGeometryElement interface might be
> appropriate. However that is complicated by the fact that
> SVGGeometryElement also covers text elements.  Perhaps, in the case of
> text, the "length" might refer to the text baseline?
>
> Paul
>
>