severage-isvg — discussions of the iSVG extension language

[iSVG] XML.com articles

[Antoine Q. <an...@gr...>]

Hey guys,

Sorry this list have been so quiet lately, fact is I've got no clue what
the future holds for iSVG. I've got some stuff ready to go and have tons
of plans for loads of other things, but the old work issue is still
holding back further developments. One thing I will definitely ne doing
though is an XML.com column on interactive SVG (yay!).

I would like to know if you guys have suggestions on things you would
like to see covered. I'm kinda sure the first paper will be just
illustrating simple SMIL and DOM, but after that we'll move to nicer
things. So give it up if you've got some cool stuff.

Antoine

Re: [iSVG] i:version

[Robin B. <ro...@kn...>]

On Tuesday 09 October 2001 02:39, Dean Jackson wrote:
> Bonjour toute le monde!

Hi Dean ! I had no idea you were hanging around here :-)

> Je dois fair des excuses pour le francais ne
> parlant pas tres bien.

Mais si, c'est tout a fait excellent. Sorry for posting in French earlier, I 
thought we were still in covert mode...

> Do you guys plan to incorporate all of kSVG into
> iSVG? Do you have any other examples/demos? Antoine
> sent me iDrag.

Yes, all of kSVG (and much more) is going into iSVG.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
A Priest, a Minister, a Rabbi, a Feminist, an Irishman, an Elephant,
and a Gorilla walked into a bar. The Bartender said, "What is this, 
some kind of joke ?"

Re: [iSVG] i:version

[Dean J. <de...@w3...>]

Bonjour toute le monde!

Je dois fair des excuses pour le francais ne 
parlant pas tres bien.

...<cough>.. english.. that's much better :)

Do you guys plan to incorporate all of kSVG into
iSVG? Do you have any other examples/demos? Antoine
sent me iDrag.

Dean


On Mon, 08 Oct 2001, Robin Berjon wrote:

