getElementsByName doesn't work on FireFox in some cases.

briggs

<html>
<head>
<script>
/* AddChild */
function ac()
{
var c;
var p = document.getElementById("p");
for (var i = 0; i < 5; i++) {
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.
}
}

/* CountChildren */
function cc()
{
// The number of children is the number of elements whose name is
'ch'
var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);
}
</script>
</head>
<body onload="ac();">
<div id="p">parents:</div>
<input type="button" value="How many children 'parents' has?"
onclick="cc();">
</body>
</html>

Jan 11 '06 #1

Subscribe Post Reply

11327

RobG

briggs wrote:

Please post plain text only.

[...]

c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.
[...]
var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);

'name' is not a valid attribute for div elements. If you check the
elements, they have a 'name' attribute but it is not recognised by
getElementsByName.

Insert elements that can have a name (say INPUTs) and it works.

[...]
--
Rob

Jan 11 '06 #2

briggs

Thanks, Rob

'name' is not a valid attribute for div elements.
But, the following code works well in Firefox.

<html>
<head>
<script>
/* CountChildren */
function cc()
{
// The number of children is the number of elements whose name is
'ch'
var c = document.getElementsByName('ch');

// Both IE and Firefox reports 5.
alert(c.length);
}

</script>
</head>
<body>
<div id="p">parents:
<div name="ch">child 0</div>
<div name="ch">child 1</div>
<div name="ch">child 2</div>
<div name="ch">child 3</div>
<div name="ch">child 4</div>
<input type="button" value="How many children 'parents' has?"
onclick="cc();">
</body>
</html>

I think...
if the above code works, the codes in my first post should work too.

Jan 11 '06 #3

Thomas 'PointedEars' Lahn

RobG wrote:

briggs wrote:

Please post plain text only.
He/she did:

| Content-Type: text/plain; charset="euc-kr"
[...]
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.
[...]
var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);

'name' is not a valid attribute for div elements.

True.
If you check the elements, they have a 'name' attribute
False. The element object created is added a `name' property.

c.getAttribute("name") // null
but it is not recognised by getElementsByName.
Which is the reason of this.
Insert elements that can have a name (say INPUTs) and it works.

True.
PointedEars

Jan 11 '06 #4

Thomas 'PointedEars' Lahn

briggs wrote:

'name' is not a valid attribute for div elements.
But, the following code works well in Firefox.
If that works, it is due to you triggering Quirks Mode or simply a bug.
Whatever is the cause, it is nothing you should rely on.
<html>
The DOCTYPE declaration is missing, which triggers Quirks Mode.
<head>
<script>
Should be

<script type="text/javascript">
[...]
<URL:http://validator.w3.org/>
I think...
if the above code works, the codes in my first post should work too.

Not necessarily.
PointedEars

Jan 11 '06 #5

Thomas 'PointedEars' Lahn

briggs wrote:

'name' is not a valid attribute for div elements.
_Rob_ wrote this, not you.
But, the following code works well in Firefox.

Please learn to quote:

<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
<URL:http://www.safalra.com/special/googlegroupsreply/>
PointedEars

Jan 11 '06 #6

RobG

Thomas 'PointedEars' Lahn wrote:

RobG wrote:

briggs wrote:

Please post plain text only.

He/she did:

| Content-Type: text/plain; charset="euc-kr"

Yeah, sorry to the OP, the different encoding threw me.

[...]

c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.

[...]

var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);

'name' is not a valid attribute for div elements.

True.

If you check the elements, they have a 'name' attribute

False. The element object created is added a `name' property.

c.getAttribute("name") // null

Consider the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>

<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>
</html>
I got:

hasAttribute name in x x.name
Firefox false true fred
Safari false true fred
Opera false true fred
However, add the name attribute in the HTML and not in the script:

<div id="steve" name="fred">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>
and you get the opposite (almost):

hasAttribute name in x x.name
Firefox true false undefined
Safari true false fred
Opera true false undefined
I think we can agree that using non-standard attributes causes unreliable
results. :-)

--
Rob

