Feature request: better XML editor node identification by attributes, semi-unique names ("non-unique id's") and less crowdedness

• 1) Crowdedness

When you try to find a node in the XML editor, you get to see XML per node like <svg:g id="abcdefg>. It's too crowded. What would be easier on the eye is to get rid of the markup so what remains are the crucial descriptors: namespace, element type and id, like: svg g abcdefg possibly with different colors per descriptor or some separator symbol. Maybe colors are not the right solution for visually impaired people. In any case, less crowdedness is the idea.

• 2) Choosing attributes as descriptors

It would be nice to be able to choose some other attributes to display in the XML editor like class and to turn off the namespace, element type or id. So your node is identified by: svg or svg g or abcdefg or abcdefg my_class etc. This is also linked to less crowdedness.

• 3) Semi-unique names ("non-unique id's")

(I know that this is DOM's fault, but Inkscape could fix this by auto-suffixing and information hiding or with an inkscape:name attribute: read on..). Non-unique id's is a misnomer because id's are unique by definition. A better term is semi-unique name, like a file/folder name in an OS filesystem. It is semi-unique because a folder's children must have unique names, but those children can be copied safely to another folder without name collisions in the hierarchy. Folders/files with unique names (id's) wouldn't allow you to do that, or they'd have to be renamed.

There are legit reasons to give nodes identical names in a hierarchy. Categorically it makes sense. For example, an orange and an apple both have a crust. You'd like to have a fruit hierarchy. Fruit is the parent of orange and apple, and orange and apple are children of fruit. So you have: fruit -> apple -> crust and fruit -> orange -> crust. Id collision already! Crust must be unique. Ok, so we name them crust1 and crust2, eh, right?

Issues with id's:

• it could look like you imply that oranges have two crusts (crust1, crust2).
• it could look like the orange had one crust instance in the past, and it got removed and it got a new crust (crust2).
• name collisions: it's as bad as having a global id namespace for nodes that live in the same hierarchy.

It really makes creating an application or drawing difficult. Imagine all your OS file names and folders had to be unique. You'd have to be aware of all names in the filesystem, and even worse, you'd be forced to invent unique names for every file. Then you lose a lot of value in using a hierarchy. Yikes.

Querying a node by its path is cleaner and more maintainable than to try to come up with a unique id for each node. A node's path would be a hierarchy of semi-unique names, such as fruit/apple/crust. If Inkscape were to have a node querying function, the user could use such path of semi-unique names to get the node.

Sometimes you identify a node by looking at it's rendered result (for example, an artist may look at a rectangle and immediately knows that it is a window that is part of a house) and the id/name may not be relevant. However, if you want to re-use that node in another context, or you are manually editing the XML without an XML tree viewer, the above points apply.

Solution 1

Inkscape could fix this by having an automatic suffix generation that is hidden from the user. They simply type in the id, like "crust" for the apple's crust, and inkscape adds a suffix that is invisible to the user when viewing the node in the XML editor, and when changing it's id.

Disadvantages

When using a text editor:

• the effort to manually manage suffixes
• the unease on the eye when trying to find (or remember) your correct node by wading through suffixes

Solution 2

Have a namespaced attribute on an element as a semi-unique name, for example: inkscape:name and display the value of that in the XML editor instead of an id.