SitePoint Sponsor

User Tag List

Results 1 to 13 of 13
  1. #1
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation getElementById Bugs

    getElementById Bugs

    There are two getElementById bugs up for discussion:

    1. getElementById is case-insensitive but it should be case-sensitive.

    2. getElementById searches NAME attributes as well as ID attributes but it should not.

    My tests show that IE 6 and down have both bugs, Opera 9.02 has bug #2, Opera 7.54 has neither bug, and FireFox 1.5.0.7 has neither bug.

    My proposed solution relies on something I noticed while testing in IE: "document.all" is case-sensitive altho it too searches NAME as well as ID attributes.

    I would really appreciate if some different people could help me verify these findings in different browsers and on different platforms.

    There has been another proposed solution - but I really don't like removing the ID attribute.

    Thanks!

  2. #2
    SitePoint Guru
    Join Date
    Sep 2006
    Posts
    731
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MikeFoster
    getElementById Bugs

    There are two getElementById bugs up for discussion:

    1. getElementById is case-insensitive but it should be case-sensitive.

    2. getElementById searches NAME attributes as well as ID attributes but it should not.

    My tests show that IE 6 and down have both bugs, Opera 9.02 has bug #2, Opera 7.54 has neither bug, and FireFox 1.5.0.7 has neither bug.

    My proposed solution relies on something I noticed while testing in IE: "document.all" is case-sensitive altho it too searches NAME as well as ID attributes.

    I would really appreciate if some different people could help me verify these findings in different browsers and on different platforms.

    There has been another proposed solution - but I really don't like removing the ID attribute.

    Thanks!
    The I.E. problem of searching names doesn't seem to apply to divs. Referring to that url, I ended up doing it effectively the same way, not that I'm likely to use it. It seems to fix both problems:
    Code:
    <SCRIPT type='text/javascript'>
    
    document.gebi=document.getElementById;
    
    document.getElementById=function(id)
    {
     var elemRef, trueId='';
     
     if( elemRef=document.gebi(id) )
      trueId=elemRef.id;
       
     return (trueId==id) ? elemRef : null;
    }
    
    </SCRIPT>

  3. #3
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Logic Ali, thanks very much for your reply.

    I also have noticed that IE and Opera both seem to search the NAME attr only on those elements that have a default NAME attr, for example <A>, <INPUT>, etc. They don't seem to search "div.name" for example.

    My proposed solution will not become my default "xGetElementById" but will be an alternate - for those who want to use it. For those who use good naming conventions this bug may never have been encountered. But it does help to understand these types of browser bugs - this one could possibly cause a lot of headaches, but now we know about it.

    Thanks again for your help!

  4. #4
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe offtopic, but IE has this extremly annoying bug when using getElementsByName. I guess this is related to your point number 2. For example:
    Code:
    <table id="colors">
    <tr>
        <td>
            <input type="radio" name="colors" value="green">
            <input type="radio" name="colors" value="blue">
            <input type="radio" name="colors" value="red">
        </td>
    </tr>
    </table>
    
    <script>
    var colorsCollection = document.getElementsByName("colors");
    alert(colorsCollection.length);  // IE will alert 4...
    </script>

  5. #5
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Pepejeria,

    Thank you very much! I also noticed the same issues with getElementsByName as with getElementById.

    However... I've been digging into the W3C Specs... and have found some things that I had forgotten about. For example, this statement regarding HTML4.0: "The id and name attributes share the same name space." and this one: "An anchor name is the value of either the name or id attribute when used in the context of anchors. ... Anchor names that differ only in case may not appear in the same document.".

    So I need to remove all <A> elements from my test page. I'm updating it now.

  6. #6
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmmm... look at the W3C's validation results for my test page, very interesting.

    The validator is wrong!
    Last edited by MikeFoster; Nov 22, 2006 at 12:07.

  7. #7
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The only conclusions I can make at this point are the following:

    * IE and Opera put IDs and NAMEs in the same namespace. This may be per spec. FireFox appears not to do this.

    * IE's getElementById and getElementsByName are both case-insensitive. This is a bug. Opera and FireFox appear not to have this bug.

    I would really like to hear the thoughts of someone who is more familiar with the W3C Specs than I am.

  8. #8
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MikeFoster
    Hmmm... look at the W3C's validation results for my test page, very interesting.

    The validator is wrong!
    Well, Ids are unique, therefore the errors.

    I'm a bit disappointed to see that Opera mimics IE, but that wouldn't be the first time they do it. The specs are pretty clear on this me thinks.

  9. #9
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But my IDs are unique - IDs are supposed to be case-sensitive.

    I also expected Opera to have the same results as FireFox... but then I started thinking that if IDs and NAMEs are in the same namespace for all elements, then Opera has it right and FireFox is violating the spec - altho I prefer FireFox's implementation (and If this is a spec violation then I wish Opera would violate it too). Also, could it be that IDs and NAMEs are case-insensitive for all elements that support having both an ID and a NAME, because per the spec this is explicitly the case for <A> elements.

    Keep in mind that Opera does not exhibit the actual bug, which is case-insensitivity. I may be wrong in considering #2 a bug - it may be per spec! But I'm not sure yet.

    The spec seems quite ambiguous regarding the issue of elements that can have both an ID and a NAME and whether or not they are case-sensitive. I guess in Opera and FireFox we are just seeing a difference in interpretation of the spec.

    Again, I do wish some HTML Spec. guru would drop in and set me straight on this

  10. #10
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    HTML is case insensitive.

    XHTML is case sensitive.

    IE doesn't understand XHTML so most pages labelled as XHTML end up getting served as HTML instead of XHTML in order that they will work in all browsers rather than not working in IE.

    Therefore values in your (X)HTML that differ only in capitalization will be considered to be the same in many browsers.

    The solution - don't use values that differ only in capitalization.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  11. #11
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi felgall, thanks for your reply.

    I thought about that too, but it is HTML tagNames that are case-insensitive when returned by DOM methods. The HTML4 spec plainly says that IDs are case-sensitive except when in anchor elements. I think the validator is wrong.

    My test case uses the HTML 4.01 Strict doctype. At this point I am not testing XHTML because IE6 does not support it and it is an IE6 bug that we are investigating.

    The solution - don't use values that differ only in capitalization.
    I think most of us adhere to this rule as a "best practice" - and this is probably why we have never encountered this IE bug before.

    FireFox and Opera both consider IDs to be case-sensitive in HTML4.01 documents. IE does not - and I consider this to be a bug.

    IE and Opera put IDs and NAMEs into the same namespace (in HTML4.01 documents). FireFox does not. Who is right? The spec does say that IDs and NAMEs share the same namespace - but implies that this is only in anchor elements. IMO the spec is ambiguous on this point. This is the point I would like clarified. It seems that IE and Opera have interpreted this to include all elements which allow the NAME attribute. FireFox has taken a stricter interpretation, which I prefer.

    The real gotcha is not case-sensitivity - it is the fact that getElementById(ID) will return an anchor or form control element whose NAME matches ID.

    I would like to know where the answer is - in the spec.

    Thanks very much to everyone contributing to this thread

  12. #12
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, this would be interesting to know.

    Since the situation is like it is now, we had to do something like this in our last project:
    Code:
    Util.getElementsByName = function(sName)
    {
    	var cNodes = document.getElementsByName(sName);
    	var aNodes = [];
    	
    	for(var i=0, oNode; oNode = cNodes[i]; i++)
    	{
    		if(oNode.getAttribute("id") == sName) continue;
    		
    		aNodes.push(oNode);
    	}
    	
    	return aNodes;
    }

  13. #13
    SitePoint Member
    Join Date
    Mar 2009
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The thing is, a person can read many books on designing but I think creativity comes from inside that person. The book can be a very good one but will it make a person creative?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •