[Rendering Order] Some early feedback

[Jeff Schiller]

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

[Doug Schepers-3]

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

[Dr. Olaf Hoffmann]

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

[Ruud Steltenpool ( http://svg.startpagina.nl )]

-having z-indexes breaks the clean readability of SVG content
-it also introduces the problems we had when we still had line numbers
in programming languages instead of in (their) editors:  when you want
to insert something in between 1 and 2, you need to either:
    =renumber at least one, maybe thousands
    =use fractional numbers (where rounding errors can introduce
surprises, next to even worse (less quick) readability)

[Jonathan Watt-3]

On 2009-10-24 5:38 AM, Jeff Schiller wrote:
> http://dev.w3.org/SVG/modules/renderorder/SVGRenderOrder.html hit
> Twitter yesterday so I thought I'd provide some comments:

[snip]

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

Jonathan

[Jonathan Watt-3]

On 2009-10-24 6:45 AM, Doug Schepers wrote:

> Jeff Schiller wrote (on 10/23/09 11:38 PM):
>> 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.

For those not in the loop that means he's off finishing his PhD on the topic. ;-)

[Jonathan Watt-3]

On 2009-10-24 2:21 PM, Dr. Olaf Hoffmann wrote:

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

I think the SVG 1.1 text is poorly worded in this regard. In reality the <use>
is still in the DOM, and the render-order property would still apply to it.
Maybe it would be better to say something like "treated as a 'g'" rather than
"replaced by 'g'". The WG should think about this.

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

"3D" transforms are just an affect that changes an elements appearance as if it
was being transformed in 3D, but they actually have no affect on its "depth" or
rendering order. Only 'render-order'/'z-index' would. Maybe someone can come up
with a fantastic, relatively easy to grasp proposal on how to change that, but I
seriously doubt it. If you want real 3D as opposed to pseudo 3D, then probably
its better to use something like WebGL (possibly using it to render SVG into
planes that can then be manipulated in true 3D).

Jonathan

[Jonathan Watt-3]

On 2009-10-26 4:21 AM, Ruud Steltenpool wrote:
> -having z-indexes breaks the clean readability of SVG content

Yes, it means that you have to be aware of reordering, but it also solves real
problems. I think it's more of an escape hatch than a tool that will be used
extensively throughout documents and make them completely unreadable. Besides,
an author can choose whether the "unreadability" is an acceptable cost in order
to solve their problem.

> -it also introduces the problems we had when we still had line numbers
> in programming languages instead of in (their) editors:  when you want
> to insert something in between 1 and 2, you need to either:
>     =renumber at least one, maybe thousands
>     =use fractional numbers (where rounding errors can introduce
> surprises, next to even worse (less quick) readability)

Having to leave calculated gaps between indexes or else completely re-index when
you need to insert a new z-indexed element between existing z-indexed elements
isn't great I agree, but it's a lot more easily scripted around than manual
renumbering of line numbers. To eliminate the problem completely I think someone
would need to come up with some sort of solution that would look quite different
to 'render-order'/'z-index'. I haven't come up with anything that isn't
completely lame and doesn't have worse issues.

Jonathan

[Dr. Olaf Hoffmann]

Ruud Steltenpool:
>-having z-indexes breaks the clean readability of SVG content
>-it also introduces the problems we had when we still had line numbers
>in programming languages instead of in (their) editors:  when you want
>to insert something in between 1 and 2, you need to either:
>   =renumber at least one, maybe thousands
>    =use fractional numbers (where rounding errors can introduce
>surprises, next to even worse (less quick) readability)

It can be used to improve the readability, understandability and
acessibility of documents as well, for example if the source
code is ordered in such a way, that the alternative text presentation
is understandable.
Currently authors have to order the elements in such a way, that
the painters model results a meaningful graphical representation -
or they have to use this tricky thing with use and the animation of
the xlink:href to reorder the elements for the graphical representation.
However the painters model approach can result in very confusing order
of title/desc-combinations of different elements ;o)

Olaf

[Dr. Olaf Hoffmann]

Jonathan Watt:
....

>
> "3D" transforms are just an affect that changes an elements appearance as
> if it was being transformed in 3D, but they actually have no affect on its
> "depth" or rendering order. Only 'render-order'/'z-index' would. Maybe
> someone can come up with a fantastic, relatively easy to grasp proposal on
> how to change that, but I seriously doubt it. If you want real 3D as
> opposed to pseudo 3D, then probably its better to use something like WebGL
> (possibly using it to render SVG into planes that can then be manipulated
> in true 3D).
>

Well, often applications are simple enough or can be decomposed in
simple enough problems to be presented with SVG.
I think, it is not very important which library or number crunchers an
author uses (I prefer fortran or PHP), if the SVG output is
sufficient to represent the intented result without too many
redundancies (for example big file size containing only
a lot of data because SVG is not capable to handle it in a
problem oriented way).
And of course such a z-index functionality as well as the '3D' proposal
is a big progress to reduce redundances and complexities, with the
result, that an author can solve the same problem with a 10kB SVG 1.2
file instead of an 100MB SVG 1.1 file and a lot of number crunching
just to create this 100MB file from the 1kB raw data describing the
original problem.

Not sure, if it is fantastic, but the proposal I'm currently working
on, solves among other more important problems those of simple
3D data as well in a relatively simple way. Combined with a z-index
functionality this could be a pretty convenient way to provide simple
3D data representations with low file size and much less author efforts
than without:
http://purl.oclc.org/net/hoffmann/rdml/


Olaf

[Jeff Schiller]

Hi Jonathan,

On Mon, Oct 26, 2009 at 5:44 AM, Jonathan Watt <jwatt@...> wrote:
> 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.

Actually whenever we re-order things in SVG-edit, we just
insertBefore() into the DOM, my comments have nothing to do with that
project. :)

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

