Re: z-index control and relative coordinates: separated at birth?

On Thursday, January 7, 2010, 4:50:13 PM, Rick wrote:

R> My current project involves a geographic situation display that zooms
R> rotates and pans.  I call that the map layer, and everything that is
R> part of the map is in that group.  Immediately following that I have
R> the hud, containing my widgets, the hud is 1:1 and lives on top.

Yes, but suppose your widgets are tied to some geographic object (like an infobox or tooltip) which if fixed geographically but moves and pans relative to the hud coordinate system? 

Or if you also display moving objects (tracks, ships, planes) in real time and those also need widgets attached to their current position? 

R> On Wed, Jan 6, 2010 at 10:14 PM, mawrya
R> <[email protected]> wrote:
>> Of course, the solution is to move the markup for all the popups to
>> the end of the svg markup so the painter's model is in harmony with
>> the desired affect. Unfortunately, this means I can't use relative
>> coordinates for drawing the popups. Relative coordinates were really
>> simplifying things and I'm not looking forward to reworking everything
>> - I'm not just drawing pictures, but a Human-Machine-Interface
>> framework with interactive widget-type graphics that can be created,
>> moved around, and have multilple instances of the same widget on the
>> screen. Everything can be dynamic and drawn at various coordinates
>> based on input from external sources. This is why relative coordinates
>> are so handy in my case.

I can see that relative coordinates would be good for the anchor position (but absolute, scree-oriented, coordinates would be good for the size and layout of the infobox).

>> It seems that SVG doesn't let you have it both ways - you can either
>> have relative coordinates, or you can have control of layers / z-
>> index, not both at once. 

Right.

This is something the SVG WG has been aware of for a while. Two things were added to the SVG 1.2 drafts to fix this. 

The first was the ref() transform value, so for example you could specify the width, height, font size of a widget in one coordinate system while describing the anchor of the rectangle by saying "that value over there in another part of the tree". 
http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html#transform-ref

The second thing was Overlaying graphics, a way to say "this is on top of everything".
http://www.w3.org/TR/2004/WD-SVG12-20041027/painting.html#overlay

Of those, overlay made it into SVG Tiny 1.2 (but only for the video element)
http://www.w3.org/TR/SVGTiny12/multimedia.html#compositingBehaviorAttribute

and ref() also made it in
http://www.w3.org/TR/SVGTiny12/coords.html#transform-ref


None of which helps people coding to SVG 1.1 (unless you add a script library to backport the functionality) but I did want to show that the SVG WG is aware of the issue and is trying to address it.


-- 
 Chris Lilley                    mailto:[email protected]
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG