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

Replying to my own message here with some more thoughts ...

I'm wondering if it might not be worth creating core widgets that just bundle references to other pieces. For instance, suppose that you had a core button widget class defined within an SVG widget namespace as:

<svg:svg    xmlns:svg=" http://www.w3.org/2000/svg " 
                xmlns:svgw=" http://www.w3.org/2000/svg/widgets "
                xmlns:xlink=" http://www.w3.org/1999/xlink " version="1.2">

...
<svg:g id="buttonNormalState"...>...</g>
<svg:g id="buttonHiState"...>...</g>
<svg:g id="buttonDownState"...>...</g>

<svgw:buttonClass width="100" height="200" id="buttonTemplate" register="button">
    <svg:param name="labelData">Placeholder Text</svg:param>
    <svg:param name="iconData" select="myImage.jpg"/>
    <svgw:label style="font-size:14;font-family:Arial" select="$labelData"/>
    <svgw:icon xlink:href="{$iconData}" x="0" y="0"/>
    <svgw:mouseover xlink:href="url(#buttonHiState)">
    <svgw:mouseout xlink:href="url(#buttonNormalState)"/>
    <svgw:mouseup xlink:href="url(#buttonHiState)"/>
    <svgw:mousedown xlink:href="url(#buttonDownState)"/>
</svgw:buttonClass>

<svg:use xlink:href="#buttonTemplate" onclick="doAction1()" id="button1">
    <svg:with-param name="label">First Button</svgw:with-param>
</svg:use>

<svg:use xlink:href="#buttonTemplate" onclick="doAction2()" id="button2">
    <svg:with-param name="labelData">Second Button</svgw:with-param>
    <svg:with-param name="iconData" select="newIconImage.png"/>
</svg:use>

</svg:svg>

The <svgw:buttonClass> object would define the core functionality for a button by defining the states that would be used for each of the event conditions (mousedown, up, over and out), and by also defining a label item that would be included at the base of the button. Note here the use of the <svgw:param> element, which basically would let users define parametrically the content they needed to customize individual buttons. This arises because I've found when creating buttons that you have the button state indicators (such as inset or outset borders) that are common to each button created in a group, but you may also have an icon and/or descriptive text that varies from one button to the next. The parameterization mechanism (borrowed from XSLT) would let users pass in XML content into the instantiated button object.

This of course raises the whole issue of being able to define more complex class entities in SVG - the <svgw:buttonClass> has been previously defined in the above piece, but it would make sense to have a mechanism to do this for custom widgets as well. This has been one of the pieces that has bothered me about SVG -- the lack of parameterization and the ability to create more abstract entities. The parameterization capability would act independently of the svgw: namespace (which is why I placed it in the svg: namespace). 

-- Kurt Cagle



  ----- Original Message ----- 
  From: Kurt Cagle 
  To: svg-developers@yahoogroups.com 
  Cc: www-svg@w3.org 
  Sent: Sunday, November 17, 2002 12:12 AM
  Subject: 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.