RE: SVG 1.2 Working Draft: Comments on 3.2.7 Expression-based at tribute values

Kim,

Thanks for this message. The inability to have graphics adaptive to text
attributes, particularly where SVG is rendering user-altered or user-entered
text is a serious limitation in our view.  We've brought this up
periodically to this list, but never so clearly and credibly as you have
here.  We enthusiastically support your suggestion.

-Allen

-----Original Message-----
From: Kim Marriott [mailto:Kim.Marriott@infotech.monash.edu.au] 
Sent: Friday, May 09, 2003 3:35 AM
To: www-svg@w3.org
Cc: Bernd Meyer; Cameron McCormack
Subject: SVG 1.2 Working Draft: Comments on 3.2.7 Expression-based attribute
values 



Basically I just wanted to strongly support the idea of adding
expression-based attribute values. Potentially they are very useful for
widget layout (3.2.3 UI widget support) and for dynamic layout (3.2.8
Dynamic layout). 

I also think it is important to provide as much support for dynamic layout
at the SVG level as possible rather than relying on XSLT (or declarative
variant) or scripting to do this.  First, it allows for efficient support
for animation or user interaction with the SVG document, say if the browser
window is resized. Support at the SVG level means that XSLT or scripting
need not take place after every user interaction or during animation.
Second, it simplifies the task of the XSLT or scripting author, and writing
XSLT or scripts is arguably much more difficult than writing SVG.

Expression-based attribute values under the name of one-way constraints
provide a simple powerful basis for UI widget layout: see the explanation of
Elliot's RelativeLayout, a Constraint-Based Layout Manager for Java
  http://www.onjava.com/pub/a/onjava/2002/09/18/relativelayout.html
For more information about one-way constraints and GUIs in general see
references in
    B. Vander Zanden et al. Lessons learned about one-way, dataflow
    constraints in the Garnet and Amulet graphical toolkits, ACM
    Transactions on Programming Languages and Systems (TOPLAS) 23(6), 2001.
Expression-based attribute values also support dynamic layout, as discussed
in     
    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

The proposal to add expression-based attribute values potentially gives the
power to program widget layout in SVG and support dynamic layout. However
this depends crucially on the kind of expressions allowed. It is not clear
to me from the working draft what is intended to be allowed in the
expressions. For instance whether the expression can refer to attributes of
a wide variety of SVG elements such as text or whether they can only refer
to properties of the outermost SVG element set by the viewing environment
such as the viewport.

I think it is important to be able to refer attributes of things such as
text since this allows dynamic layout that adjusts SVG placement to changes
in text size resulting from user preferences in font or language. I.e. it
allows text boxes!

I think it is also important to provide max or min operations since this
allows non-proportional scaling of elements, i.e. shrinking of white space
in diagrams for narrow viewports or squashing together of widgets laid out
in a grid.

Allowing conditional expressions of the form
  <path d="M {if {viewport.right-viewport.left > 10px} then
                          {viewport.left+10px}
                        else
                          {0.5*viewport.right+0.5*viewport.left}}...."
provides even more expressiveness. Such conditional expressions mean that
alternate layout such as laying out a tree or widgets horizontally in a wide
viewport but vertically in a narrow viewport can be supported. The SVG
working group might want to consider adding conditional expressions, either
as part of the expression language or by extending the renderSwitch proposed
in 10.2 Proposal 2: Conditional content based on resolution.

A second issue is whether expression-based attribute values are to be
allowed in other attributes apart from path data. For instance in the height
and width of a rectangle. Logically this makes sense where the attributes
are implicitly defining a path. What about for attributes which are not
paths, for instance in transformations?

A third issue is checking that an expression has the right dimension. For
instance
   <path d="M {viewport.right/viewport.left} ..."
is in my view a dimension error.

A fourth issue is readability: one might want to provide local variables to
allow complex expressions to be broken up and reused.

My final issue: What will be the effect of transformations on these external
parameters? I feel that when accessed from a SVG element within a
transformation that the appropriate transformation needs to be applied to
the external parameter value.


Kim

-- 
Professor Kim Marriott
School of Computer Science & Software Engineering
Monash University, Wellington Rd, Clayton, Vic 3800, Australia
Ph: ++61 (3) 9905-5525, Fax: ++61 (3) 9905-5146
Email: Kim.Marriott@infotech.monash.edu.au

Received on Friday, 9 May 2003 06:33:19 UTC