Promoting SVG attributes to properties so that they may be animated with CSS Animations

If we take each row in the SVG 1.1 Attribute Table appendix that is marked as animatable, we start with 184 attributes. This includes separate entries for, say, width on rect to width on image, since they have different definitions in the specification. On the other hand, transform has a single definition which many other elements reference, so there is only a single row for it.

The only animatable attribute I can see we definitely want to exclude from promoting to a property is class.

Initial mapping

I'll start here with a fairly blind mapping of attributes to properties, unifying only where it is really obvious.

That is new properties.

The names I chose for properties are certainly up for discussion. I tried not to be constrained by the existing names of the SVG attributes and instead chose names that look more like real CSS properties.

Since it still seems to be open whether we want to promote the filter and gradient attributes just yet, because they will have more specialised/usable syntax in CSS, I separated them out. As Robert mentioned, though, it is prudent to look at how all of the attributes would be promoted, even if we are avoiding doing so for some of them initially.

The unifications I made in the above table are:

• Properties lighting-kernel-unit-length and lighting-surface-scale are used for the kernelUnitLength and surfaceScale attributes on both feDiffuseLighting and feSpecularLighting.
• Properties light-position-x, light-position-y and light-position-z are used for the x, y and z attributes on both feSpotLight and fePointLight.
• Properties center-x and center-y are used for attributes cx and cy on circle and ellipse.
• Properties width and height are used for many SVG elements that have width and height properties, and are also used for markerWidth and markerHeight on marker.
• Properties left and top are used for attributes x and y on elements that have x/y/width/height.
• I used properties glyph-position-x and glyph-position-y for attributes x and y on text content elements like text and tspan.
• I used properties cursor-reference-point-x and cursor-reference-point-y for attributes x and y on cursor.
• Property poly-points is used for the points attribute on polygon and polyline.

I am uneasy about promoting xlink:href and target on a to properties. Every other property is simply about the visual display of elements, but these ones affect an element's interactive behaviour. (Maybe that's OK.)

More unification

We can consider some more property unification:

• Many of the xlink:href attributes are used to reference an element of the same kind whose attributes are inherited if not specified on the referencing element. (I named those properties *-parent in the above table.) These could all use the one property.
• Elements that have a single, specified position, such as cx/cy on circle and refX/refY on marker can use the one pair of properties.
• Elements that have a start and end pair of positions, such as x1/y1/x2/y2 on line and fx/fy/cx/cy on radialGradient can use the one pair of properties.
• Various radius-related attributes can be unified.
• All of the *Units attributes can be represented with two properties, one for the coordinate space of the element's attributes and one for the element's contents.
• All of the *Transform attributes can use the transform property, too.
• xlink:href on image, feImage, use and tref all reference some content, and could use the same property.
• d on path and points on polygon & polyline all define a shape, so they could use the same property (with different syntax for point lists and path data).

Applying the above, we get the following table of attribute to property mappings:

That's now new properties, or 33 if we are only looking at the non-filter, non-gradient attributes.