some discussion of SVG 1.2

http://www.w3.org/TR/SVG12 :
At the time of publication, the Working Group is undecided as to whether or
not the SVG specification should describe a default rendering and behavior
for some form elements, such as buttons and sliders. We realise that
creating widget sets is a deep topic and specifically request feedback on
this matter. Would a simple set of form widgets be sufficient in most
situations, or would authors prefer to always create the SVG rendering and
behaviour for every element?

comment:
I think to make it easy to develop there should be a default.
Some people hate different: give them the option to very easily use widgets
that are the same as in their webpages or applications
(1 look at Swing from Java,
2 the window-manager from the OS, might provide you with options to what
that default is, skins, etc.)
Some people like new and different: they can create their own widgets


http://www.w3.org/TR/SVG12 :
The Working Group has not reached a conclusion on the requirements for such
a feature. Should the mapping be one way or two way (ie. should there be a
way to automatically reflect changes in the transformed content when the
transformation is updated?) Should the feature be enabled by the styling
system (ie. should you be able to apply a style rule that converts all
myns:pie elements into a combination of svg:path elements?) Is this an
extension to the 'use' element?

comment:
XSLT is nice, but that's it.
I don't see the connection with 'use'
I think you should look at MVC (Model View Control) from Java for some
insight

more comment:
Here's an example i thought of for a project of my own (looks like MVC
combined with SVG):
There are DOM-objects that represent a thing in a namespace, with special
Script commands associated with it for that namespace. (that's the M from
MVC)
When they are loaded in the application a corresponding SVG-object is
created that also has special Script functions and of course event-listeners
combined with it to create a context-sensitive visual editing especially for
the namespace of the objects that are represented. (parsing)
With this system you can have more than just one representation: you can
have a different SVG-presentation with some other context-specific settings,
you can just have multiple of the same, you can have one with different
CSS-properties, but you can also have a view (the V from MVC) that is a form
in HTML, or a JTree in an applet or application, or a syntax-colored
namespace-specific source-view .



http://www.w3.org/TR/SVG12 :
The SVG Working Group requests feedback on this feature, especially any
specific requirements you may have. SVG 1.2 plans to enable a drawing order
independent of document order, a feature commonly referred to as Z index.
This feature is in very early development - there are no further details at
the moment

comment:
If the z-index is not only an option, but obligatory and would take only
integers this would change the z-system from relative in SVG 1.0 to worse
than absolute in SVG 1.2 :  If you need a z-index between 7 and 8, but only
integers are allowed, you need to renumber :-(

Received on Friday, 15 November 2002 23:07:51 UTC