> Hi guys,
> 
> comme il faut toujours versionner les langages (enfin ca aide) je viens de 
> creer un attribut i:version. Il est inherite a tous les descendants de 
> l'element sur lequel il est place et peut etre localement override. Ca sera 
> peut-etre pratique un jour (pour l'instant ca ne fait rien) si on introduit 
> des syntaxes non-backward compatible.
> 
> J'ai decide de le mettre a 0.2.0 pour la version presente, en considerant que 
> le kSVG etait la version 0.1.0.
> 
> -- 
> _______________________________________________________________________
> Robin Berjon <ro...@kn...> -- CTO
> k n o w s c a p e : // venture knowledge agency www.knowscape.com
> -----------------------------------------------------------------------
> The human brain is a wonderful thing, but it is also a result of 
> three billion years' worth of "good enough" implementation. As a 
> result, it is a giant hack with more than a few quirks.
> 
> 
> _______________________________________________
> SeVeraGe-iSVG mailing list
> SeV...@li...
> https://lists.sourceforge.net/lists/listinfo/severage-isvg

[iSVG] i:version

[Robin B. <ro...@kn...>]

Hi guys,

comme il faut toujours versionner les langages (enfin ca aide) je viens de 
creer un attribut i:version. Il est inherite a tous les descendants de 
l'element sur lequel il est place et peut etre localement override. Ca sera 
peut-etre pratique un jour (pour l'instant ca ne fait rien) si on introduit 
des syntaxes non-backward compatible.

J'ai decide de le mettre a 0.2.0 pour la version presente, en considerant que 
le kSVG etait la version 0.1.0.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
The human brain is a wonderful thing, but it is also a result of 
three billion years' worth of "good enough" implementation. As a 
result, it is a giant hack with more than a few quirks.

Re: [iSVG] CSS DOM issues

[Robin B. <ro...@kn...>]

On Friday 28 September 2001 17:35, Antoine Quint wrote:
> Well, it's good to have these too. 

s/good/vital/ ;-)

> My example is not simply shortcut to
> your piece of code.

It is a shortcut in that that's what would happen internally if you fed it a 
string.

> We need a Create* method taking a string as a
> parameter so that any string, possibly one read in a non-"style"
> attribute like in iDrag, can benefit from the CSSStyleDeclaration
> interface. It would allow us for parsing such a string, your example
> relies on the string being parsed already really. But what's in your
> example is required too since we need to be able to create style objects
> in such a verbose way too.

Yes, I know your needs Antoine, and I agree. If this were my implementation 
in a sane language (ie that either doesn't have method signatures OR has them 
_and_ multiple dispatch, anything in the middle being just plain stupid) it 
would happen this way.

However in this context I doubt that there will be a 
createCSSStyleDeclaration() and a createCSSStyleDeclarationFromString(string).

The talk that's going on right now seems to imply that parsing facilities may 
be made available (eg parseCSSStyleDeclaration as it exists in SAC: 
http://search.cpan.org/doc/RBERJON/CSS-SAC-0.03/SAC.pm , I keep referring to 
my module for the spec but that's because the spec is quasi inexistant) in 
which case you could do what you do with a stream model and without touching 
the actual object model (which would be a problem).

Another solution that I've been thinking about is a way to tell the host DOM 
that a given attribute is a style holding attribute. Yes, this should have 
made it into XSchema but they preferred to fuck with namespaces instead and 
leave us with a number of awful things. It might be in XSD 1.1 though (xing 
fingers...). In any case a way to set it from the DOM would be great.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
Forty two.

Re: [iSVG] "actuate" attribute on <i:drag> element

[Robin B. <ro...@kn...>]

On Friday 28 September 2001 16:08, Antoine Quint wrote:
> Kev (list-member !!!) suggested that it'd be nice to have the
> possibility to have drag changes applied when you click on the object
> rather than when you actually drag it.

This is totally necessary.

> What about doing something like:
>
> <i:drag actuate="onmousedown"> or <i:drag actuate="ondrag"> where
> "ondrag" would be the default value.

I think this is *not* going far enough. If possible -- and I think it is -- 
drag should be totally ignorant of how or why it is being selected.

What we want is an i:select module. The i:select module would be an 
intermediate between the selector (which is usually a mouse, but can also be 
for instance the key board: windows users, pick a non-fullscreen window, hit 
Alt+Space, arrow-down and select move, then move around with your arrow keys. 
Esc to stop, Enter to confirm. KDE users select move from the icon menu and 
do something similar. Other users do whatever) and the object, which we know 
can be anything but is taken care of by i:drag (in this case).

Having an i:select module would give us lots of benefits. First, it would 
take care of the actuate problem described above, which is likely to occur in 
other modules (buttons, pan, whatever). I would also allow us to do very 
nifty things like multiple selection.

An ugly but interesting example of this (for IE5+) is at 
http://www.microsoft.com/japan/developer/workshop/author/dhtml/dude/dude092298.asp 
. Forget the language (well, unless you can read it) and scroll down to 
"Drag-and-Resize example".

Right now multiple-selection would be painful to add to i:drag, and again 
we'd have to add it everywhere we need it.

Instead, any event occuring on an object that's part of the selection (stored 
in an dictionary by the i:select module) would be dispatched to all objects 
in the selection as if they were receiving it directly. For window-like 
objects we probably don't care too much, but for a drag-and-drop system 
(which is where i:drag is heading) it would be marvellous.

It would also take care of solving the problem of selecting overlapping 
objects. The default would be to take the one on top, but it could have an 
option to put up a menu (or something) listing the i:selectable object under 
the pointer, when there are several.

And of course, if we added new actuate styles, they'd be available to 
everything, and able to throw their own events (eg onfocus, which would be 
very cool for i:form if we decide to do it).

If any of you know some expert of GUI toolkits, I'd be interested in knowing 
how they do it there.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
Suicidal twin kills sister by mistake! 

RE: [iSVG] CSS DOM issues

[Antoine Q. <an...@gr...>]

> > First off, we need a method to give a string access to this 
> interface's
> > methods. Like
> >
> > var string = 'fill: red; opacity: 1';
> > var CSSString = doc.createCSSStyleDeclaration(string);
> 
> We need create* (preferably on CSSImplementation, or on 
> specific Factory 
> interfaces) for everything (SAC has those). Your above 
> example could be a 
> shortcut, but I would much prefer:
> 
> // RGBCOLOR and REAL are constants defined in SAC
> var CSSDecl = factory.createCSSStyleDeclaration();
> var redLU = factory.createCSSLexicalUnit(RGBCOLOR, 'red');
> var CSSDecl.addProperty( 
> factory.createCSSPropertyValue('fill', redLU) );
> var opaLU = factory.createCSSLexicalUnit(REAL, 1);
> var CSSDecl.addProperty( 
> factory.createCSSPropertyValue('opacity',opaLU) );

Well, it's good to have these too. My example is not simply shortcut to
your piece of code. We need a Create* method taking a string as a
parameter so that any string, possibly one read in a non-"style"
attribute like in iDrag, can benefit from the CSSStyleDeclaration
interface. It would allow us for parsing such a string, your example
relies on the string being parsed already really. But what's in your
example is required too since we need to be able to create style objects
in such a verbose way too.

We just need both really.

Antoine

Re: [iSVG] CSS DOM issues

[Robin B. <ro...@kn...>]

On Friday 28 September 2001 16:02, Antoine Quint wrote:
> The CSSStyleDeclaration interface could be improved.

You bet.

> First off, we need a method to give a string access to this interface's
> methods. Like
>
> var string = 'fill: red; opacity: 1';
> var CSSString = doc.createCSSStyleDeclaration(string);

We need create* (preferably on CSSImplementation, or on specific Factory 
interfaces) for everything (SAC has those). Your above example could be a 
shortcut, but I would much prefer:

// RGBCOLOR and REAL are constants defined in SAC
var CSSDecl = factory.createCSSStyleDeclaration();
var redLU = factory.createCSSLexicalUnit(RGBCOLOR, 'red');
var CSSDecl.addProperty( factory.createCSSPropertyValue('fill', redLU) );
var opaLU = factory.createCSSLexicalUnit(REAL, 1);
var CSSDecl.addProperty( factory.createCSSPropertyValue('opacity',opaLU) );

It's more verbose but it means that you're now manipulating PropertyValue 
objects, which in turn means that they are what will be returned by 
CSSDecl.item(i), and that would have getName, getType, getValue, and a 
variety of things from 
http://search.cpan.org/doc/RBERJON/CSS-SAC-0.03/SAC/LexicalUnit.pm

I prefer verbosity to uselessness. I guess I won't get much argument here.

> Right now, I have to use a non-appended node to which I
> createAttribute('style', string). Then I get my CSSString through
> getStyle and removeAttribute('style'). This is just annoying.

Yeah I know. It's not only annoying, it's a filthy dirty hack (curtesy of 
yours truly). I'm afraid there's no better solution in CSS DOM level 2.

> That's it.

Oh, I'm not so sure that's it. You'll probably hit a few other walls along 
the way :-)

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
"Oh no not again !" said the bowl of petunias

