Svg.js: Only a few properties are documented for [TextPath](http://svgjs.com/elements/textpath/).

[wout]

Missing: dom, node, x, y, cx, cy, text, size, leading, lines, rebuild, build, setData, plain, tspan, clear and length.

Better doc for: font

[wout]

@dotnetCarpenter
Since SVG.TextPath is inheriting from SVG.Text, those methods are implied. I added a small note about it in the new version, which I will push later today.

What do you suggest for the font() method?

[RmiTtro]

Maybe we could say that it provide an easy way to set the font properties and then link to this page in the svg spec.

[dotnetCarpenter]

When I browse the docs, I expect to see which methods and properties a
class has. I think that making people click around multiple pages to get
the information is bad UX.

For the font, it is only mention in the example. I think it should have a
prominent place like the rest of the methods.

On Wed, Feb 22, 2017 at 8:43 PM, Rémi Tétreault [e-mail]
wrote:

Maybe we could say that it provide an easy way to set the font properties
and then link to this page
https://www.w3.org/TR/SVG/text.html#FontPropertiesUsedBySVG in the svg
spec.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/svgdotjs/svg.js/issues/600#issuecomment-281780389,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACq82ohigyobTAMdoObUM3b62KXgLfJks5rfI_wgaJpZM4MJEX6
.

[RmiTtro]

Well the reason I thought it was good to reference the svg spec here is because the font method exist just to make it easier to set SVG attributes relating to fonts. Basically text.font({family: 'Helvetica'}) is the same thing as doing this: text.attr({font-family: 'Helvetica'}).

To rephrase, the font method is a part of SVG.js while the attributes it allow to set are a part of the SVG spec.

Anyway, that is what I think but I might be biased since I like to keep things simple :laughing: .

[dotnetCarpenter]

@RmiTtro Sorry, it was not a remark to have a link to specs. I think that is a good idea. Without knowing SVG, SVG.js is hard to use.

My remark was to the documentation in general. The more information we can show about a class, without requiring the user to read other pages, the better. I usually have 3 taps open when I browse the docs, which probably mean, that we should consider whether or not our information level on each page is high enough.

In an ideal world, I would get all the information about TextPath's methods and properties from the TextPath page. Currently, I tend to use the devtool debugger to get that information.

[wout]

I've been thinking about further flattening the structure of the docs. For example, have all element pages merged into one large page with anchor links in the menu, just like it's done with the referencing page for example.

[wout]

Font method has been described in more detail:
http://svgjs.com/elements/text/#font

TextPath moved to the Text page, so all the methods are available on the same page for both elements. It does, however, retain a link in the menu:
http://svgjs.com/elements/text/#textpath

[dotnetCarpenter]

Haha enter the dragon :)

Look very good to me.

I think we should take the overall documentation (single page) discussion on slack.

[dotnetCarpenter]

Oops, setData doesn't seem to be documented but appears in devtools for a TextPath.

[Fuzzyma]

setData is a member of SVG.Element and is again an internal method which is not public api

[RmiTtro]

Really nice what you did with the docs!!

[dotnetCarpenter]

@Fuzzyma We should mark internal methods with a prefix e.i. _setData() or people will start to use them.

[Fuzzyma]

@dotnetCarpenter imo people should only use documented methods ;). But I guess you are right

[wout]

I agree on the prefix.