Semantically order attributes by default

[Ede123]

Follow up to #59:

As already discussed there we should order attributes by default in output.
Furthermore a semantic ordering would be preferable to increase human readability.

The challenge at hand is to find a viable way to achieve a useful attribute order, even with future SVG specifications, namespaced extensions, etc. in mind.

[Ede123]

Right now I see two possible options:

1. Only care about a minimal subset of the most common attributes. Order everything else after that in alphabetical order. This will undoubtedly leave some attributes ordered in a non-optimum way but should be easier to implement and is probably more future proof.
2. Try to achieve a useful order for all attributes. This would already be pretty hard for the attributes specified in SVG 1.1 alone, however (if done right) it would be the better solution by far.

If we decide on the first option I'd suggest the following order:
id/class -> transform -> x,y,z,width,height,x1,x2,y1,y2,cx,cy,r,rx,ry,fx,fy ->d ->properties -> style -> everything else in alphabetic order

If we decide on the second option I'd follow the order in the SVG 1.1 specification (see for example the path element) with the exception to put id/class at the start. Like before everything else goes at the end in alphabetical order.

[dirk-thomas]

I think both options are actually the same to implement. I would suggest a pseudo algorithm like this:

all_attr = {...}
known_attr = ['id', 'class', 'transform', 'x', 'y', ...]
ordered_attr = OrderDict()
for a in known_attr:
    if a in all_attr:
        ordered_attr[a] = all_attr[a]
for a in sorted(all_attr.keys()):
    if a in ordered_attr:
        continue
    ordered_attr[a] = all_attr[a]

I think the important part is that the attributes have some order. Your suggested attribute order sounds good to me.

[Ede123]

I think both options are actually the same to implement

With "easier to implement" I meant that the list of known_attr would probably be much easier to maintain for option 1. In terms of code complexity it's probably about the same...

@oberstet Any thoughts from you side?

[Ede123]

@dirk-thomas - Tobias seems to be busy lately but I think this is something we definitely want (Scour messing up the order of attributes on every run was something that bugged me a lot in the past).

Is your offer to provide a PR still valid? If yes, I'd be happy to review it. As you noted implementation for the two cases I suggested should be similar and since I have no clear preference, feel free to work on whatever seems more natural to you.

[Ede123]

I just noticed --order-attributes does not work on style attributes yet (and therefore don't have reproducible output yet).
This is something we should remember to add when working on this enhancement.

[dirk-thomas]

Here we go: #105

[Ede123]

Fixed by #105. Thanks again Dirk!

Follow up (ordering of style attributes) is #106.