Re: [svg-developers] Re: some discussion of SVG 1.2

I think the secret behind developing base "widgets" in the XForm sense is to 
look at what would be the minimum necessary functionality necessary to 
implement a base level widget that can be adopted for use. For instance, both 
a standard editable text field and text area field a la HTML would be 
considered de rigour, but the functionality here is in the "editable" 
characteristics. If you could readily create an editable="yes" attribute on a 
<text> element, for instance, this complies with the minimal requirements 
while still letting people develop richer visual appearance and 
funcationality. Similarly, a scroll bar may be as simple as saying:

<path d="m0,0 ...." id="scrollpath"/>
<circle id="thumb" constrainToPath="url(#scrollPath)" position="0.3"  ... />

This would basically create a path that would act as the constraint for 
movement -- you could move the circle along the path by dragging it, but 
would be unable to move it off that path. The position attribute would be 
normalized, so that position="0.0" represents the beginning of the path and 
position="1.0" represents the end of the path, in essence giving you a 
parametric means to represent the actual position without having to go 
through  potentially complex calculations.

Similarly, 

<circle id="constraintRegion" .../>
<circle id="thumb" constrainToRegion="constraintRegion" ../>

would make it possible to keep an element exclusively within the constraint 
region in response to drag operations. 

I'd think strongly about implementing XPath 2.0 as a reference mechanism 
within SVG. For instance, the animation block:

<set attributeName="fill" attributeType="CSS"  to="red" fill="restore"
begin="(//rect[@ex:type='stepBox']).mouseover" 
end="(//rect[@ex:type='stepBox']).mouseout"/>

would cause the encasing element's fill to go red any time ANY rectangle with 
an external namespace attribute of ex:type holding the value 'stepBox' is 
rolled on, and will release the fill whenever such a box is left.

Just a few thoughts. I like the direction I see for SVG 1.2. I think it 
solves a few of the bigger holes in the SVG language.

-- Kurt Cagle


On Saturday 16 November 2002 03:34 pm, you wrote:
>  Thank you for useful comments. See some questions below.
>
> --- In svg-developers@y..., "Ruud Steltenpool" <r.g.steltenpool@s...>
>
> wrote:
>  > 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 :-(
>
> Actually the question is not even what the syntax would be, but how
>  it should be defined in terms of rendering and should it be "local"
>  or "global". Consider this example (suppose all rects partially
>  overlap each other):
>
> <g opacity="0.5" clip-path="...">
>    <rect id="A".../>
>    <rect id="B".../>
>  </g>
>  <rect id="C".../>
>
> Now rectangle B completely obscures A where it covers it and
>  C obscures both A and B. Also A and B are semitransparent
>  because of the group opacity. Now, suppose I added z-order="1"
>  on the rect B. What should happen? Will B render on top of
>  C? Will it be semitransparent? Will it honor group clipping? Will
>  it still completely obscure A? Now add filter effects and
> use element in the mix and try to go through these questions
>  again. Note that I have not posted these questions here just as
>  illustration to the complexities of the z-order within rich
>  rendering model, they meant to be answered!
>
> BTW, you might want to CC your comments to www-svg@w3.org, and
>  give it more explicit subject like "SVG 1.2 FEEDBACK".
>
> Peter
>
>
>
>  -----
>  To unsubscribe send a message to:
> svg-developers-unsubscribe@yahoogroups.com -or-
>  visit http://groups.yahoo.com/group/svg-developers and click "edit my
> membership" ----
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Received on Sunday, 17 November 2002 11:38:39 UTC