part of a FORM inside DIV block

[Michal Mieszkowski]

i have a block of html code looking like this

<FORM name=myform>
<INPUT type=text name=firstname>
<DIV id=mydiv>
<INPUT type=text name=address>
</DIV>
</FORM>

i can access firstname field with document.myform.firstname

but how to reference to address field which is inside a DIV block.
nor document.myform.mydiv.address neither
document.myform.mydiv.document.address works

any ideas? this is realy kickin' my ass.

[Fabian]

Michal Mieszkowski hu kiteb:

i have a block of html code looking like this

<FORM name=myform>
<INPUT type=text name=firstname>
<DIV id=mydiv>
<INPUT type=text name=address>
</DIV>
</FORM>

i can access firstname field with document.myform.firstname

but how to reference to address field which is inside a DIV block.
nor document.myform.mydiv.address neither
document.myform.mydiv.document.address works

Have you tried document.myform.address yet?
--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Lasse Reichstein Nielsen]

ju****@interia.pl (Michal Mieszkowski) writes:

<FORM name=myform>
<INPUT type=text name=firstname>
<DIV id=mydiv>
<INPUT type=text name=address>
</DIV>
</FORM> but how to reference to address field which is inside a DIV block.
nor document.myform.mydiv.address neither
document.myform.mydiv.document.address works

That's not how addressing works. In fact, "document.myform" itself
isn't part of any standard.

The appropriate and standards[1] sanctioned way to access a form
control is:
document.forms['myform'].elements['address']
The div is irrelevant to the relation between form and form control.

And it is recommended to use "id" instead of "name" on the form.

/L
[1] Well, at leaset "W3C Recommendation" sanctioned.
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[@SM]

Lasse Reichstein Nielsen a ecrit :

And it is recommended to use "id" instead of "name" on the form.

Yes !
But ...
my NC4.5 can't use it !

so :
document.forms[0].elements[2].value
would work everywhere

--
************************************************** ************
Stéphane MORIAUX : mailto:st*********************@wanadoo.fr
Aide aux Pages Perso (images & couleurs, formulaire, CHP, JS)
http://perso.wanadoo.fr/stephane.moriaux/internet/
************************************************** ************

[DU]

Lasse Reichstein Nielsen wrote:

ju****@interia.pl (Michal Mieszkowski) writes:

<FORM name=myform>
<INPUT type=text name=firstname>
<DIV id=mydiv>
<INPUT type=text name=address>
</DIV>
</FORM>

but how to reference to address field which is inside a DIV block.
nor document.myform.mydiv.address neither
document.myform.mydiv.document.address works

That's not how addressing works. In fact, "document.myform" itself
isn't part of any standard.

HTMLCollection can make use of the namedItem method to retrieve a node.

The appropriate and standards[1] sanctioned way to access a form
control is:
document.forms['myform'].elements['address']
document.forms[0].elements.namedItem("address")

is perfectly standard and works without a glitch in Mozilla 1.5, Opera
7.23, MSIE 6 for windows and K-meleon 0.8.

DU
The div is irrelevant to the relation between form and form control.

And it is recommended to use "id" instead of "name" on the form.

/L
[1] Well, at leaset "W3C Recommendation" sanctioned.

[Lasse Reichstein Nielsen]

DU <dr*******@hotWIPETHISmail.com> writes:

Lasse Reichstein Nielsen wrote: HTMLCollection can make use of the namedItem method to retrieve a node.

Yes, or normal property access, using the NAME of the collection element
is the property name.

The appropriate and standards[1] sanctioned way to access a form
control is:
document.forms['myform'].elements['address']

document.forms[0].elements.namedItem("address")

is perfectly standard and works without a glitch in Mozilla 1.5, Opera
7.23, MSIE 6 for windows and K-meleon 0.8.

So is and does
document.forms['myform'].elements['address']
(ok, I haven't checked K-meleon, but it's Gecko-based)

Using forms[0] avoids the problem that Netscape 4 apparently has (not
recognizing the id attribute on forms). However, it makes the script
more fragile, since adding a form before the first will break the script.
I would rather put both the "id" and "name" attribute there (with the
same value).

"HTMLcollection" is defined in W3C DOM 2 HTML. The ECMAScript bindings
part of DOM 2 HTML says that using square bracket property access
notation is equivalent to using the namedItem method. Quote:
---
namedItem(name)
This function returns an object that implements the Node interface.
The name parameter is a String.
Note: This object can also be dereferenced using square bracket
notation (e.g. obj["foo"]). Dereferencing using a string index is
equivalent to invoking the namedItem function with that index.
---
(from <URL:http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>)

Since ECMAScript says that obj.foo is equivalent to obj["foo"] when
foo is valid identifier, using the dot notation for property access
should work as well.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[DU]

Lasse Reichstein Nielsen wrote:

DU <dr*******@hotWIPETHISmail.com> writes:

Lasse Reichstein Nielsen wrote:

HTMLCollection can make use of the namedItem method to retrieve a node.

Yes, or normal property access, using the NAME of the collection element
is the property name.

The appropriate and standards[1] sanctioned way to access a form
control is:
document.forms['myform'].elements['address']

document.forms[0].elements.namedItem("address")

is perfectly standard and works without a glitch in Mozilla 1.5, Opera
7.23, MSIE 6 for windows and K-meleon 0.8.

So is and does
document.forms['myform'].elements['address']
(ok, I haven't checked K-meleon, but it's Gecko-based)

We understand each other. All I wanted to say is that there is just one
appropriate way conforming to W3C web standards to access that node and
its value.
Using forms[0] avoids the problem that Netscape 4 apparently has (not
I really don't care about NS 4. People should stop using such bad browser.
recognizing the id attribute on forms). However, it makes the script
more fragile, since adding a form before the first will break the script.
Then you adjust accordingly. Simple as changing [0] to [1]. Ordinal
index is one way.

DU
I would rather put both the "id" and "name" attribute there (with the
same value).

"HTMLcollection" is defined in W3C DOM 2 HTML. The ECMAScript bindings
part of DOM 2 HTML says that using square bracket property access
notation is equivalent to using the namedItem method. Quote:
---
namedItem(name)
This function returns an object that implements the Node interface.
The name parameter is a String.
Note: This object can also be dereferenced using square bracket
notation (e.g. obj["foo"]). Dereferencing using a string index is
equivalent to invoking the namedItem function with that index.
---
(from <URL:http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>)

Since ECMAScript says that obj.foo is equivalent to obj["foo"] when
foo is valid identifier, using the dot notation for property access
should work as well.

/L

[@SM]

DU a ecrit :

document.forms[0].elements.namedItem("address")

is perfectly standard and works without a glitch in Mozilla 1.5, Opera
7.23, MSIE 6 for windows and K-meleon 0.8.

And so on NN4.5 ??

Don't believe old navigators still running.
--
************************************************** ************
Stéphane MORIAUX : mailto:st*********************@wanadoo.fr
Aide aux Pages Perso (images & couleurs, formulaire, CHP, JS)
http://perso.wanadoo.fr/stephane.moriaux/internet/
************************************************** ************

[Thomas 'PointedEars' Lahn]

DU wrote:

Lasse Reichstein Nielsen wrote:

DU <dr*******@hotWIPETHISmail.com> writes:

Lasse Reichstein Nielsen wrote:
The appropriate and standards[1] sanctioned way to access a form
control is:
document.forms['myform'].elements['address']

document.forms[0].elements.namedItem("address")

is perfectly standard and works without a glitch in Mozilla 1.5, Opera
7.23, MSIE 6 for windows and K-meleon 0.8.
So is and does
document.forms['myform'].elements['address']
(ok, I haven't checked K-meleon, but it's Gecko-based)

We understand each other.

I am afraid you did not understand.
All I wanted to say is that there is just one appropriate way
conforming to W3C web standards to access that node and its value.

But you are wrong, read again. There are exactly four possibilities
of accessing a form element in a standards-compliant way: The
namedItem(...) method, the index operator with a string operand, the
item(...) method and the index operator with a numeric operand. The
index operator (`[...]'), however is also downwards compatible as the
`document.forms' and `elements' collections or arrays were already part
of "DOM Level 0" from IE 3.0 and NN 3.0 on while the namedItem(...)
and item(...) methods were not. So the saner way is using the index
operator as Lasse suggested.
PointedEars

P.S.
Your `From:' header does not contain an e-mail address and is therefore
invalid, so you are violating Internet standards, helping to destroy the
Internet. ---> http://www.interhack.net/pubs/munging-harmful/

[Dr John Stockton]

JRS: In article <3F**************@PointedEars.de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<Po*********@web.de> posted at Mon, 8 Dec 2003 03:39:21 :-

Your `From:' header does not contain an e-mail address and is therefore
invalid, so you are violating Internet standards, helping to destroy the
Internet. ---> http://www.interhack.net/pubs/munging-harmful/

Perhaps he does not want to receive long-winded and pointless messages
from such as yourself. I trust that you will have the courage of your
convictions, and will not attempt to use any addresses other than those
literally provided.

I advise you to stop nagging; it makes you look foolish.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
some Astro stuff via astro.htm, gravity0.htm; quotes.htm; pascal.htm; &c, &c.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Thomas 'PointedEars' Lahn]

Dr John Stockton wrote:

[...] Thomas 'PointedEars' Lahn

Your `From:' header does not contain an e-mail address and is therefore
invalid, so you are violating Internet standards, helping to destroy the
Internet. ---> http://www.interhack.net/pubs/munging-harmful/
[flame]
I advise you to stop nagging;

I do not nag, I advise people not to destroy working structures.
If I would have time for it, I would pity you for not understanding this.
it makes you look foolish.

Well, that is your opinion and based on what you showed here regarding
Usenet/Internet Standards, I don't give a ... cent on it.
PointedEars

[Grant Wagner]

Thomas 'PointedEars' Lahn wrote:

Dr John Stockton wrote:

[...] Thomas 'PointedEars' Lahn

Your `From:' header does not contain an e-mail address and is therefore
invalid, so you are violating Internet standards, helping to destroy the
Internet. ---> http://www.interhack.net/pubs/munging-harmful/

[flame]
I advise you to stop nagging;

I do not nag, I advise people not to destroy working structures.
If I would have time for it, I would pity you for not understanding this.

How does it destroy a working structure?

He posted to Usenet, you read it, you replied, I read both the original post
and the reply, seems to be working fine to me.

it makes you look foolish.

Well, that is your opinion and based on what you showed here regarding
Usenet/Internet Standards, I don't give a ... cent on it.

And your one-man crusade to "save" Usenet and the Internet at large is unlikely
to produce any noticable effect.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[Thomas 'PointedEars' Lahn]

Grant Wagner wrote:

Thomas 'PointedEars' Lahn wrote:

Dr John Stockton wrote:

> [...] Thomas 'PointedEars' Lahn
>> Your `From:' header does not contain an e-mail address and is therefore
>> invalid, so you are violating Internet standards, helping to destroy the
>> Internet. ---> http://www.interhack.net/pubs/munging-harmful/
>
> [flame]
> I advise you to stop nagging;
I do not nag, I advise people not to destroy working structures.
If I would have time for it, I would pity you for not understanding this.

How does it destroy a working structure?

He posted to Usenet, you read it, you replied, I read both the original post
and the reply, seems to be working fine to me.

Obviously you did not read before you post, following the above link,

> it makes you look foolish.

Well, that is your opinion and based on what you showed here regarding
Usenet/Internet Standards, I don't give a ... cent on it.

And your one-man crusade to "save" Usenet and the Internet at large is unlikely
to produce any noticable effect.

nor have you any idea of Netiquette
--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

and how disregarding it destroys working structures. *PLONK*
PointedEars

[DU]

Thomas 'PointedEars' Lahn wrote:

DU wrote:

Lasse Reichstein Nielsen wrote:

DU <dr*******@hotWIPETHISmail.com> writes:

Lasse Reichstein Nielsen wrote:

>The appropriate and standards[1] sanctioned way to access a form
>control is:
>document.forms['myform'].elements['address']

document.forms[0].elements.namedItem("address")

is perfectly standard and works without a glitch in Mozilla 1.5, Opera
7.23, MSIE 6 for windows and K-meleon 0.8.

So is and does
document.forms['myform'].elements['address']
(ok, I haven't checked K-meleon, but it's Gecko-based)
We understand each other.

I am afraid you did not understand.

I was merely mentioning another W3C-web-standards way of accessing a
form control. Lasse's initial answer somewhat suggested there was only 1
way.

All I wanted to say is that there is just one appropriate way
conforming to W3C web standards to access that node and its value.

It should have been saying "... there is not just one appropriate
way...". Somehow I forgot to write the "not" word. My initial reply was
clearly suggesting there is more than 1 W3C web standard way to access a
form control.

But you are wrong, read again. There are exactly four possibilities
of accessing a form element in a standards-compliant way
Exactly four? There are other web standard compliant ways to access a
form element. You can give a form element an id attribute and then
access it with getElementById method. Roughly 96% (and still growing) of
all browsers in use out there support that method. NN 3.x, NN 4.x, IE
3.x and IE 4.x do not support getElementById though.

: The namedItem(...) method, the index operator with a string operand, the
item(...) method and the index operator with a numeric operand. The
index operator (`[...]'), however is also downwards compatible as the
`document.forms' and `elements' collections or arrays were already part
of "DOM Level 0"
DOM Level 0 is not a technical recommendation from the W3C. Never was.

from IE 3.0 and NN 3.0 on while the namedItem(...) and item(...) methods were not.
Are you saying people should not be using namedItem or item because IE
3.0 and NN 3.0 do not support these methods? Is that what you are
actually saying? IE 3.0 and NN 3.0 were designed and developed 8 years
ago, you know.
And what about other methods? NN 3.x, IE 3.x, NN 4.x and IE 4.x do not
support about every possible DOM 1 methods (including those which
generates HTMLCollections, nodeLists and NamedNodeMaps) and attributes
listed in W3C TRs. Would you go as far as saying we should not use any
of them because NN 3.x, IE 3.x, NN 4.x and IE 4.x do not support them as
well? and so forth for CSS1 properties, HTML 4 elements, attributes,
etc. that are either not supported or not working well in NN 3.x, NN
4.x, IE 3.x and IE 4.x?

So the saner way is using the index operator as Lasse suggested.
PointedEars

Lasse's initial reply did not make use of the index with an numeric
operand; I was the first to mention and use it in this thread.

DU

[DU]

Thomas 'PointedEars' Lahn wrote:

Dr John Stockton wrote:

[...] Thomas 'PointedEars' Lahn

Your `From:' header does not contain an e-mail address and is therefore
invalid, so you are violating Internet standards, helping to destroy the
Internet. ---> http://www.interhack.net/pubs/munging-harmful/
[flame]
I advise you to stop nagging;

I do not nag,

You nag. You admonish on spelling, on fixing news readers, on quoting
manners. You try to domesticate people on their posting manners, on
their quoting manners, on adding a semi-colon here, you then call them
scriptkiddies, you give them bullshit, etc.. You nitpick on top of all
that. Your tone is an authoritative one also: you just say "do this,
don't do that" but you rarely address the intelligence of people by
explaining to them the positive benefits of doing what you claim to
promote. This is a newsgroup on javascript, you know; not a place to
consolidate your nanny manners.
I advise people not to destroy working structures.
Spammers are destroying working structures: Yahoo!.com, Microsoft and
AOL recently understood that. Spammers undermine trust, confidence.
Successful scams achieved on the web thanks to spams are the ones which
destroy working structures. 2 billions junk emails of traffic per day
traveling among US servers is what is destroying working structures.
And what you said has no common measure with what I do with my email
address in a newsgroup. There is a magnitude of difference in
destruction between what spammers have done over the years and what I
have been doing in this newsgroup for the last 2 years that your post
absolutely ignore: your choice of word is senseless.
If I would have time for it, I would pity you for not understanding this.

it makes you look foolish.

Well, that is your opinion and based on what you showed here regarding
Usenet/Internet Standards, I don't give a ... cent on it.
PointedEars

Your reply to me in this thread was quite stunning to say the least. My
"from" header contains my email address. Claiming I violate Internet
standards and then adding that I help destroy the Internet is foolish.

DU

[DU]

Thomas 'PointedEars' Lahn wrote:

Grant Wagner wrote:

Thomas 'PointedEars' Lahn wrote:

Dr John Stockton wrote:

[...] Thomas 'PointedEars' Lahn

>Your `From:' header does not contain an e-mail address and is therefore
>invalid, so you are violating Internet standards, helping to destroy the
>Internet. ---> http://www.interhack.net/pubs/munging-harmful/

[flame]
I advise you to stop nagging;

I do not nag, I advise people not to destroy working structures.
If I would have time for it, I would pity you for not understanding this.
How does it destroy a working structure?

He posted to Usenet, you read it, you replied, I read both the original post
and the reply, seems to be working fine to me.

Obviously you did not read before you post,

This is insulting, I would say. You obviously can not know for sure if
Grant did or did not read that document. Nevertheless, you just say he
did not, just like that.

following the above link,
You did not write that document either. Why should we automatically go
to that url and read the referenced documents you mention? That document
is not even about javascript. That document is far from demonstrating
the damages done by email address munging.

it makes you look foolish.

Well, that is your opinion and based on what you showed here regarding
Usenet/Internet Standards, I don't give a ... cent on it.
And your one-man crusade to "save" Usenet and the Internet at large is unlikely
to produce any noticable effect.

nor have you any idea of Netiquette

You just authoritatively say others have no netiquette. "Plonk"-ing
people like you do can not promote your ideas in any way and will not
document your own claims about email address munging.

I have known Grant W. for over 2 years from the posts he wrote in this
newsgroup. From a c.l.javascript newsgroup perspective and from an
evangelization of good, sound compliance of web standards, sound coding
practices/techniques, I would say he's a patient, reasonable, moderate
person. He does not try to battle with others. I'm sure he would not
reply to you the way he did without solid reasons.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

and how disregarding it destroys working structures. *PLONK*
PointedEars

A very wide majority of reasonable people would not adamantly persist in
saying that modifying an email address is destroying working internet
structures.
PointedEars, you have rigid manners with people. Simple as that.

DU

[Lasse Reichstein Nielsen]

DU <dr*******@hotWIPETHISmail.com> writes:

Lasse's initial reply did not make use of the index with an numeric
operand; I was the first to mention and use it in this thread.

That was quite deliberate. I dislike programming with "magic numbers",
and prefer to use names whenever possible. Using numeric indices is
not stable wrt. changes on the page.

It is correct that it works, and in some cases might be useful, but I
recommend against it. It makes for fragile code.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[DU]

Lasse Reichstein Nielsen wrote:

DU <dr*******@hotWIPETHISmail.com> writes:

Lasse's initial reply did not make use of the index with an numeric
operand; I was the first to mention and use it in this thread.

That was quite deliberate. I dislike programming with "magic numbers",
and prefer to use names whenever possible.

I dislike resorting to numbers too. I always prefer meaningful,
intuitive, self-explanatory identifiers for name values, id values and
for functionName, variables, etc.. This simple code-naming policy helps
tremendously understanding, maintaining, reusing, reviewing (by others)
and debugging a source code.

Using numeric indices is not stable wrt. changes on the page.

The exception I apply (regarding such code naming policy) is about forms.
1- When I code a page, I want it to be as forward-compatible as possible
and as ready/easy to convert to XHMTL strict as possible; so I avoid
using the name attribute for forms elements.
E.g.: document.forms['myform'].elements['address']
can involve a compliant document in XHTML 1.0 strict and XHTML 1.1 only
if "myform" is the id value of the form.
2- I very rarely have more than 1 form in a webpage I build (1), so I
don't see the need to use the id attribute for it. In such case, when I
have a single form, I usually give significant id attribute values to
elements which will need to be accessed in script functions and then use
document.getElementById("FormControlId"), otherwise
document.forms[0].elements["FormControlName"] or
document.forms[0].elements.namedItem("FormControlName")
And if I have 2 forms (which is quite rare for me), then I just use
document.forms[0] and document.forms[1] accordingly, that is if I can't
reach, access form controls via document.getElementById. I remember
starting a thread (in this newsgroup I think) on this querying what was
the best (efficient) way to access form elements.
It is correct that it works, and in some cases might be useful, but I
recommend against it. It makes for fragile code.

/L

DU
(1) I don't want the user to be confronted to 2 submit buttons, 2 reset
buttons for the sake of interface clarity and eliminating possible
source of confusion. I believe there should be at most only 1 form
submit button per webpage.

[Lasse Reichstein Nielsen]

DU <dr*******@hotWIPETHISmail.com> writes:

The exception I apply (regarding such code naming policy) is about forms.
1- When I code a page, I want it to be as forward-compatible as
possible and as ready/easy to convert to XHMTL strict as possible; so
I avoid using the name attribute for forms elements.
Reasonable.
E.g.: document.forms['myform'].elements['address']
can involve a compliant document in XHTML 1.0 strict and XHTML 1.1 only
if "myform" is the id value of the form.
And ofcourse it is. The name attribute is deprecated on the form
element. The index of form controls in the elements collection is
easier to handle, as it only changes when you change the form, not
when you change the rest of the page.

The only problem is Netscape 4, which is no big surprice.
2- I very rarely have more than 1 form in a webpage I build (1), so I
don't see the need to use the id attribute for it. In such case, when
I have a single form, I usually give significant id attribute values
to elements which will need to be accessed in script functions and
then use document.getElementById("FormControlId"),
It has the advantage of working without a form element too. The forms
I make are usually meant for client-side processing, so the form
element makes no sense (except for keeping Netscape 4 happy, and I why
should I - I don't even like it :)

(1) I don't want the user to be confronted to 2 submit buttons, 2
reset buttons for the sake of interface clarity and eliminating
possible source of confusion. I believe there should be at most only 1
form submit button per webpage.

If the layout is clear, I don't think it is a problem (that includes
things like a form and a small login box - name/passwd/submit).
Wrap both forms in fieldset elements or other distingusihing wrappers.
I agree that it can become confuzing if not treated carefully.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'