Jan 11 '06 #7

Thomas 'PointedEars' Lahn

RobG wrote:

Thomas 'PointedEars' Lahn wrote:
RobG wrote:
briggs wrote:
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
[...] [...]
If you check the elements, they have a 'name' attribute

False. The element object created is added a `name' property.

c.getAttribute("name") // null

Consider the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>

| <!ELEMENT TITLE - - (#PCDATA) -(%head.misc;) -- document title -->
<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>
</html>
(I reply only to clear up a misunderstanding. In case you did not notice
yet, usually I do not read postings of yours with a non-existing sender
address since I killfiled .auau in From headers as being a disregarding of
Netiquette [RFC1855] and a violation of USENET/Internet (quasi-)standards,
particularly RFC1036 and RFC[2]822.)

I was talking about creating element objects through DOM scripting and
what happens when they are added a property that does not have a Valid
corresponding attribute.

You are talking about referring to existing elements in _markup_ via
element objects and what happens when that element objects are added
a property that does not have a Valid corresponding attribute.

As for the code of the OP,

c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.
I think we can agree that using non-standard attributes causes
unreliable results. :-)

We can, even in an ambiguous sense.
PointedEars

Jan 11 '06 #8

briggs

Thomas 'PointedEars' Lahn wrote:

briggs wrote:
'name' is not a valid attribute for div elements.

_Rob_ wrote this, not you.

Sorry. I'm a newcomer. I should have learned quoting manners before
posting reply.

But, the following code works well in Firefox.

Please learn to quote:

<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
<URL:http://www.safalra.com/special/googlegroupsreply/>
PointedEars

I read the second URL yesterday and now i'm trying the first. I'll read
both of them until familiar with them.

appreciate your advices.

briggs

Jan 12 '06 #9

RobG

Thomas 'PointedEars' Lahn wrote:

RobG wrote:

Thomas 'PointedEars' Lahn wrote:
RobG wrote:

briggs wrote:

> c = document.createElement("DIV"); // Create 'div' element.
> c.id = "ch";
> c.name = "ch";
> [...]

[...]

If you check the elements, they have a 'name' attribute

False. The element object created is added a `name' property.

c.getAttribute("name") // null
Consider the following: [...] <div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script> [...]
I was talking about creating element objects through DOM scripting and
what happens when they are added a property that does not have a Valid
corresponding attribute.

You are talking about referring to existing elements in _markup_ via
element objects and what happens when that element objects are added
a property that does not have a Valid corresponding attribute.
I was highlighting differences in outcomes depending on how it is
attempted for the purpose of discussion, not contradiction.

As for the code of the OP,

c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.

'correct' on what basis? Can you explain why 'false' is the correct
response?
==Some further discussion==

In Firefox, attributes can be added to an element:

1. in the HTML source,
2. using the element's setAttribute method, and
3. using JavaScript dot notation.

The first two methods will add the attribute to the HTML element's
attribute object, making them available to other methods such as
getElementById or getElementsByName.

Using dot notation will only add an attribute to the element's
attributes object if the element has an attribute with the same name
defined in the relevant DTD.

This means that an ID can be added to a DIV's attributes object using:

divRef.id = 'divId';
divRef.hasAttribute('id') // returns true
But since name is not an attribute defined in the HTML 4 DTD, a name
attribute isn't added to divRef's attributes object if dot notation is used:

divRef.name = 'divName';
divRef.hasAttribute('name') // returns false
But a name attribute can be added to the attributes object using
setAttribute:

divRef.setAttribute('name','divName');
divRef.hasAttribute('name') // returns true

Now hasAttribute('name') will return true, getElementsByName will find
the div and innerHTML reveals a name attribute in the HTML.

The results from IE 6 are quite different, it does not allow the 'name'
attribute to be added to a DIV element's attributes object by any of the
above methods.

I think we can agree that using non-standard attributes causes
unreliable results. :-)

We can, even in an ambiguous sense.

'Ambiguous' infers that you think it is unreliable for a reason
different to mine.

I explained that different results are obtained using exactly the same
code in different browsers and that how the attribute is attached can
affect the outcome in ways that are not obvious or might not be expected.

Do you have a different reason for saying so?.
1. Ignoring innerHTML, innerText and other proprietary approaches.

--
Rob

Jan 12 '06 #10

Thomas 'PointedEars' Lahn

RobG wrote:

Thomas 'PointedEars' Lahn wrote:
RobG wrote:
Thomas 'PointedEars' Lahn wrote:
RobG wrote:
> briggs wrote:
>> c = document.createElement("DIV"); // Create 'div' element.
>> c.id = "ch";
>> c.name = "ch";
>> [...]
[...]
> If you check the elements, they have a 'name' attribute
False. The element object created is added a `name' property.

c.getAttribute("name") // null
Consider the following: [...] <div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script> [...]
I was talking about creating element objects through DOM scripting and
what happens when they are added a property that does not have a Valid
corresponding attribute.

You are talking about referring to existing elements in _markup_ via
element objects and what happens when that element objects are added
a property that does not have a Valid corresponding attribute.
I was highlighting differences in outcomes depending on how it is
attempted for the purpose of discussion, not contradiction.

Pardon?

As for the code of the OP,

c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.

'correct' on what basis? Can you explain why 'false' is the correct
response?

Because adding a property to an element object that has no corresponding
declared attribute name should not result in adding an attribute of that
name to the respective element at all. I assumed that to be clear already.
==Some further discussion==

In Firefox, attributes can be added to an element:

1. in the HTML source,
2. using the element's setAttribute method, and
3. using JavaScript dot notation.

The first two methods will add the attribute to the HTML element's
attribute object, making them available to other methods such as
getElementById or getElementsByName.
Where I consider it to be a Gecko DOM bug that setAttribute() is
successful even though the resulting element (would) contradict(s)
the DTD.
Using dot notation will only add an attribute to the element's
attributes object if the element has an attribute with the same
name defined in the relevant DTD.
See above. It appears that whether the attribute is added or not using
that, depends on how the element object was created, unfortunately. I
consider that to be a Gecko DOM bug as well.
[...] I think we can agree that using non-standard attributes causes
unreliable results. :-)

We can, even in an ambiguous sense.

'Ambiguous' infers that you think it is unreliable for a reason
different to mine. [...]
Do you have a different reason for saying so?.

I have. Non-existing e-mail addresses in From headers are a non-standard
attribute, too, and the unreliable result it produces is a smaller number
of competent people that will read and reply to your postings :) (SCNR)
Regards,
PointedEars

Jan 12 '06 #11

RobG

Thomas 'PointedEars' Lahn wrote:

RobG wrote:

Thomas 'PointedEars' Lahn wrote:
RobG wrote:

Thomas 'PointedEars' Lahn wrote:

>RobG wrote:
>
>>briggs wrote:
>>
>>> c = document.createElement("DIV"); // Create 'div' element.
>>> c.id = "ch";
>>> c.name = "ch";
>>> [...]
>
>[...]
>
>>If you check the elements, they have a 'name' attribute
>
>False. The element object created is added a `name' property.
>
> c.getAttribute("name") // null

Consider the following:
[...]
<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script> [...] c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.

'correct' on what basis? Can you explain why 'false' is the correct
response?

Because adding a property to an element object that has no corresponding
declared attribute name should not result in adding an attribute of that

^^^^^^ name to the respective element at all. I assumed that to be clear already.

Not to me.

It seems that there is no way of determining via script what attributes
are OK and what aren't - hasAttribute only tells you those that have
been set, not whether the attribute is valid for that element.

There is nothing in the DOM spec that says using setAttribute to attach
an attribute that isn't in the DTD should do anything in particular
(hence your use of 'should' rather than 'must' and I agree with that).

==Some further discussion==

In Firefox, attributes can be added to an element:

1. in the HTML source,
2. using the element's setAttribute method, and
3. using JavaScript dot notation.

The first two methods will add the attribute to the HTML element's
attribute object, making them available to other methods such as
getElementById or getElementsByName.

Where I consider it to be a Gecko DOM bug that setAttribute() is
successful even though the resulting element (would) contradict(s)
the DTD.

Which suggests that for setAttribute to be useful, it should return a
value to say whether attaching/modifying the attribute was successful -
otherwise dot notation may as well be used.

A hack can be to use dot notation to set the property then test it with
hasAttribute - but IE doesn't support hasAttribute.

IE isn't much better - it won't find the element using
getElementsByName, but it will add the name attribute to the HTML and
attribute object using any of the mentioned methods.

Using dot notation will only add an attribute to the element's
attributes object if the element has an attribute with the same
name defined in the relevant DTD.

See above. It appears that whether the attribute is added or not using
that, depends on how the element object was created, unfortunately. I
consider that to be a Gecko DOM bug as well.

It doesn't matter HTML or createElement are used to create the element,
it's how the attribute is attached that matters.

Adding the attribute in the HTML behaves exactly as does setAttribute,
and setAttribute behaves the same whether the element is created in HTML
or DOM. Adding the attribute as a property of the DOM object is where
the difference lies (to which I suppose you could respond with "Yeah,
like I said in the beginning").

I did quite a bit of further testing to prove it this, hopefully that
will make the lesson stick. This discussion has been useful, at least
to me.

I'd call it a Gecko flaw, bug indicates a programming error. This seems
to be a 'works as designed' thing - but that's just opinion.

[...]
I think we can agree that using non-standard attributes causes
unreliable results. :-)

We can, even in an ambiguous sense.

'Ambiguous' infers that you think it is unreliable for a reason
different to mine. [...]
Do you have a different reason for saying so?.

I have. Non-existing e-mail addresses in From headers are a non-standard
attribute, too, and the unreliable result it produces is a smaller number
of competent people that will read and reply to your postings :) (SCNR)

And I don't disagree with that! :-)
--
Rob

Jan 12 '06 #12

Thomas 'PointedEars' Lahn

RobG wrote:

Thomas 'PointedEars' Lahn wrote:
RobG wrote:
Thomas 'PointedEars' Lahn wrote:
RobG wrote:
> Thomas 'PointedEars' Lahn wrote:
>> RobG wrote:
>>> briggs wrote:
>>>> c = document.createElement("DIV"); // Create 'div' element.
>>>> c.id = "ch";
>>>> c.name = "ch";
>>>> [...]
>> [...]
> [...]
c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.
'correct' on what basis? Can you explain why 'false' is the correct
response? Because adding a property to an element object that has no corresponding
declared attribute name should not result in adding an attribute of that

^^^^^^
name to the respective element at all. I assumed that to be clear
already.

Not to me.

It seems that there is no way of determining via script what attributes
are OK and what aren't - hasAttribute only tells you those that have
been set, not whether the attribute is valid for that element.

Unfortunately, yes.
There is nothing in the DOM spec that says using setAttribute to attach
an attribute that isn't in the DTD should do anything in particular
(hence your use of 'should' rather than 'must' and I agree with that).
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288>

Unfortunately, this particular recommendation regarding attribute values
should not be followed in practice due to buggy implementations.
[...]
Which suggests that for setAttribute to be useful, it should return a
value to say whether attaching/modifying the attribute was successful -
It should throw an exception, could be an INVALID_CHARACTER_ERR exception,
in that case. DOM methods should not allow for creating elements that
contradict the document type they are declared for.

<URL:http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-F68F082>
[...]
Using dot notation will only add an attribute to the element's
attributes object if the element has an attribute with the same
name defined in the relevant DTD. See above. It appears that whether the attribute is added or not using
that, depends on how the element object was created, unfortunately. I
consider that to be a Gecko DOM bug as well.

It doesn't matter HTML or createElement are used to create the element,
it's how the attribute is attached that matters.