[iSVG] iDrag syntax changes

[Antoine Q. <an...@gr...>]

Hey,

Looking back, I was wondering if the XML grammar used for iDrag was
appropriate... Consider this piece of code:

<i:drag bringToFront="yes">
  <i:style ondrag="opacity:0.5" />
  <i:style xlink:href="#iDragText" ondrag="fill: #ff00ff; opacity: 1;"
/>
  <i:text xlink:href="#welcomeText" ondrag="SeVeraGe's my pal !!!" />
</i:drag>

I was wondering if it wouldn't be better done using this syntax:

<i:drag bringToFront="yes">
  <i:set actuate="ondrag" style="opacity:0.5" />
  <i:set xlink:href="#iDragText" actuate="ondrag"
         style="fill: #ff00ff; opacity: 1;"
         text="SeVeraGe's my pal !!!" />
</i:drag>

This way it's more of a target-oriented syntax (one "set" element per
object for both types of changes - text and style) rather than
action-oriented (text or style).

Please advise as this would mean some rather dramatic changes in the
syntax and in the implementation. And I want the release to be real
soon.

Antoine

[iSVG] "actuate" attribute on <i:drag> element

[Antoine Q. <an...@gr...>]

Hey,

Kev (list-member !!!) suggested that it'd be nice to have the
possibility to have drag changes applied when you click on the object
rather than when you actually drag it.

