[Transforms] specification feedback

Esteemed experts,

I'd like to make some comments on the "SVG Transforms 1.0, Part 2: 
Language" document, draft dated 11 March 2009:

1. Section 2: The references to 'Z position' confound me. Does that mean
     that specifying z-order by a proper Z co-ordinate rather than an
     index is on the cards? I would argue strongly in favour of doing so.
     An index serves no purpose except ordering, but a *position* can
     be used for all kinds of purposes (as I was attempting to argue in my
     previous email).

    Also, since transforms will use proper Z positions, to use artificial
     integers for z-ordering (rather than positions) would introduce an
     inconsistency. And every inconsistency makes something harder to learn.

2. Section 2: I see no need for special elements (layeredG or g3d).

3. Sections 2.1, 2.2: I'm confused when you refer to 'properties'. Are
     'transform-origin' and 'perspective' intended to be defined in the 'style'
     attribute (or from a style sheet)? If so, that doesn't seem natural to
     me: these aren't style-related at all.

4. Section 2.1: Whenever I see a property or attribute that contains
     multiple values, I ask myself whether it could be achieved another
     way. Multi-values are a pain to animate. In the case of 
'transform-origin',
     if this were an attribute, its value could be a property list
     (eg. transform-origin="ox:0; oy:100; oz=50"). If <animate> and
     <set> were made a little more intelligent, it would be easy to
     animate a single value within a property list for any attribute.

5. Section 2.1: Naming things 'o' is to be avoided whenever possible,
     because of possible confusion with '0' (that's a zero), especially
     things with numeric values. Can't you use another letter? Why not
     call these plain x, y and z?

6. Section 3: I think you should maintain more backward compatibility.
     Can't you maintain *complete* backward compatibility if you:

     (a) Introduce rotate3D() for 3D rotations, and keep rotate() as
          it is (for 2D rotations).

     (b) Make the <cz> values optional in rotateX() and rotateZ().

    Since the bulk of SVG documents are purely 2D, you shouldn't impose
     a burden on their authors for 3D features that they don't want to
     use. So in addition to backward compatibility you shouldn't force
     authors of 2D documents to do more work (supply more values).

7. General: I don't like matrices, and I daresay the vast majority of
     SVG document authors don't either. You should make it as intuitive
     as possible for a non-techo to specify rotations in 3D - especially
     about a horizontal or vertical axis.

8. General: Following on from point 7, this specification is crying out
     for some examples. Devise what you consider to be a range of common
     cases and show the sources of the elements that implement them.
     Until you do that it won't be possible for a reader (reviewer)
     to judge how easy this stuff will be to write.

Now a few things that go beyond the scope of this specification:

9. This specification addresses just the transform extensions
     themselves. By implication that means it affects just graphical
     elements. But that need not be so. The case that interests me
     is <animateMotion> along a path 'tilted' in three dimensions, which
     I think can be achieved straightforwardly (famous last words!).
     Your perspective stuff is able to define the tilt. For example, you
     could have collection of objects 'orbit' together in a horizontal
     plane. I hasten to add that the path itself will still be defined
     in 2D.

10. Also on a wider note, I'd prefer to be able to express 3D effects
      in terms of what I want to achieve, rather than having to calculate
      all the details and then express them in terms of transforms
      (which are, let's face it, an unintuitive implementation contrivance
      when you go beyond the trivial). That is, I'd like the software do
      the tedious calculation of perspectives, say to align graphical
      elements relative to a virtual horizon.

11. Another feature that could be added is adjusting the rendered size
      of elements according to their z positions - so as an animation
      moves an element 'outwards' it appears to get bigger. Again, this
      should be done without the document author having to do the hard work.

Regards, Steve.

Received on Monday, 16 November 2009 08:54:59 UTC