No, if HTMLDocument::createElement is used, the created but not included
element is not added a new attribute using the property accessor, but the
element object is added a new property. Hence the return values of
HTMLElement::getAttribute() and HTMLElement::hasAttribute() for that
element object as the calling object.
[...]
> I think we can agree that using non-standard attributes causes
> unreliable results. :-)
We can, even in an ambiguous sense.
'Ambiguous' infers that you think it is unreliable for a reason
different to mine. [...]
Do you have a different reason for saying so?.

I have. Non-existing e-mail addresses in From headers are a non-standard
attribute, too, and the unreliable result it produces is a smaller number
of competent people that will read and reply to your postings :) (SCNR)

And I don't disagree with that! :-)

I see.

$ host -t MX iinet.net.au
iinet.net.au mail is handled by 10 filter.iinet.net.au.

$ telnet filter.iinet.net.au smtp
| Trying 203.0.178.192...
| Connected to filter.iinet.net.au.
| Escape character is '^]'.
| 554 iinet-mail.icp-qv1-irony4.iinet.net.au
| Connection closed by foreign host.

Probably you want to read the Acceptable Use Policy of your service
provider, SingTel Optus Pty Ltd., again, especially Appendix H, section 7.

[Word]
<URL:http://optus.net.au/dafiles/OCA/AboutOptus/LegalAndRegulatory/SharedStaticFiles/SharedDocuments/AppH.doc>
Score adjusted

PointedEars

Jan 16 '06 #13

Randy Webb

Thomas 'PointedEars' Lahn said the following on 1/16/2006 10:38 AM:

RobG wrote:

Thomas 'PointedEars' Lahn wrote:

<snip>

I have. Non-existing e-mail addresses in From headers are a non-standard
attribute, too, and the unreliable result it produces is a smaller number
of competent people that will read and reply to your postings :) (SCNR)

That is utter non-sense. Non-existing e-mail addresses are a
"non-standard attribute"? Did you read that before you posted it? Your
implication is that the fact the email address is non-existent makes the
attribute non-standard but that a valid address all of a sudden makes it
a standard attribute?
And I don't disagree with that! :-)

I see.

$ host -t MX iinet.net.au
iinet.net.au mail is handled by 10 filter.iinet.net.au.

$ telnet filter.iinet.net.au smtp
| Trying 203.0.178.192...
| Connected to filter.iinet.net.au.
| Escape character is '^]'.
| 554 iinet-mail.icp-qv1-irony4.iinet.net.au
| Connection closed by foreign host.

Probably you want to read the Acceptable Use Policy of your service
provider, SingTel Optus Pty Ltd., again, especially Appendix H, section 7.

Mine is a "valid existing email address" but it is as useless as any
other non-existing email address as you can't send it email. Your
pedantics are getting old.

There are only two reasons people would want to have a valid email
address in Usenet Postings:

1) So that they can circumenvent the "Ask in Usenet, get answered in
Usenet" convention.

2) Collect email addresses for Spamming.

Neither of which are a valid reason for anyone posting a valid email
address and are very valid reasons *not* to post a valid email address.

You need to find you some newer references (under 5 years old) to read
and learn from.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Jan 16 '06 #14

Thomas 'PointedEars' Lahn

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 1/16/2006 10:38 AM:
RobG wrote:
Thomas 'PointedEars' Lahn wrote:
I have. Non-existing e-mail addresses in From headers are a
non-standard attribute, too, and the unreliable result it produces is a
smaller number of competent people that will read and reply to your
postings :) (SCNR)
That is utter non-sense.
No, it is not.
Non-existing e-mail addresses are a "non-standard attribute"?
They are.
Did you read that before you posted it?
I did.
Your implication is that the fact the email address is non-existent makes
the attribute non-standard but that a valid address all of a sudden makes
it a standard attribute?
Yes, it does.

And I don't disagree with that! :-)

I see.

$ host -t MX iinet.net.au
iinet.net.au mail is handled by 10 filter.iinet.net.au.

$ telnet filter.iinet.net.au smtp
| Trying 203.0.178.192...
| Connected to filter.iinet.net.au.
| Escape character is '^]'.
| 554 iinet-mail.icp-qv1-irony4.iinet.net.au
| Connection closed by foreign host.