What about doing something like:

<i:drag actuate="onmousedown"> or <i:drag actuate="ondrag"> where
"ondrag" would be the default value. 

Another possibility, that would be allowing for more flexibility, would
be to allow an "onmousedown" attribute on <i:style> and <i:text>
elements. This way, some changes could be made ondrag and others
onmouseover.

What do you think?

Antoine

RE: [iSVG] CSS DOM issues

[Antoine Q. <an...@gr...>]

Hey,

The CSSStyleDeclaration interface could be improved.

First off, we need a method to give a string access to this interface's
methods. Like

var string = 'fill: red; opacity: 1';
var CSSString = doc.createCSSStyleDeclaration(string);

Right now, I have to use a non-appended node to which I
createAttribute('style', string). Then I get my CSSString through
getStyle and removeAttribute('style'). This is just annoying.

Other thing that I would like is a change to this interface.

CSSStyleDeclaration::item(n) returns the name of the n-th property in
the CSS string. I wish it returned an object that would have methods
like getPropertyName() and getCSSValue() or something like that.

That's it.

Antoine

[iSVG] CSS DOM issues

[Robin B. <ro...@kn...>]

Hi guys,

I've been talking with Bjoern Hoehrmann, as well as a little with Bert Bos, 
about the fact that CSS DOM sucks quite bad and doesn't have the richness of 
CSS SAC, which in turn is a non-maintained and rather incomplete Note.

Management of the CSS DOM having been transferred from the DOM WG to the CSS 
WG for the creation of level 3, we feel that this is the moment to list 
issues and start finding solutions (notably merging the part of SAC that is 
an CSS Object Model much more than an event stream into DOM).

Our first step is to collect issues, so as you guys may be involved in a lot 
of manipulations of the CSS DOM (especially Antoine so far that has hit a few 
walls already) I'm asking you every time you bump into something to send the 
issue to me. That'll help lots in establishing a roadmap.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
In which level of metalanguage are you now speaking?

[iSVG] iDrag release candidate -> the code

[Antoine Q. <an...@gr...>]

Hey,

If some of you want to take a look at the code too, it's all in there in
this zip archive. Take care,

Antoine

[iSVG] iDrag release candidate

[Antoine Q. <an...@gr...>]

Hey,

Before we publicly release the first iSVG module (iDrag) on the SeVeraGe
project page, I would like to gather some feedback from all you people.
The demo SVG for the iDrag module is located at:

http://www.graougraou.com/iSVG/demo/drag.svg

You will need Windows / Mac with a browser and the Adobe SVG Viewer v3.0
beta available at: 

http://www.adobe.com/svg/viewer/install/beta.html

Sorry for the lack of documentation for now but it's coming too. Direct
any question to me.

Robin and I have to work out a way to compile all the required modules
into one big gzip, hopefully we'll get that sorted out tomorrow. I guess
we can look at a weekend release for this one. Thanks y'all,

Antoine

[iSVG] New #severage IRC channel

[Antoine Q. <an...@gr...>]

Hey,

A new #severage channel has been registered on irc.openprojects.net for
discussion of SeVeraGe-related topics. You are all welcome to join!

Antoine

RE: [iSVG] Methods or properties?

[Antoine Q. <an...@gr...>]

 
> If you read the docs, Adobe voted for us. Using accessors is 
> the only way to 
> be fully portable and cross-platform. This is because of the 
> limitations of 
> certain platforms, amongst which Netscape of course. v3 
> changes that with its 
> embedded interpreter, but its still better not to take chances.
> 
> I vote for accessors.

Ok, though I must say that the iSVG code has been developed using
Adobe's engine. This is I managed to get rid of the init(evt) call for
instance. This won't matter since the code makes use of DOM methods only
implemented in ASV 3.0 and that this document property will also be
accessible in any native SVG vrowser (like mozilla). So the code will be
very portable (if mozilla supports the required standard methods).

