Suggestions for additions to the W3C Specification for SVG

SVG Working Group (WG) has demonstrated considerable willingness to collect input from the community about the sorts of features that the language should contain to best support the needs of its user community. Like its cousin, HTML, SVG has a most remarkably divergent set of user needs. Given its emphasis on material displayed on planar devices, and given the intrinsic importance of spatial relations in the presentation of content using a spatial metaphor, SVG's user community may be expected to grow to embrace and support more diversity even than HTML, which at its core is (with the exception of the <table> element and possibly other elements related to spatial arrangement) 1.5 dimensional: that is, its fundamental metaphor consists of written speech (text), with occasional embedded belches of multimedia (<object>, <img>, <audio>, <video>) plus graph theoretic cross-references that provide a modest foray into translinearity.

For alphabet A={a1, a2, ... , an } and graphics G={G1, G2, ...Gk} (where A intersect G is empty)

The text -- a linear sequence of characters with occasional pictures.

For vocabulary V={w1, w2, ... , wn }, including graphics G and anaphora H={h1, h2,}  (where  G and H are subsets of V). An example of anaphora might include H={this, that, which, he, her}

The hypertext -- words and pix in sequence with references.

SVG has every bit as much semantic and pragmatic reference to meaning as HTML, it is every bit as hypertextual, but its core metaphor for expression is the plane rather than the line. As such it has come to attract, already, artists, physical and social scientists, and mathematicians whose needs for expression transcend the ability to belch static frames generated elsewhere into an otherwise translinear stream of text. For this community, multidimensional space is not the occasional 2D painting on the wall of an otherwise 1.5 dimensional hypertext, rather for n>=2, n- dimensional space is home.

In addition to being quite close to wrapping up one specification, the WG has been working hard on another and has announced both that it is focusing some of its efforts into extensions of the spec into focused areas of initiative (such as filters, gradients, transforms, accessibility, etc.) and that it is interested in engaging the community in broader dialogue about its needs. In response to community feedback it is already planning to consider extensions into non-affine transformations, richer sets of filter primitives, and improved control over layout and flow.

At the same time, it is important for the SVG community to respect the facts that a) standards development is hard work involving intense amounts of behind-the-scenes work with validation, test suites, conformance and other magical things I don't pretend to understand b) the WG already has a large agenda mandated by the standards process and c) there are not that many individuals in the WG to be able to do all the work already present. In part, this is why the SVG-IG has come into existence: to help with the workload (and hopefully, to shrink it at least as much as we add to it.)

So, without appearing to dump a giant chunk of work onto the WG*, I'd like to suggest that we have some discussions about new classes of effects for the SVG spec, under a couple of provisos: 1. let's realize that these are not responses to a candidate or current draft and 2) spec writers usually prefer it[1] when users structure the discussion of needs in a vocabulary and syntax that spec writers themselves use: use cases, disambiguation, validation, ontologies, and so forth. That is, if we can make our needs clear, document how or why the current spec doesn't do something, provide multiple situations (use cases) in which the feature could be useful (to the arts or sciences -- while recognizing that usefulness can mean very different things to different communities) , and perhaps, even suggest how the syntax of the feature might be expressed, then in such a case, the IG might reach consensus that a given feature be recommended to the WG for inclusion in "a future spec." The reason for saying "a future spec" is that, as I understand it, the W3C requires rather extensive amounts of work from a WG depending on the stage at which a given current spec is in its progression from draft to recommendation. I don't believe it would be in anyone's interest to derail any progress currently underway. We like SVG!

Some Suggestions:

I will discuss the following: the <contour>, an object consisting of concentric subpaths (closed curves) that instructs the gadget-browser[2] to interpolate those subpaths into something resembling a path filled with a gradient that is considerably more flexible than the radial or linear gradients, applied as effects.

A syntactically similar notion is the <superpath>. Like the <contour> it has <path> elements within it, but those path elements are never closed by z in their "d" attribute and represent the different borders that a given region might share with its neighbors (as in a geopolitical map). It is likely to be used both for map processing, graph theoretic purposes (like diagramming), animation, and for layout (that is more flexible than the HTML table or its CSS counterparts since it affiliates regions, connections and boundaries of arbitrary partitions of the plane)..

