W3C home > Mailing lists > Public > www-svg@w3.org > October 2009

Re: [Rendering Order] Some early feedback

From: Doug Schepers <schepers@w3.org>
Date: Sat, 24 Oct 2009 00:45:47 -0400
Message-ID: <4AE2867B.5090605@w3.org>
To: www-svg <www-svg@w3.org>
Hi, Jeff-

Jeff Schiller wrote (on 10/23/09 11:38 PM):
> http://dev.w3.org/SVG/modules/renderorder/SVGRenderOrder.html hit
> Twitter yesterday so I thought I'd provide some comments:

Jiminy Xmas, slow down, Turbo!


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

No, because it doesn't exist yet. :)


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

That's a good use case, thanks.

We have just started formally talking about this, and there is at least 
one and possibly 2 more proposals yet to come, and that's just from 
within the SVG WG.  So, review of this particular draft is exceptionally 
premature.  However, it is good to have use cases, so feel free to 
elaborate more on that topic.


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

JWatt experienced this firsthand with his coverflow demo (which he 
showed at SVG Open 2009)... when you remove and reinsert an element that 
has dynamic content, it restarts the animation/reloads the external 
resource/sucks.


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

One use case I see is being able to structure a document according to a 
different logical order than it is to be presented, which is actually a 
case I've run into quite a lot.


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

Yes, that's why I mentioned it in the spec... this was a proposal by 
Andrew Emmons (who had experience implementing this feature for a 
client), but I was the one who drew it up in spec format, and I added a 
few cursory notes).

Even if the underlying models are slightly or somewhat different for SVG 
than for HTML+CSS, I see value in exposing it to the author as the same 
property name, with which they may already be familiar; if the 
underlying models or restrictions are sufficiently different, then a 
different name might be better, since it would then clarify, rather than 
cause, any confusion.

We will elaborate significantly in future drafts on why z-index, as 
specified in CSS, may not be suitable for SVG (or we will change our 
minds about that, but I've heard some compelling explanations that I 
don't recall at the moment).

Either way, we will coordinate with the CSS WG on this.


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

No, the editor for that specification has retreated to his hidden island 
laboratory under the Earth to plot his nefarious deeds.  Rumors persist 
that his vile experiments are directly related to that specification, 
and one presumes he will unveil his master plan when the stars are aligned.


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Saturday, 24 October 2009 04:45:52 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT