- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sat, 24 Oct 2009 14:21:53 +0200
- To: www-svg@w3.org
Hmmm, a nasty author can simply put a g-element around any element to be able to reorder all rendered elements. This mainly blows up the source code and shows that this approach does not prevent authors using it in a way, hard to interprete by a viewer ;o) On the other hand, one can do this right now with SVG1.1 with a simple trick, if things are predictable and simple enough: Just put all g-groups (or elements) in the defs element and reference them with use elements. Then animate the xlink:href of the use elements to get the intended rendering order ;o) My use case: Consider a planet moving around a sun (sideview). Sometimes the planet is in front of the sun, sometimes behind. One has to change the rendering order in a time dependent way. Currently I do this with the trick mentioned above (or with two planets, one behind and one in front and some display:none sometimes for the front one). Of course this can get more complex in a complete planetary system with several planets and maybe moons, especially because this has typically no short periodicity, required for a simple declarative animation as available with SVG1.1. If as proposed render-order is animatable, one can simply map the distance in the direction perpendicular to the canvas into render-order numbers and animate render-order with these values - this solves the problem of the complex planetary system without short periodicity and looks already pretty useful (for other applications with not simply predictable changes of the render-order too, of course). Therefore it could be even more convenient to allow floating point numbers instead just integers. This saves some computing efforts to transform the coordinate into a large integer. As far as I understand the example, the g with a largest render-order is on top - as far as I have seen, this is not formally defined, should be done of course ;o) Should be noted too, what happens, if two g elements have the same render-order. I assume, that the last in the source code is on top. If referenced with use - this property is inherited I assume, if the referenced g does not have its own render-order specified? Because the use is formally replaced with a g in the generated content, is it ok for such cases to put the render-order in the g as well and does it apply to the generated-g? For the use case above, it could be more useful of course to be able to combine this approach the 3D-transfrom proposal to use the z-axis (after transformation) somehow for the render-order. Then one could maybe think of a space-ship moving around the system, changing the 'render-order-axis' as well ;o) Olaf
Received on Saturday, 24 October 2009 12:53:00 UTC