I'm not a DOM expert, especially when it comes to load events, things
like that - but it seems to me that this is the main reason people
think they need the ability to arbitrarily order the document.  My own
thoughts on this are:  why does the image need to be reloaded when an
insertBefore() has been done?  Could additional requirements be added
to the DOM to change this behavior upon insertBefore()?

i.e. "If the node being inserted into the DOM already exists in that
DOM, the user agent must only reposition the node in the DOM, the user
agent must not reload the contents or ..."

If this has the potential to break a whole lot of existing web content
(as I now suspect it does), then could a new method be added into the
core DOM? i.e. moveElement() that has the same function signature as
insertBefore()?

Several members of the SVG IG were chatting about this at SVG Open
(Ruud, Wade, myself).  At the time we thought z-index (or something
equivalent) breaks the elegance of SVG for the reasons that Ruud
stated above.  We were originally thinking about a new method for
moving elements within a DOM but I wasn't even sure this was required
since I was not familiar with the requirements on UAs to reload
content when insertBefore() had been called.

Regards,
Jeff

[Boris Zbarsky]

On 10/26/09 11:47 AM, Jeff Schiller wrote:
> why does the image need to be reloaded when an
> insertBefore() has been done?

It doesn't (and generally isn't, last I checked).

Removing an <iframe> from the DOM currently unloads the document inside
the iframe in Gecko for technical, not spec, reasons.  Fixing that
(which is desirable, but low priority) seems like a better idea than
introducing yet another DOM method.

Similarly for plug-ins: a plug-in instance gets destroyed on removal.
This we're not sure about being a bug; sites might depend on this
behavior.  Hard to say.

I can't speak to behavior in other UAs.

>  We were originally thinking about a new method for
> moving elements within a DOM but I wasn't even sure this was required
> since I was not familiar with the requirements on UAs to reload
> content when insertBefore() had been called.

There are no such requirements in the DOM specs.

In fact, there are no requirements that anything at all be loaded, in
the DOM specs.

-Boris

[Jeff Schiller]

On Mon, Oct 26, 2009 at 11:01 AM, Boris Zbarsky <bzbarsky@...> wrote:

>
>>  We were originally thinking about a new method for
>> moving elements within a DOM but I wasn't even sure this was required
>> since I was not familiar with the requirements on UAs to reload
>> content when insertBefore() had been called.
>
> There are no such requirements in the DOM specs.
>
> In fact, there are no requirements that anything at all be loaded, in the
> DOM specs.

I couldn't find anything in my cursory searches of DOM 2 and DOM 3
Core, but as I said: I'm not DOM expert.

Jeff

[Doug Schepers-3]

Hi, Jeff-

Jeff Schiller wrote (on 10/26/09 11:47 AM):

>
> On Mon, Oct 26, 2009 at 5:44 AM, Jonathan Watt<jwatt@...>  wrote:
>>
>>  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.
>
> I'm not a DOM expert, especially when it comes to load events, things
> like that - but it seems to me that this is the main reason people
> think they need the ability to arbitrarily order the document.  My own
> thoughts on this are:  why does the image need to be reloaded when an
> insertBefore() has been done?  Could additional requirements be added
> to the DOM to change this behavior upon insertBefore()?
>
> i.e. "If the node being inserted into the DOM already exists in that
> DOM, the user agent must only reposition the node in the DOM, the user
> agent must not reload the contents or ..."
>
> If this has the potential to break a whole lot of existing web content
> (as I now suspect it does), then could a new method be added into the
> core DOM? i.e. moveElement() that has the same function signature as
> insertBefore()?

This may solve the script case (though I'm afraid it might introduce
other complexities), but it doesn't solve the declarative case.


> Several members of the SVG IG were chatting about this at SVG Open
> (Ruud, Wade, myself).  At the time we thought z-index (or something
> equivalent) breaks the elegance of SVG for the reasons that Ruud
> stated above.

Having to use script to accomplish this also breaks the elegance of SVG,
for static or declarative documents.


>  We were originally thinking about a new method for
> moving elements within a DOM but I wasn't even sure this was required
> since I was not familiar with the requirements on UAs to reload
> content when insertBefore() had been called.

It's an option we should consider.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Jeff Schiller]

On Mon, Oct 26, 2009 at 11:29 AM, Doug Schepers <schepers@...> wrote:
>
> This may solve the script case (though I'm afraid it might introduce other
> complexities), but it doesn't solve the declarative case.

You mean the declarative solution isn't just to put your elements in
the DOM in the order you want them displayed? :)

I guess you're talking about declarative animation which I'll be
honest I haven't really thought about...

But it still seems like we should 'fix' the UA behavior on
insertBefore(elementAlreadyInDOM, ...)

Regards,
Jeff

[Boris Zbarsky]

On 10/26/09 12:01 PM, Boris Zbarsky wrote:
> On 10/26/09 11:47 AM, Jeff Schiller wrote:
> Removing an <iframe> from the DOM currently unloads the document inside
> the iframe in Gecko for technical, not spec, reasons. Fixing that (which
> is desirable, but low priority) seems like a better idea than
> introducing yet another DOM method.

That said, I should note that for HTML/CSS content a z-index change is
much cheaper than an insertBefore.  On a conceptual level, the former
merely has to invalidate the area of the object whose z-index changed,
thus triggering a repaint of that area.  The latter, on a conceptual
level, has to tear down the CSS boxes for the subtree being moved and
create new ones, rerunning CSS selector matching (since selector
matching depends on tree position and since styles depend on both which
selectors matched _and_ on tree position due to inheritance).
Optimizing some of this work away while not introducing bugs would be
... complicated.

To put numbers to this, load http://www.cnn.com and try both approaches.
  To swap using z-index:

javascript: function swap() { var start = new Date();
document.body.style.zIndex = -1 * document.body.style.zIndex;
document.body.offsetWidth; setTimeout(function() { alert(new Date() -
start); }, 0); } document.body.style.position = 'absolute';
document.body.style.zIndex = 2; var myNewNode =
document.createElement('div');
document.documentElement.insertBefore(myNewNode,
document.documentElement.firstChild); myNewNode.innerHTML = '<input
type="button" onclick="swap()" value="Swap"><div style="position:
absolute; width: 200px; height: 200px; background: white; z-index: 1">';
void(0);

To swap using insertBefore:

javascript: function swap() { var start = new Date();
otherNode.parentNode.insertBefore(topNode, otherNode); var temp =
otherNode; otherNode = topNode; topNode = temp;
document.documentElement.offsetWidth; setTimeout(function() { alert(new
Date() - start); }, 0); } var topNode = document.body;
document.body.position = 'absolute'; var myNewNode =
document.createElement('div');
document.documentElement.insertBefore(myNewNode,
document.documentElement.firstChild); myNewNode.innerHTML = '<input
type="button" onclick="swap()" value="Swap"><div style="position:
absolute; width: 200px; height: 200px; background: white;"
id="swapper">'; var otherNode = document.getElementById("swapper"); void(0);

In Safari 4, for example, the former requires ~30ms over here.  The
latter requires ~70ms.  In Gecko builds with bug 507764 fixed, the
numbers are 50ms and 200ms respectively; the former will go down once
some planned inline style change optimizations happen.

-Boris

[Doug Schepers-3]

Hi, Jeff-

Jeff Schiller wrote (on 10/26/09 12:34 PM):
> On Mon, Oct 26, 2009 at 11:29 AM, Doug Schepers<schepers@...>  wrote:
>>
>>  This may solve the script case (though I'm afraid it might introduce other
>>  complexities), but it doesn't solve the declarative case.
>
> You mean the declarative solution isn't just to put your elements in
> the DOM in the order you want them displayed? :)

Not necessarily.  I've often run into the situation where I had 2 (or
more) different organizational considerations, but was forced to use
just one, as imposed by the document structure.  A simple example is
collecting all the labels in one group for displaying above the
corresponding shapes, when in fact they should be organized each with
their related shape.


> I guess you're talking about declarative animation which I'll be
> honest I haven't really thought about...

Yes, animation does add scenarios, but the uses are not exclusive to
animation.


> But it still seems like we should 'fix' the UA behavior on
> insertBefore(elementAlreadyInDOM, ...)

Yes, the behavior in the DOM specs should be clarified.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs