Re: [Rendering Order] Some early feedback

On 2009-10-24 5:38 AM, Jeff Schiller wrote:
> hit
> Twitter yesterday so I thought I'd provide some comments:


> 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?

Hi Jeff,

That's interesting and seems plausible to me. Hmm, I'll have to think about that.

I don't mean to nit pick (since as I say the behavior you describe does seem
like something that could be useful), but a description of behavior (desired or
otherwise) isn't actually a use case. It's just a description of behavior. You
do hint at a specific use case though (something that you want to be able to use
the behavior you described for) - dragging. Could you elaborate on this? I
presume this relates to your work on SVG-Edit? It would seem a bit weird to me
for an element to pop above all others when I drag it, and then presumably drop
back down when I released it, but maybe I'm missing something.

> 4) As maybe clear from above, I'm not really convinced of a strong
> need for this.

To me the most compelling reason for z-index type functionality is to avoid the
problem of images and sub-documents (e.g. iframe in foreignObject) from having
to be reloaded due to them being removed temporarily from the DOM to reposition
them somewhere else.


Received on Monday, 26 October 2009 10:45:23 UTC