getElementsByName doesn't work on FireFox in some cases.

Discussion in 'Javascript' started by briggs, Jan 11, 2006.

  1. briggs

    briggs Guest

    <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>
     
    briggs, Jan 11, 2006
    #1
    1. Advertisements

  2. briggs

    RobG Guest

    briggs wrote:

    Please post plain text only.

    [...]
    '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.

    [...]
     
    RobG, Jan 11, 2006
    #2
    1. Advertisements

  3. briggs

    briggs Guest

    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.
     
    briggs, Jan 11, 2006
    #3
  4. He/she did:

    | Content-Type: text/plain; charset="euc-kr"
    False. The element object created is added a `name' property.

    c.getAttribute("name") // null
    Which is the reason of this.
    True.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 11, 2006
    #4
  5. 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.
    The DOCTYPE declaration is missing, which triggers Quirks Mode.
    Should be

    Not necessarily.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 11, 2006
    #5
  6. Thomas 'PointedEars' Lahn, Jan 11, 2006
    #6
  7. briggs

    RobG Guest

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

    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. :)
     
    RobG, Jan 11, 2006
    #7
  8. (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.
    We can, even in an ambiguous sense.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 11, 2006
    #8
  9. briggs

    briggs Guest

    briggs, Jan 12, 2006
    #9
  10. briggs

    RobG Guest

    I was highlighting differences in outcomes depending on how it is
    attempted for the purpose of discussion, not contradiction.

    '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.

    '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.
     
    RobG, Jan 12, 2006
    #10
  11. 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.
    Where I consider it to be a Gecko DOM bug that setAttribute() is
    successful even though the resulting element (would) contradict(s)
    the 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 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
     
    Thomas 'PointedEars' Lahn, Jan 12, 2006
    #11
  12. briggs

    RobG Guest

    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).

    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.

    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.

    And I don't disagree with that! :)
     
    RobG, Jan 12, 2006
    #12
  13. Unfortunately, yes.
    <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.
    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.

    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 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/Abo...ry/SharedStaticFiles/SharedDocuments/AppH.doc>


    Score adjusted

    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 16, 2006
    #13
  14. No, it is not.
    They are.
    I did.
    Yes, it does.
    If what you write here applies, it is not:
    | Network Working Group M. Horton
    | Request for Comments: 1036 AT&T Bell Laboratories
    | Obsoletes: RFC-850 R. Adams
    | Center for Seismic Studies
    | December 1987
    |
    |
    | Standard for Interchange of USENET Messages
    | [...]
    | 2.1. Required Header lines
    |
    | 2.1.1. From
    |
    | The "From" line contains the electronic mailing address of the
    | person who sent the message, in the Internet syntax. [...]


    | Network Working Group P. Resnick, Editor
    | Request for Comments: 2822 QUALCOMM Incorporated
    | Obsoletes: 822 April 2001
    | Category: Standards Track
    |
    |
    | Internet Message Format
    | [...]
    | 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. [...]
    ^^^^^^^^^^^^^^^^^^^^^^^^


    HTH

    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 16, 2006
    #14
  15. briggs

    Randy Webb Guest

    Thomas 'PointedEars' Lahn said the following on 1/16/2006 5:41 PM:
    I have read some crazy things from you but that tops most of them.

    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.

    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
    and neither is of any more use to you
    than the other.
     
    Randy Webb, Jan 17, 2006
    #15
  16. Indeed it does. If what you say above is true, you used the wrong wording.
    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.
    Irrelevant to you, but not to the discussion and many service providers.
    What counts is that the _mailbox_ receives.
    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
     
    Thomas 'PointedEars' Lahn, Jan 17, 2006
    #16
  17. briggs

    Randy Webb Guest

    Thomas 'PointedEars' Lahn said the following on 1/17/2006 7:35 AM:
    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".
    Mine does.

    Electronic mail that cannot be received by a mailbox is never
    delivered by either the
    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
    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.
    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.
    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.
    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.
    Fake sender addresses do not cause any problem. Well, other than to you.
    Then sue me and complain to Comcast.
     
    Randy Webb, Jan 17, 2006
    #17
  18. JRS: In article <>, dated Mon, 16 Jan
    2006 17:28:56 remote, seen in Randy Webb
    3) So that off-topic communication can occur, without off-topic news-
    posting.

    YSCIB.
     
    Dr John Stockton, Jan 17, 2006
    #18
  19. 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, Jan 17, 2006
    #19
  20. | 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
     
    Thomas 'PointedEars' Lahn, Jan 17, 2006
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.