antoine

Re: [iSVG] Methods or properties?

[Robin B. <ro...@kn...>]

On Thursday 20 September 2001 21:45, Antoine Quint wrote:
> First off all, let's all celebrate waving goodbye to the awful
> onload="init(evt)" call on the <svg /> element. Now setting up and iSVG
> document is even simpler.

Hurrah !!

> And now for the BIG questions... Who votes for using methods and who
> votes for using properties? Here's what I mean... Do we write
>
> node.getBBox().x
>
> Or
>
> Node.getBBox().getX() ?
>
> I have been using the latter in my code, but I'm listening to
> suggestions...

If you read the docs, Adobe voted for us. Using accessors is the only way to 
be fully portable and cross-platform. This is because of the limitations of 
certain platforms, amongst which Netscape of course. v3 changes that with its 
embedded interpreter, but its still better not to take chances.

I vote for accessors.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi

[iSVG] Methods or properties?

[Antoine Q. <an...@gr...>]

Hey,

First off all, let's all celebrate waving goodbye to the awful
onload="init(evt)" call on the <svg /> element. Now setting up and iSVG
document is even simpler.

And now for the BIG questions... Who votes for using methods and who
votes for using properties? Here's what I mean... Do we write

node.getBBox().x

Or

Node.getBBox().getX() ?

I have been using the latter in my code, but I'm listening to
suggestions...

antoine

RE: [iSVG] weyyy

[Antoine Q. <an...@gr...>]

> I tried to view http://www.fuchsia-design.com/, but it 
> complained about not having an 'svg+xml' plugin or something.

Which is the correct behaviour since I'm using an awful <embed /> tag
with a pluginspace registered (for the Adobe SVG Viewer plugin, although
it has no importance in that case). Since I have specified the mime type
of the embed to "image/svg+xml", it looks rightfully for a plug-in
handling such a mime type. On top of that, Mozilla SVG has no support
for animation.

antoine

Re: [iSVG] weyyy

[Julien Q. <Jul...@im...>]

On Thu, Sep 20, 2001 at 08:01:18PM +0200, Robin Berjon wrote:
> > Since the audience of the list is so small for the moment, I guess I =
can
> > post just to say that I finally got Mozilla 0.9.4 to compile with SVG
> > support under Linux... It looks quite neat for the moment!
>=20
> Duuuuude, you're so cool.
>=20
> I've gotta try the same thing, anything I should know ?

This is what I did:
  + got the source with CVS, using the branch SVG_20010721_BRANCH
  + configured with the following options:
      --enable-strip-libs
      --disable-debug
      --enable-optimize=3D-O2
      --enable-svg
      --enable-mathml
    there may be some more that are useful unless you want debug info, et=
c.
  + configure complained about my version of libarts (2.2 or something), =
so I
    had to get it from the Gnome CVS repository, as the lastest tarball w=
