[Rendering Order] Some early feedback

http://dev.w3.org/SVG/modules/renderorder/SVGRenderOrder.html hit
Twitter yesterday so I thought I'd provide some comments:

1) Can you provide a correct link for the primer?

2) One of the use cases often seen with a desire of re-ordering is to
take some arbitrary element somewhere in the DOM and draw it on top or
move it to the back of all drawn elements (dragging, for instance).
Often this element could be nested arbitrarily deep within a group
hierarchy.  The way I understand this spec is that only the direct
children of a <g> can have render-order and that only affects the
rendering order _within that g_.  This would fail to address the use
case of an arbitrarily nested element somewhere in the DOM and seem to
limit its functionality.  Does this spec truly address the reasons
people think they want z-index in SVG?  Can you clarify the use cases
that the spec is trying to solve with some examples maybe?

3) "This has performance implications and adds complexity to content
creation. It is also unsuitable for many effects, such as animation"

It's not immediately clear to me why there would be performance
implications i.e. is there a reason that browsers can't optimize an
insertBefore() that happens to be a 'move' such that the performance
cost would be the same as changing the value of the render-order
property?  Perhaps there are DOM events that have to get sent out in
the insertBefor() case?

Can you also provide a complete description why insertBefore() doesn't
work for these cases?  i.e. why is it unsuitable for animation?

4) As maybe clear from above, I'm not really convinced of a strong
need for this.  If we have to go down this route, it seems like
sharing properties with CSS would make sense, so I'm even less
convinced of a need for a new property.  As you mention in the spec,
please provide sufficient background to explain why the z-index
property is not suitable.

5) Trying to think if this has any impact on other modules being put
forth by the SVG WG.  Layout springs to mind as one that might have
some overlap but I don't think any spec has been released for this
yet, correct?

Regards,
Jeff Schiller

Received on Saturday, 24 October 2009 03:38:58 UTC