Probably you want to read the Acceptable Use Policy of your service
provider, SingTel Optus Pty Ltd., again, especially Appendix H, section
7.

Mine is a "valid existing email address"

If what you write here applies, it is not:
but it is as useless as any other non-existing email address as you can't
send it email.

Jan 16 '06 #15

Randy Webb

Thomas 'PointedEars' Lahn said the following on 1/16/2006 5:41 PM:

Randy Webb wrote:
<snip>

Your implication is that the fact the email address is non-existent makes
the attribute non-standard but that a valid address all of a sudden makes
it a standard attribute?

Yes, it does.

I have read some crazy things from you but that tops most of them.

<snip>

Mine is a "valid existing email address"

If what you write here applies, it is not:

Read carefully what I wrote. The wording makes a difference. "You can't
send it email". Consider carefully the phrase I used versus "It doesn't
receive email". The email address I use in Usenet does indeed receive
mail. In fact almost 100 emails a day.

but it is as useless as any other non-existing email address as you can't
send it email.

<snip useless quote that is irrelevant to me>
| A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^

And as I said, that email address receives mail. Daily.

Your useless pedantics are getting old and serve no useful purpose.

I could just as well change my email address I post in Usenet to
us*************@hikksworld.com and neither is of any more use to you
than the other.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Jan 17 '06 #16

Thomas 'PointedEars' Lahn

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 1/16/2006 5:41 PM:
Randy Webb wrote:
Mine is a "valid existing email address" If what you write here applies, it is not:

Read carefully what I wrote. The wording makes a difference.

Indeed it does. If what you say above is true, you used the wrong wording.
"You can't send it email". Consider carefully the phrase I used versus "It
doesn't receive email".
An e-mail address must specify an existing mailbox; anything that does not,
is no e-mail address (RFC[2]822, Address Specification). Electronic mail
that cannot be received by a mailbox is never delivered by either the
sending or the receiving MTA; after some tries it results in a bounce, an
"undeliverable mail" message, to the sender and is removed from the MTA's
queue.
The email address I use in Usenet does indeed receive mail. In fact almost
100 emails a day.
but it is as useless as any other non-existing email address as you
can't send it email.
<snip useless quote that is irrelevant to me>
Irrelevant to you, but not to the discussion and many service providers.
| A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^

And as I said, that email address receives mail.

What counts is that the _mailbox_ receives.
Daily.

If we assume that you identify e-mail address with mailbox, your statement
above that you cannot send mail there is not true, and your sender address
would not pose any problem. However, it would violate Internet Standard 11
(RFC[2]822) otherwise.
PointedEars

Jan 17 '06 #17

Randy Webb

Thomas 'PointedEars' Lahn said the following on 1/17/2006 7:35 AM:

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 1/16/2006 5:41 PM:
Randy Webb wrote:

Mine is a "valid existing email address"

If what you write here applies, it is not:
Read carefully what I wrote. The wording makes a difference.

Indeed it does. If what you say above is true, you used the wrong wording.

I did not use the wrong wording to say what I wanted to say. It says
exactly what I wanted to say and it said in the way I wanted it said.
That does not make it the "wrong wording".

"You can't send it email". Consider carefully the phrase I used versus "It
doesn't receive email".

An e-mail address must specify an existing mailbox; anything that does not,
is no e-mail address (RFC[2]822, Address Specification).

Mine does.

Electronic mail that cannot be received by a mailbox is never
delivered by either the sending or the receiving MTA;
The email address I use points at a mailbox that does indeed get mail
delivered to it - daily.

after some tries it results in a bounce, an "undeliverable mail" message, to the sender and is removed from the MTA's
queue.
If you attempt to send an email to the address I give, you should get an
undeliverable mail message. Probably get a declined message though.

The email address I use in Usenet does indeed receive mail. In fact almost
100 emails a day.

but it is as useless as any other non-existing email address as you
can't send it email.
<snip useless quote that is irrelevant to me>

Irrelevant to you, but not to the discussion and many service providers.

For it to be relevant to a discussion between you and myself, it has to
be relevant to both of us and I don't give one iota what that reference
says.

As for my service provider, I don't think you would succeed in doing
anything more than giving them a good laugh if you notified them that I
was using an email address that you can't send email to. Especially
considering that Comcast explicitly suggests you do just that (use a
fake address) to cut down on spam.

| A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^
And as I said, that email address receives mail.

What counts is that the _mailbox_ receives.

And it does. What counts to *ME* is that YOU can not send it mail. And
that makes my email address just as useless to you as a non-existent
one. Other than a non-existent one has a little more use to you because
you get to be pedantic about whether that is proper or not when nobody
in this group (except you) gives a crap about it.

Daily.
If we assume that you identify e-mail address with mailbox, your statement
above that you cannot send mail there is not true,

Send me an email then. See if it gets delivered. And then I will forward
one, with all headers intact, to you so that you can see that it
actually *does* receive email. Just not from anybody that I don't
explicitly allow to email it.
and your sender address would not pose any problem.
Fake sender addresses do not cause any problem. Well, other than to you.
However, it would violate Internet Standard 11 (RFC[2]822) otherwise.

Then sue me and complain to Comcast.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Jan 17 '06 #18

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

An e-mail address must specify an existing mailbox;

What is a mailbox? If we use the rather loose definition of RFC2822,
the paragraph that you quote, a mailbox is said to both receive mail
and normally be comprised of two strings (optional display name and
e-mail address enclosed in < and >). That's ambiguous already. A
string does not receive mail.

What they appear to mean, and uses correctly later, is that the string
is a "mailbox specification". I.e., an identifier of something that
receive mails.

What "receives" means is still unspecified, since RFC2822 doesn't
cover exchange protocols like NNTP and SMPT. Piping to /dev/null
should be sufficient.

A more precise definition is in RFC2821 (2.3.10 Mailbox and Address).
It still just says that a mailbox is a place where mail is deposited.
Again "deposited" is not formalized.

I can assure you that I have mailboxes that delete some incoming mails
without me ever seeing them. Is that a mailbox? Would it be if it
deleted all of them?
/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.'

Jan 17 '06 #19

Thomas 'PointedEars' Lahn

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
An e-mail address must specify an existing mailbox;

What is a mailbox? [...]

| 3.4. Address Specification
|
| Addresses occur in several message header fields to indicate senders
| and recipients of messages. An address may either be an individual
| mailbox, or a group of mailboxes.
| [...]
| A mailbox receives mail. It is a conceptual entity which
| does not necessarily pertain to file storage. [...]

What a mailbox is, could not be more clear: A mailbox is a conceptual
entity that receives (e-)mail and belongs to a recipient.
PointedEars

Jan 17 '06 #20

Dr John Stockton

JRS: In article <-8********************@comcast.com>, dated Mon, 16 Jan
2006 17:28:56 remote, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

There are only two reasons people would want to have a valid email
address in Usenet Postings:
Untrue.
1) So that they can circumenvent the "Ask in Usenet, get answered in
Usenet" convention.

2) Collect email addresses for Spamming.

3) So that off-topic communication can occur, without off-topic news-
posting.

YSCIB.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

Jan 17 '06 #21

Randy Webb

Dr John Stockton said the following on 1/17/2006 10:17 AM:

JRS: In article <-8********************@comcast.com>, dated Mon, 16 Jan
2006 17:28:56 remote, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :
There are only two reasons people would want to have a valid email
address in Usenet Postings:

Untrue.

1) So that they can circumenvent the "Ask in Usenet, get answered in
Usenet" convention.

2) Collect email addresses for Spamming.

3) So that off-topic communication can occur, without off-topic news-
posting.

Spam could be defined as "off-topic communication" also.

In any event, I do not post the email address I use so that I comply
with some arcane archaic document. I could just as well use
Th****@sucks.com and it would make no difference to me. It would only
serve to give Thomas something to whine about.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Jan 17 '06 #22

getElementsByName doesn't work on FireFox in some cases.

Similar topics