as
    too old (see http://www.artofcode.com/libart.html), you need version =
2.4.4
    at least (got version 2.4.5 from the CVS repository)
  + launched make... waited about one hour... and voil=E0 !

Issues: not sure about the MathML support; it doesn't look like it's doin=
g
much. I tried to view http://www.fuchsia-design.com/, but it complained a=
bout
not having an 'svg+xml' plugin or something. Most of the test from the
croczilla page seemed allright (a couple glitches here and there).

So this is not too hard, really... but some patience is required.

Julien

Re: [iSVG] weyyy

[Robin B. <ro...@kn...>]

On Thursday 20 September 2001 19:30, Julien Quint wrote:
> Since the audience of the list is so small for the moment, I guess I can
> post just to say that I finally got Mozilla 0.9.4 to compile with SVG
> support under Linux... It looks quite neat for the moment!

Duuuuude, you're so cool.

I've gotta try the same thing, anything I should know ?

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi

[iSVG] weyyy

[Julien Q. <Jul...@im...>]

Since the audience of the list is so small for the moment, I guess I can post
just to say that I finally got Mozilla 0.9.4 to compile with SVG support under
Linux... It looks quite neat for the moment!

Julien

Re: [iSVG] Adobe's current DOM support

[Robin B. <ro...@kn...>]

On Tuesday 18 September 2001 22:14, Antoine Quint wrote:
> Robin said a bit earlier off list that DOM support in v3.0 beta 2 of
> Adobe's SVG Viewer was nearly complete. Well, there's one thing that's
> not in there and that we need : the enclosure and intersection methods.
> Those will be essential in the drag'n'drop module for checking when we
> hover targeted elements ondrag and stuff.

That's a pity, but anyway I've been developping a set of helpers to do just 
that. I need it for the selection stuff, so that if several objects are piled 
on top of one another, instead of dragging them immediately you get a small 
menu asking you which one you want (or something like that).

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi

[iSVG] Adobe's current DOM support

[Antoine Q. <an...@gr...>]

Hey,

Robin said a bit earlier off list that DOM support in v3.0 beta 2 of
Adobe's SVG Viewer was nearly complete. Well, there's one thing that's
not in there and that we need : the enclosure and intersection methods.
Those will be essential in the drag'n'drop module for checking when we
hover targeted elements ondrag and stuff.

Also, I am amazed by how cool addEventListener() is. It leaves the DOM
tree unchanged when you copy SVG from the plug-in. It's just like black
magic! Pretty 37331, so g00d for u5!

antoine

Re: [iSVG] Split bug in Adobe SVG Viewer?

[Robin B. <ro...@kn...>]

On Tuesday 18 September 2001 20:19, Antoine Quint wrote:
> > Have you turned on notification of new subscriptions ? I'd
> > like to know about
> > it if Bob joins ;-)
>
> Yes, if Bob is DiBlasi, his posts will be moderated!!!

I was thinking about the river one. But yes, moderate all the gremlins fr=
om=20
svg-dev.

> > If you don't mind testing the version I gave you that adds a
> > method to the
> > String interface it'd be great. I'd love to know whether that
> > approach works.
> > Using that we'd be able to have very readable and clean code.
>
> Well, if there is no way to do it with split, then it's going back in
> the code!

Yes, but I was thinking specifically about the first one of the two that =
I=20
gave:

/* this is totally untested, but it would be great if it worked */
function isvgNonNumericSplit () {
=A0 =A0 var preClean =3D new Regexp('^\D+');
=A0 =A0 var postClean =3D new Regexp('\D+$');
=A0 =A0 this.replace(preClean, '');
=A0 =A0 this.replace(postClean, '');
=A0 =A0 return this.split('\D+');
}
// add to the interface
String.prototype.isvgNonNumericSplit =3D isvgNonNumericSplit;

We could perhaps have a global isvgUtilRegexp object hanging around to=20
contain all the generally useful Regexps we may use. This would avoid hav=
ing=20
to redefine them everytime, and would allow us to fix Regexp bugs far mor=
e=20
easily (notably if we start running into unforeseen encoding problems, wh=
ich=20
wouldn't suprise me).

function isvgUtilRegexp () {
    this.version =3D '0.0.1'; // version interfaces ?
    this.nonNumericStart =3D new Regexp('^\D+');
    this.nonNumericEnd =3D new Regexp('\D+$');
    // etc.... follows long definitions
    return this;
}
var globalUtilRegexp =3D new isvgUtilRegexp;

We would then have:

function isvgNonNumericSplit () {
=A0 =A0 this.replace(globalUtilRegexp.nonNumericStart, '');
=A0 =A0 this.replace(globalUtilRegexp.nonNumericEnd, '');
=A0 =A0 return this.split('\D+');
}
// add to the interface
String.prototype.isvgNonNumericSplit =3D isvgNonNumericSplit;

I know that it looks stupid given the simplicity of this example, but if =
we=20
want this thing to grow we might just as well put all reusable regexen=20
together.

> What would the Perl split do in the case I described?

It'd give an empty first element, but no empty last element (unless you a=
dded=20
a negative LIMIT parametre). Split is a complex little thing in pretty mu=
ch=20
all languages.

--=20
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi