Adding dynamic evaluation of element attributes to SVG

Some time ago we posted a suggestion that SVG allow element attributes to be
assigned expressions which are evaluated at display time by the SVG browser
to compute the value of the attribute.  The expression may refer to
attributes of other elements and also to properties of the display
environment such as the actual viewport width and height.

Our main motivation was that this allows the layout of the SVG document to
adapt to its environment, particularly to different viewPort sizes and font
sizes. I think this provides the capabilities that Allan Razdow would like.

Providing dynamic evaluation of attributes also has benefits for widget
layout.  It allows widgets to have a fixed location and size regardless of
zooming and panning and dynamic evaluation (under the name of one-way
constraints) is a good way to handle widget layout. E.g. see Elliot's
RelativeLayout, a Constraint-Based Layout Manager
http://www.onjava.com/pub/a/onjava/2002/09/18/relativelayout.html)

For example here is some SVG that will draw a QUIT button in the
top-left corner using the same font size regardless of zooming or panning.
The font size used is the default browser font size set by the user,
allowing the widget to adapt to requirements for larger fonts. The rectangle
drawn around the text (of course) adapts to the text size.

The example assumes the following environment variables are available
* ZoomScaleFactor: this is the current scaling factor due to zooming.
* PanOriginX, PanOriginY: these are the coordinates of the top left corner
of the region currently being displayed (updated during zooming and
panning).
* DefaultFontHeight: this is the default font height set in the browser

<!-- SVG graphic -->
   <svg xmlns='http://www.w3.org/2000/svg'
      width="100px" height="200px" zoomAndPan="magnify" >

   <!-- text placed in upper-left corner -->
   <text ID = "QUITtext"
         x="PanOriginX + (5mm/ZoomScaleFactor)"
         y="PanOriginY + (5mm/ZoomScaleFactor)"
        font-family="Verdana"
        font-height="DefaultFontHeight/ZoomScaleFactor"
        fill="blue" >
    QUIT
  </text>

  <!-- draw a rectangle around the text to create a button -->
  <rect x="//text[@ID=QUITtext]@x"
        y="//text[@ID=QUITtext]@y - //text[@ID=QUITtext]@textheight"
        height="//text[@ID=QUITtext]@textheight"
        width="//text[@ID=QUITtext]@textLength"
        fill="none" stroke="blue" stroke-width="2" />

      
      <!-- rest of SVG graphic would go here -->
   </svg>   

Please do not focus on the syntax and my inexperience with XPath, the point
to notice is that we can do seemingly difficult things in a simple uniform
way without needing to use scripting.

Of course you could do this with scripting but the advantages of providing
this capability directly in SVG are
* It makes SVG documents with this capability easier to understand, author
and interchange. The problem is that otherwise two languages need to be used
with hidden dependencies between them and scripting languages are
non-declarative and non-XML compliant.
* An SVG browser can provide a more efficient implementation to handle
dynamic evaluation and incremental update in linear time.
* Dynamic evaluation is less expensive to support than general purpose
scripting, thus making it more suitable for less powerful computing
devices.

I'd love to see such capabilities in SVG 1.2: what do others think?

Kim

See
    K. Marriott, B. Meyer, and L. Tardif. Fast and efficient client-side
    adaptivity for SVG. WWW 2002 May 2002.
    http://www.csse.monash.edu.au/~marriott/papers/csvg-mmt.pdf
for a more complete description of the proposal and
    http://lists.w3.org/Archives/Public/www-svg/2001Jul/0016.html
for our earlier posting.

Received on Wednesday, 27 November 2002 23:22:08 UTC