W3C home > Mailing lists > Public > www-svg@w3.org > February 2001

SVG Spec. Suggestions

From: Neil Stansbury <nstansbury@m85.com>
Date: Mon, 12 Feb 2001 11:44:45 +0000
Message-Id: <sa87ccc6.053@m85.com>
To: <www-svg@w3.org>
Hi all,

I am relatively new to XML, and even newer to SVG, but having read through the current spec, I would like to make some suggestions.  Apologies in advance if they are not relevant, miss the point, or don't work within the the DOM ;-)

I would describe myself as a fairly competent Flash developer, and so I am approaching the SVG specs from 3 points.

1. What I always thought MMFlash should do, but didn't
2. What I personally would want any standard Vector Graphics implementation to do.
3. That SVG is not "just another static graphic spec", and interactivity is a major portion of the standard.

As such I have a couple(?) of suggestions.

Firstly I would like to suggest 2 new elements, and 2 new attributes.  The reasons below, but I believe the vast majority of developers will use them. (excuse the syntax in the examples :-)

1. "Change the "Visibility" attribute to allow "0|1|2" as follows:
  "0" - Element is visible and accepts pointer events
  "1" - Element is invisible and does not accepts pointer events
  "2" - Element is invisible and DOES accept pointer events.

Many users will require invisible buttons etc (See point 7), and from what I have seen rendering opacity is one of the most processor intensive tasks, especially if a colour is 
changed below an object and multiple opacities have to be re-rendered.  This would allow just a shape, and visibility to be set to "2", to keep this elements code small, and 
rendering minimal.

2. Allow any element to have an attribute of "locked"

An example is probably easiest here.  I define a "rect" with a "stroke-width:20.0" "fill:black".  I   want the rectangle to scale, but I want my stroke-width to stay the same.  I would like to  propose an attribute that allows an element to have specific attributes "locked", so that control can be placed on what scales and what doesn't.  Eg.  Resize you browser, the window expand,  the icons, text, and borders don't.

3. Similar to the <g> element define a <button> element as follows:

<button type="COO|COCO" (Click On/Off, Click On/Click Off)
default rect: fill: etc
StateOver: rect: fill: etc 
StateRelease: rect:  fill: event:javascript call, etc etc

I know this can be done with js and css/xsl, however to do the same requires far more than five lines of code, and _everybody_ will use buttons.  I know the CSS principle is to separate style from content, but I believe this is an important exception, especially if this were defined in external libraries (see point later).

4. As above example, but now <ProgressInd>:
<ProgressInd type="0|1|2"> (0= ProgressBar, 1=Increment text, 2=both)
not quite sure on the syntax here ;-(  Again to produce a proper progress indicator in JS is a nightmare of code, and I think important enough.  Also there is no way to actually monitor what elements have been downloaded.  I know you can do a progressive display, but that is not the same as defining a "do while"/"do until" type event on individual elements.

5. (This might be possible already) Symbols & Libraries.  I want to be able to define my own external symbol libraries, and manage these separately.  For example, I create a site wide Symbol Library, where I can define all buttons, animations, and general graphics used regularly. From any SVG file I can reference this external entity (like an external DTD), and then manipulate the external symbols within the actual SVG file.  This means my symbol library is separate for manageability, once downloaded is within either browser or a  local cache, and keeps each SVG file as small as possible as it only concerns itself with managing a symbols instance, rather than redefining it every time from within a the file's internal subset.

It also means I can easily share my libraries, with others, and totally change the look of an entire site by changing the single library reference - kind of CSS on speed.  Also I don't understand why the spec doesn't support "sprites".  Being able to store _all_ relevant code in one external file (including js) would be fantastic.

6. In relation to above.  One of the best features of the spec I think is the "view box" concept.  A number of important points though.  I want to be able to define a new "layer" as a "view box" but then fill it's contents from an external library. That way previously defined graphics are a breeze as they are all relative.

7. In relation to the "Visibility" attribute I suggested, an example use for it.  I want to define a particular area as "draggable"/ or magnifyable.  Thus with a <g> element, my top object is an invisible shape, that sets the draggable area for the whole <g>.  The magnify attribute would allow me to specify a draggable invisible element, but then just magnify what the element was over.  Kind of like moving a magnifying glass over a map.  You can still see the magnifiction in relation to the larger context.  Again you don't have the processor overhead of rendering opacity

8. Timelines.  I accept that javascript will provide timeline functions for those that need it, but again javascript generates a large quantity of code for a relatively simple task, wouldn't it be simpler (and faster) to build the capability into SVG and let the viewer handle it.

9.  One of the things that always annoyed me about Flash was the Canvas was never an object in its own right.  Which meant you can't define a gradient as a Canvas colour, or even set it as transparent.  The later then requires careful consideration for positioning of large movies. Thus the entire canvas would be allowed to be transparent, from its stage.  eg. A large graphic over an entire web page.

10.  I know this can be done in IE with javascript, but allowing direct control of the "Right Click" plugin menu would be great, or specifically allow custom right click menu generation, again a fair amount of work in JS.

7. 3D.  I know the spec specifically says 1D and 2D Graphics, but 3D work in Flash required an awful lot of effort.  If SVG is going to become the dominant vector format, surely it is better to define a way to express an element in 3D space, rather than people develop proprietary solutions to do it.  Maps would be the immediate beneficiary.

8.  I mentioned CD browsers, something we use Flash for fairly regularly (as do others), I haven't seen anything in the spec that addresses any of those particular issues.  (I'm not sure what those might be - but I'm sure there must be some ;-)

9. Components.  On large interfaces, large quantities of information may not be need until a specific event occurs.  I can't see a way to insert additional elements in the existing document based on that event.  By this, I don't mean external symbol libraries, I mean dynamically inserting other SVG documents.

10. Why does the <polyline> element just not have an attribute of: closepath="boolean", rather than define a whole new element <polygon>?

11. In the spirit of XML as simple and self describing, why define the group element as <g> rather than <grp> or <group>?

12. For the same reasons above, what does <defs> stand for / mean?

13. I have now wish to sound petty but... In the spirit of internationisation. Why is colour spelt "color".  The spec defines both the following colour keyword names:

lightslategray rgb(119, 136, 153) 
lightslategrey rgb(119, 136, 153)

  "Grey" is the correct english, which is to be used?

14. There is doesn't appear a set ability to "Tab" around rendered elements in a specified order for mouseless operation.

15. Whilst "onactivate" allows for keyboard activation.  Any use of "onmousedown" or "onclick" precludes any keyboard activation, can the "onactivate" event not be implied in certain circumstances to reduce multiple event code?

Just some thoughts, hope they're useful.


Neil Stansbury
Field Consultant
Mission Communications

Ph: +44 (0)20 8424 8815
Fx: +44 (0)20 8424 8813

 T e c h n o l o g y  f o r  e B u s i n e s s*
Confidentiality Notice:
This information is intended only for the use of the named 
recipient. Internet communications are not neccesarily 
secure and therefore Mission does not accept legal responsibility
for this message or its contents.  If you are not the intended
recipient, please notify us immediately and then delete this document. 
Do not disclose the contents of this document to any other person, 
nor take any copies.  Violation of this notice may be unlawful.
Received on Monday, 12 February 2001 07:45:30 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:20 GMT