Also included (with increasingly less clarity in my mind as to exactly how they would work are the doodle, the editable attribute for <path>s and for certain <animate>s, the editable <sound> and the fractal (is it a basic shape or is it a filter?).

Speaking of filters, I believe the universe of possible filters (like the class of permutations of strings) is a large set. While, we might observe that a small number of primitives may suffice to generate all expressions in that expressive realm[3] I am not clear how best to optimize the size of that set, and to make matters worse, I think the boundary between filters and transforms occasionally becomes blurry -- perhaps because of Photoshop's inclusion of "distort" options in the fillter menu while simpler transforms live in the edit menu. Given the already rather high learning curve (so It would seem based on the expertise level of the audience that might show up for a workshop on filters) associated with filters, I think we should exercise caution about expanding that set too quickly. I am reminded of how quickly Kai's Power Tools became accessible as Photoshop plugins In the 1980's so we may wish to consider extensible grammars in this area. Nevertheless, I have three things to say on this topic: spherize and pinch (as either transforms or filters) are quite handy (owing to their relationship to common lenses) and a mechanism for weaving pictures together as in could prove useful both in artistic and cryptological communities[4]. Last and foremost it'd be nice to have a filter to convert bitmaps to paths like apparently happens in the diffusion curves video at . The fellow from Los Alamos at SVG Open 2007 was doing pretty cool stuff with SVG and realtime data processing of scenes -- his algorithms were quite fast though USDOE has gotten rather stuck with cost recovery lately so I don't know if the stuff is still covered by the "works of the US govt / copyright" proviso. If nothing else the stuff that Adobe was doing in its early Illustrator (88) and the stuff in Inkscape (which is pretty darn sophisticated) and NIH image would give us an ample start in that direction.

The <doodle> is a somewhat declarative alternative to the <path>. Rather than drawing it by enumerating coordinates and transitions as in its simpler cousin <path>, one enumerates coordinates and transitions,but also extrapolations, iterations and simple enumerated, conditional and recursive operations.

It and the others will be discussed in more detail now.

A. The new grouping elements: <contour> and <superpath>

Basically, the contour and the superpath are like groups <g>, but all the visible elements inside are <paths>. Each gives explicit instructions to how those objects inside are combined, extrapolated, animated on the screen and how they are processed through certain JavaScript (or other language) calls. (I know the Spec refers to ECMAscript rather than JavaScript but ours is, after all, not a standards group and it is probably best to keep a sense of informality, and even, occasional humor to our discussions.)

B. The <contour>

As mentioned earlier, <contour> is an object consisting typically of concentric subpaths (closed curves). It interpolates those subpaths into something resembling a single path filled with a gradient that is considerably more flexible than the radial or linear gradients, applied as effects. It is like a contour map, but since the border (stroke) is not required, it resembles, when the curves are concentric, a shape gradient that may have multiple shapes inside. I had started writing this up before I had a chance to look at the stuff that we heard about concerning Diffusion curves, so I don't know how the two ideas compare. This idea is straightforward to implement and would rely on some code the browser implementers have probably already built (like following movement along a path). So with that in mind, here goes:

The paths within < contour > are constrained as follows:

Their fill must be either a simple color or a gradient (no patterns or filters). If two fills of type gradient are adjacent (in markup) then both must be of the same type (radial or linear). If two gradients of different type are adjacent then one must be of the null type (e.g. a simple fill=color) so as to allow a nonambiguous interpolation.

Typical syntax:

< contour type=null|gradient|animate path=”url(#q)” 
method=uniform|equidistant steps=positive-integer>
<path />
</ contour >


The way it works is this.In the default case, we build a shape by interpolating between two other shapes as in Illustrator (circa 1988) when you'd tween between two bezier curves. The tweening lays down, in sequence a series (of size "steps") of new path elements moving from the background to the foreground. Those path elements are rendered on screen, and inserted into the DOM., so that the <contour> expands the DOM declaratively. Inkscape provides this functionality under "effects" / "generate from path" which one can experiment with easily. Illustrator provides it under Object / Blend.

By default the interpolation moves the bounding box of the first to the bounding box of the last (with possible intermediate steps given by the path elements between first and last) with linear interpolation. If a path attribute is provided then the position of the center of the bounding box of the hypothetical curves will follow that curve. If the curve provided does not coincide with the bBox centers of paths that lie between the first and last, then the locus of those intermediate paths is overwritten by the path of the provided url. [I'm not sure I wrote this correctly, but I'm thinking of something much like the way SMIL animation follows a curve]

If the type specified is "gradient" then the <contour> itself may be used to shade any other simple drawn object in much the way that a radial gradient whose centroid and fx cause out-of-bounds regions. In such case, the <contour> is not rendered, and instead acts like it is part of a <defs> tag.

If the type specified is "animate" then the intermediate frames will not be added to the DOM nor accumulated on screen as rendered, but rather will be "moved" from the first position to the last following the "path" and interpolating shape and fill from beginnng to end (with the each specified path acting as a sort of intermediate keystop).

If the number of control points in each path is identical, then the tweening happens on the natural correspondence. Otherwise if one shape has n control points and the other m<n. then the mapping happens between the division of n into M subpaths of equal length (as measured by the same algorithms that give us path.getPointAtLength ).

Use cases:

1. creating simple 3D-looking objects with shading

2. allowing a richer class of gradients than just linear and radial (useful for drawing)

3. allowing a richer class of declarative animation in which two shapes and a path determine the framewise transitions as well as the 2-D path.

C. The <superpath> (including <map> and <node>)

Currently, any concept of "proximity" or adjacency (as in regions that share a border) within SVG must be defined using script. It is the premise of this proposal, that allowing markup to convey the sense of a spatial relation between two SVG objects is not only useful, but applicable to several areas, and ultimately liberating to programmer and non-programmer alike.

This is used to either facilitate animation of separate parts of an object, to easily define a class of part-whole relations, or to define a sequence of boundaries that define regions, as in a map, or tabular layout. We introduce the "superpath": that is, the union of a series of subpaths, in which those subpaths may, in fact, be shared between multiple ("contiguous") superpaths.  The one-dimensional junction of two superpaths converge is their border, and is typically, a <path> consisting of exactly one "M" subcommand.

The zero-dimensional junctions, or point, where three or more superpaths converge is called a "node". A collection of superpaths is called a map. The incidence matrix  (or boundary matrix or adjacency matrix)  of a <map> is uniquely specified by the pairs of <superpath>s  within the map that have shared subpaths.

Typical syntax:

<superpath  fill=color|gradient|pattern|filter>
<path /><node id=quotedstring /><path />
< node /> 

1. A <path> element in a superpath must not have a "z" path command at the end of its "d" attribute; it is not a closed path.

2. The <node> objects are for reference to the vertex shared by any two consecutive paths within the superpath.

3. by default, a <map> is of type "map"

4. I've decided it is easier to have the <map> element than to have a class of superpaths that contain superpaths. (my reasoning here is rather fuzzy)

5. a <node> at the end of the sequence of subpaths within

Superpaths allow for condensation of the data needed to specify a planar map or for the planar embeddings of graphs (whether intrinsically planar or not).

Several superpaths together in a collection are called a <map> which is either of type "map" or type "graph".

<map type=map|graph><superpath><path/><path/></superpath><superpath><path/><path/></superpath></map>

might be a typical usage.


Consider the following diagram that shows three planar regions drawn next to each other. At one level of zoom and data precision. the regions appear to abut one anotherr properly, but at another level we see that the imprecision (due to level of accuracy) has sundered the images from one another


The superpath works by breaking each region into a series of subpaths -- each describing the border where precisely two regions meet. A subpath is either a <path> or a <node>: a path containing only one x-y coordinate.

Let's begin with an example:

The above map could be described as

<map type="map">

<superpath id=”OneYellow” color=”mustard”>

<path id=”A” d=[description of path from node3 to node2] />

<path id=”B” d=[ description of path from node2 to node1] />

<path id=”E” d=[ description of path from node1 to node3] />


<superpath id=”OneBlue” color=”blue”>

<path id=”C” d=[description of path from node4 to node2] />

<path id=”B” d=[description of path from node2 to node1] />

<path id=”D” d=[description of path from node1 to node4] />


<superpath id=”OneGreen” color=”lightgreen”>

<path id=”A” d=[description of path from node3 to node2] />

<path id=”C” d=[description of path from node2 to node4] />

<path id=”F” d=[description of path from node4 to node3] />



Note: any fills associated with paths that are part of a subpath are ignored, though their strokes might not be (since different borders between regions may require differing strokes. If a superpath region defines a stroke, then all subpaths inherit that stroke unless they have their own stroke defined.

Given two consecutively defined paths within a superpath, It is generally assumed that the last point of one, A(n) will be the first point of the next, B(1). If not there are two options: either a line segment is added connecting A(n) to B(1) prior to rendering, or a <point> element is inserted between the two paths to specify the nature of the transition between the subpaths it connects:

<superpath id=”OneGreen” color=”lightgreen”>

<path id=”A” d=”100,100 200,200 />

<node x=”210” y=”210” join=”smooth”/>

<path id=”A” d=”200,220 100,300 />


The above would instruct the browser to find a “smoothest” transition between the two paths – one which matches the slope of the two paths at the endpoints being joined. This involves definition of the <node> element, which for now is rather vague, but its purpose is to allow styles to be assigned to the juncture of two path segments, to give simplified control over animations of <superpaths> by animating the locus of such <node>s and to allow the identification of graph theoretic “nodes” when the superpath is of type =“graph”

When, for the map containing a collection of superpaths, type="graph" the concentration is on the linking structure provided between nodes or points. In the above diagram, the graph defined, would be the geometric dual of the map, so that this map (informally used to mean a group of superpaths) would in fact define the graph K4 (4 nodes all connected pairwise).

When we fill a superpath not with a color or fill, but rather with svg, what I mean by that is that we flow a given group <g> into the shape defined by that region. This allows a very flexible class of geometric layouts in the plane -- far more flexible and fine-grained I think that html <table> and far more user friendly than CSS when it comes to actually building something (empirical hypothesis demanding human factors data!)

Use cases/ rationale:

1. Allowing the author and user to zoom in on borders of regions of maps without having to specify huge levels of precision when the we zoom to close levels of details and still have regions borders zoom accurately. The presentation by Li, Yan (School of Computer, South China Normal University) "An Extension of Spatial Functionality for SVG Specification" at SVG Open 2008 made a fairly compelling use case. By way of extending this functionality for cartographic purposes, see also the footnote (a) that follows this section on making text disappear declaratively as we zoom out.

2. Allowing the data reduction afforded by not having to redundantly ship entire descriptors of regions which share common borders

3. Enabling methods which might deform one border of two shapes without having to redraw the entire map.

4. Enabling ease of animation by providing markup-based parsing of a drawn object into semantically relevant subobjects and maintaining the relational structure of those subobjects. We may, for example, by breaking a paths d that has 1000 elements into 100 subpaths of 10 control points apiece, we may animate just the "arm" subpath of a cartoon character, without having to interpolate between two 1000 point paths. This will likely make life easier for hand-coders and authoring tools alike.

5. Providing a lightweight format for the specification of binary relational data: graphs. The stipulation of the <node> object should be fleshed out but one can consider that by defaullt an entire group of superpaths would inherit

6. Providing a flexible method for stating the spatial relations between collections of SVG objects, that can be used to support layouts. One can imagine "pouring" GIS data into the <superpath>'s of a <map> under certain constraints about importance / display, edging, etc. More on this topic can be found in this note**

7. Providing scripting methods appropriate to the support of the above use cases.

Example A=getElementsById("Q") ///where Q is a group of superpaths

///can be followed by


///for the above example which would return a JavaScript object

Graph = [






That is, an incidence array for the nodes of the graph (which is sufficient for all relational data). If the geometry of the paths is relevant then

Graph=A.toGraph("lines") might return an object consisting of an array of node incidences together with an array of pointers to the actual subpath objects in DOM.


(a) On allowing text to scale "properly" at several layers of zoom.

For the cartographer, textual information (like letters and symbols in languages like English or Chinese) do not always scale properly.

 At one level of zoom (for example a view of northeastern China) we may only be able to see Beijing, Shijuiazhuang, Tianjin and Huhehaote displayed because of the minimum size required for the characters to be legible and the size of the map. At another level we may see Lanqfang, Tangshan, and Zhangjiakou as well. Still closer we may see the districts Fangshan, Shunyi and Changping.

The ability to describe this through markup rather than script, it seems to me, is desirable.

Something like <text zoomdetail="5">Changping</text> and <text zoomdetail="1">Beijing</text> would allow the browser to "know" at what levels of zoom, these labels should appear and at what levels they should remain invisible. This is not difficult to do with script, but a very large part of the charm of SVG is that it allows many such details to be handled by markup rather than script.

Building paths declaratively: the <doodle>

(See also the <replicate> below).
My thought here is based on the simple observation that it is too much work to have to actually write or draw all the coordinates in the d attribute of a path. Can't we do that declaratively by saying something like this?:

Walk south for three blocks, turn 20 degrees, repeat this operation 12 times, but reducing the scale each time by 20% as we go. This generates a spiral.

I remember writing a paper in grad school about the syntax of such declarative drawing languages (there were a couple at the time -- maybe Herb Simon (H. A. Simon, “Complexity and the Representation of Patterned Sequences of Symbols,” Psychological. Review 79 (1972):)  and later Seymore Papert defined one as I recall in Logo). My recollection of what I concluded is that isolation of the primitives was subjective and that no objective work on which of several distinct axiomatizations actually worked best for humans had been done. The progress in empirical work in such heavily theoretic areas has I suspect been largely neglected by researchers who would rather build things than study humans. However there are a class of smooth planar four regular graphs that as neural networks are sufficient to drive computation in two space (with only a trit of memory per processor) and the drawing of those graphs would be awfully nice if it could be done somewhat declaratively.

Consider something so simple as a regular octagon. And suppose we wish to do such through markup.

d="M 100 100 L 200  100  270.7 170.7 270.7 270.7 
     200 341.4 100 341.4  29.3 270.7  29.3 170.7 z" 

would be the way. (Note the presence of the irrational numbers in any embedding of the octagon in the Cartesian plane.)

Wouldn't " M 0 0 (Move forward 100 units turn right 45 degrees) repeat 8 z" is a much simpler construction for programmer or non programmer alike than to actually calculate the irrational coordinate positions.

I note that Inkscape's "effects" menu has a lot of the sorts of things I may be thinking of here. A simple microformat (is that the right word?) could be developed that would be easy to implement and would expand the expressive power of mathematicians, artists and animators alike.

<doodle dd="(((M 100 100 radian 330 12) scale .5) iterate 12) (((last duplicate) translate 30) rotate 20 ) iterate 5 >

Basically, it'd be sort of like the use of <use> in but defined on parts of curves rather than objects.

The primitive operations should include rotate, translate, scale, but also reflect (invert the markup point sequence description from left to right), fragment (shake or permute a given sequence), randomize, smooth and fractalize (to a given degree). The ability to insert random numbers into our SVG without script is likely to be very important, I think, to the arts community.

<replicate> : like SMIL only with space instead of time. See for my original description. Here is a brief synopsis:

Just as

<object><animate attributename1 propertylist><animate attributename2 propertylist></object>

succeeds in modifying <object> over time according to the attributes named in its child animations,

how about

<object><replicate attributename1 propertylist><replicate attributename2 propertylist></object>

that would lay out copies of <object> on a page? The number of copies and their positions and attributes would be determined by the property lists (including keyTimes which now becomes keyPlaces?) associated with each attribute.

Editable graphic objects:

Many folks have called for SVG to adopt editable text objects (like textareas). SVG 1.2 full has those, and Opera has already implemented editable text in SVG. The flowing text shapes are coming as well. Basically we want users to have a way to enter and modify strings In SVG.

Well it just makes sense since it is a graphic language that we should allow run time editing of shapes as well.

Any shape marked as editable, should be for the beginning selectable, repositionable, scalable, rotatable and annotatable. The interface for doing this is pretty common from application to applications these days -- Inkscape and some other open software projects are useable and probably available for adoption.

Click on an object -- its boundary becomes highlighted and handles appear. While selected if the mouse is over the object the second click signals the beginning a drag. A click on a handle signals the beginning of a resize, a click outside all of these (but within some radius) signals a rotation. While selected, the delete key remove from DOM.

Just as text folks want to be able to edit text without lots of script, graphics folks probably want to be able to edit graphics without a lot of script. This is SVG, of course.

Editable sound objects:

Ditto all the above arguments for sound. It'd be relatively easy to build in a little SVG sound studio for all embedded sounds, so why not we do it?

Suggestion concerning the status of such speculation

Since the ordinal number of the specs currently under various states of juvenescense are all (to my knowledge) less than 1.3, how about we entitle (in an informal way, appropriate perhaps to an interest group that is not a working group) all such speculative specifications "speculafications" and let us adopt (again in the most informal of ways) an ordinal number for the union of all current speculafications to be equal to the next integer above the current Spec[5] minus an infinitesimal. In this case since the current Spec number is greater than 1 but less than 2, then all such speculations the IG discusses would be labeled SVG1.9999... **[6] At some point in time we might ask the SVG WG to recommend to some committee on committees (a WGWG?) that the official Spec never be numbered with an integer minus an infinitesimal, since that entire countable set of individually infinite strings would be reserved for speculifications.

(Doug, can I have an action item # for resolving the discussion of whether our group's discussion of specs should have a number?)

I conclude with some of my own examples at the end of my recent paper and at the end of my book. Some of these I've talked about already (but some I did not)[7]:

1.       Some types of gradients that are more flexible than just linear and radial would really be handy. The contour gradients of many applications that parallel (or run perpendicular to) a bounding shape might help (certainly for the task of stitching things together into larger smooth textures.) It might be nice to take n user defined points in the plane and to define from that a set of contour lines which would run like altitude lines, around those points providing arbitrary gradient maps over a region.

2.       Transforms of the non-affine sort would certainly be useful. While it is encouraging that one can simulate these, a proper simulation would require too many small regions to be practical. Cylindrical and spherical warps obviously come to mind, but any extension of the conic warp attempted in the section on clipPaths would be useful.

3.       Some types of random noise other than what is provided through feTurbulence could be useful in allowing the class of natural textures that we can construct to expand.

4.       Additional filters (such as one can purchase as add-ons to Adobe Photoshop for example) would be handy. The convolution filters allowed are flexible, but for the average user, things like "plasticize" or "chromatize" might be more straightforward.

5.       Additional 3-D constructs could be added. In addition to non-affine transforms, which some might view as special cases of 3-D constructs, there is currently no compelling standard for 3-D work on the web. Adding a bit of this into SVG might serve to fill a void without stepping on any exposed toes.

6.       Extension of the declarative animation model to include occasional imperative constructs: for example, might we not benefit from having the ability to define random durations or random x-y loci in our declarative markup without having to rely upon script? Likewise, a construct that allows us to specify that a certain object might move in such and such a direction until it encounters an edge or another object, might be quite a powerful extension to the quality of declarative code within SVG.

7.       In conjunction with the posterization of bitmaps, the ability to read color values at given pixel locations back into script is quite important. Likewise, the ability to use a "file upload" capability to bring images from user-drive-space into an SVG application is crucial. It appears that the HTML WG (at least WHATWG) has decided this is to become verboten (perhaps it causes too much work for browser makers to worry about security problems) but in the 15 years that Internet Explorer has allowed it in HTML it seems not to have crashed the Internet. Perhaps SVG could enable this in some way, since the HTML bus seems intent on squashing this ability?

8.       Non rectangular <pattern> spaces. It's clear that most of this can be simulated through rectangular ones. And it is also quite likely that nondeterministic tilings will require script rather than markup for quite some time to come. But SVG could enable the non-programmer to produce interesting visual effects by simply enabling the choice of any of the uniform tilings. Some of these might actually prove to be practical since the hexagonal tiling for example is often used in simulation of battlefield scenarios since distance in that graph is slightly more similar to Euclidean than is distance in square grids.

9.       And of course, we have the simple request that the offset of a text should be expressible as a negative number -- it seems rather inconsequential in contrast to some of the rest of this wish list.

I conclude with some comments from my book that I see do not entirely overlap with the above. How delightful that everytime I think about what SVG needs I come up with something else. That means I don't have to be too concerned if none of this happens in any immediate time frame.

So although I am grateful for the bitmap capabilities we do have in SVG, they are nevertheless, a source of some of what I would like to see added. In truth, my wish list of features to see in SVG may overlap with some of what SVG 1.2 has to offer.

    1. Knowing the color of a particular pixel on the screen. If we could do that then we could not only apply convolution filters to bitmaps to display high contrast edges, but then we could convert the edges back to vectors. I understand that there are potential security issues associated with giving scripts the ability to take pictures of the user’s screen, but Opera 9.0 seems to have implemented a getPixel and setPixel method that allows interrogating and setting pixel values for arbitrary pixels within a <canvas> object in the HTML environment. If we wished to enable desktop image analysis to be done in the browser, then access to pixels will be pretty important.

    2. The ability to deform an arbitrary quadrilateral into another arbitrary quadrilateral (as with the distort tool in Adobe Photoshop™). The affine transformations allowed within SVG 1.1 and 1.2 allow scaling, translation, rotation and skew, which together offer mappings between arbitrary pairs of parallelograms. If we wished to be able to do the morphing of one bitmapped image into another, quadrilateral distortion would seem to be handy. To build something like the "liquefy" filter in Photoshop would likely rely on mesh-based distortions that fall outside the affine transformations currently recommended.

    3. The ability to slice a bitmap into subregions where each subregion is not merely the clip of the entirety If we wish to make large scale jigsaw puzzles, and then scramble the resulting pieces, then numerous copies of the bitmap would likely need to be created using either <clipPath> or <mask>. Either is highly RAM intensive and would require, enormous allocations of memory to perform a fine-grained relocation of small chunks of imagery.

    4. Gradients of varieties other than just linear and radial To create smooth transitions of fill patterns across a variety of shapes or with more than two colors is likely to involve a more complex specification for gradients (such as mesh gradients). To piece together segments of linear and radial gradients to approximate omni-directional gradients has been compared by some to making smooth curves out of line segments – possible, but tedious.

*The IG has made a helpful effort in that direction already with the decision to publish "the book" (representing maybe a person-year's worth of effort) and the WG has demonstrated a strong sense of cooperation as well.

** There is a sort of physics to layout. Containers have volume (as given by their contents); containers have adjacency. Operations on the resizing or repositioning of elements have implications on the pressure and tensile properties of those contents.

For example if we have three polygons meeting at a point and each is filled with a combination of text and graphics, the volume of that content will affect the ways that the containers can be reshaped.  Think of the content as fluid, that is somewhat compressible. Text has limits beyond which compression is not allowed. Graphics have rigidity which affects how much deformation is allowed; while text tends to flow more easily (in the general case), so long as individual characters do not deform too much.

If we generalize the table (as a way of carving rectangles into rectangles) into the <map> (informally, a collection of <superpaths> whose adjacency is determined by the borders they share) then the flow dynamics of that system is a simplified 2-D physics, consisting of elasticity, flexible chains, and rubber bands. I think the <map type=”map”><superpath fill=”href to textual and graphic content”/> <superpath fill=”href to textual and graphic content”/><superpath fill=”href to textual and graphic content”/></map>  approach being discussed at (and on our wiki, presumably sometime) may lend itself conveniently to allow both

a flexible geometry for the planar interrelationships of content, and a fairly easy way to introduce a computationally lightweight physics to allow for the resizing and positioning of contents so as to preserve constraints on how different content may be displayed.

Some pictures can move in x-y but may not be rotated. Others can be deformed but must maintain verticality. In some cases, like in morphing from one scene to another, we wish local deformations to be negligible, for edge/boundary constraints to be preserved, but other than that the content (a bitmap or vector graphic) is quite fluid and stretchable and can deform to fill whatever curve it is poured into (while minimizing turbulence). In some cases we want a string of characters (like the name of a river) to remain quite close to the boundary of a region (whose border is defined by that river).

The notion of deforming a liquid graphic through a volume-preserving and proximity-preserving deformation from any simple closed curve to any other provides a rather flexible metaphor for the class of possible nonrigid transforms. The advantage of such a metaphor, I think, is that it is intrinsically declarative – the user specifies what the beginning and end shapes look like – the computer figures out the rest. Hence it is much in the spirit of SVG itself!

This may or may not be along the lines of what the WG has been discussing; I must apologize for not being a better listener, since I got so excited about putting a physics into this little graph theory (one of my favorite topics) so it may be that the direction you are going is even more general, or that it is considerably more practical, but if <superpaths> can be used for animation, map/boundary encoding, and graph theory, then squeezing page layout out of it would just be icing on the cake!

I think as we scale diagrams down to smaller devices with differing aspect ratios, the demands on scaling placed by our semantics, can at least partially be represented by a simple physics.