I know we're arguing for the same side. Just getting there from a different place.
On Tue, 2012-12-04 at 00:31 +0100, Johan Engelen wrote:
I don't know what you mean by a canvas element.
paths, circles, squares are all canvas elements. They are a) xml elements and b) on the canvas/page as things.
A path is a rendered object in final output. An anchor point is something that should not be rendered (right?),
Not really. Anchor points can be rendered, or not rendered. Much like a line can be visible... or not visible. I think that was the point of the markers in the spec.
and is more something like the rotation center of a group. The rotation center of a group is what I also call a canvas element, as is the flashing helper path, etc. The rotation center is not stored as an svg:path because that would make no sense.
Well yes, because a center is an attribute of an element, while a point is an element in and of itself. It's a different kind of shape which can be optionally grouped with other shapes to provide the needed concept.
These are not reasons to use single point paths for anchor points; as you propose you could use <point..>. These two points are reasons supporting changing the "<p.." into something else. The spec will most certainly not use svg:path for the anchor points.
Which is a shame ;-) but I'm just hoping the spec will be more generic than the draft published so far.
So what happens when I ungroup the group with your anchor-point-paths in it? Going to special-case that, or "neatly" add the anchor points to the parent group?
No, having free floating points is a feature. Points don't have to be in groups, part of their charm is that they could be free floating.
What if someone fixes applying markers to a group of paths (does not work at the moment), going to special-case that too?
No, that would be a feature... might possibly have to think about the spec with the direction though.
Paths are selectable too, what if someone goes into the group, selects part of it by dragging a selection box and unavoidably selects an anchor point and runs some extension on it... ?
Awesome things will happen. These point shapes are not meant to be hidden from the user, nor is their nature. Selecting them should be possible.
Defining anchor points as paths is buggy... which isn't necessary. Avoid.
It's not distinctive, but it isn't as buggy as it appears.
Surely it can't be messy if one calls an anchor point an "anchor point" in SVG?
Not at all; names is names. I'm more keenly interested in the idea the point should be a shape rather than any attribute.
As I wrote earlier, single point paths do have a use.
What use?
Except that the "existing points" (paths, really) are rendered objects, and hence unsuitable for anchor points.
Both are rendered objects, usefully so.
Great that you found a resulting bug yourself. Yes it is a feature if the node tool can edit the anchor points, but it should not treat them as path points and there would not be a way to tell the difference if you define anchor points as single-point paths.
That's a valid destinction point. Perhaps inheriting path code to produce the desired function with a new point element to avoid confusion in editing nodes.
Martin,