- From: Jeff Schiller <codedread@gmail.com>
- Date: Fri, 23 Oct 2009 22:38:26 -0500
- To: www-svg <www-svg@w3.org>
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