Subscribe to our feed

Symfony Experts

Symfony Experts
If you have an urgent question for a symfony-related issue, this is the place to ask.


Stack Overflow

The old fashioned way


July 27, 2009 – 11:07am IE 6 getElementsById() and prototype $() function return dom elements by *name*

I can’t believe I had not run into this yet, but today I had a page that had an element (an anchor) with a name attribute (“floorplans”), and further down the page a div with that id (“floorplans”). When I tried to dynamically load content into my div using $(‘floorplans’), things were getting all out of control on IE 6. Turns out IE6’s document.getElementById returns the first element whose id OR name matches the string, and of course Prototype’s $() function relies on the browser’s own getElementById(). Lesson learned!

7 Responses to IE 6 getElementsById() and prototype $() function return dom elements by *name*

  1. Andrew Noyes says:

    People have often noted that Prototype’s greatest weakness is its reliance on extending the browser’s DOM API. Good catch! I have to wonder, though–why mix ids and names? Why not just use ids?

  2. Scott Meves says:

    In this case I was only using the name attribute because to create an inline anchor you need them. I just happened to have a named anchor and a div with that same name as its ID that I needed to fetch in JS, otherwise I would have never ran into this issue! But you are right, not a good idea to mix ids and names if you don’t have to!

  3. Andrew Noyes says:

    Ah, is there some long lost IE version that doesn’t support using ids in place of names?

  4. Scott Meves says:

    You know, I never realized that using an id tag would work for an anchor, let alone an id tag on *any* type of element! I checked to see if this was just an unofficial thing or actually in the spec, and the w3c says that it’s totally legit, but that some older user agents don’t support anchors created with ids and that the name attribute allows richer names (with entities) that ids cannot (but names only work on <a> tags). Very interesting indeed! Learn something new every day.

  5. Andrew Noyes says:

    Indeed–I discovered that by accident myself. I was trying to get a page to validate XHTML 1.0 Strict, but it wouldn’t do so with the name attribute, which is deprecated. I figured the W3C must have provisioned that in the spec, so I gave it a whirl and sure enough, id’s worked just fine. That tip was a lifesaver when it came to making some very JavaScript intensive navigation schemes work without JavaScript.

  6. Scott Meves says:

    Wow, I had no idea the name attribute was deprecated in xhtml! To keep this geeky conversation going, I heard that XHTML is being ditched at the end of 2009 in support of HTML 5 (link). Crazy times. I kinda liked xhtml but only because it made me feel like my html was “better”.

  7. Andrew Noyes says:

    Depends on which bandwagon you’re on; XHTML 2.0 or HTML5. I tend to agree with the HTML5 side of the fence–the XHTML spec as is and into the foreseeable future is a purely academic agreement and seems to care almost not at all for the problems facing UI designers. The spec is designed for the markup of academic and scientific documents, and beyond that you’re stretching the rules. I honestly would have liked for HTML5 to be based on XHTML 1.0. It’s not any more semantic than HTML 4.01, but I just like how the community at large has used XHTML as an opportunity to rally people around standards compliance. Not to insult the intelligence of web designers, but it’s easier to tell people “XHTML good, HTML bad” than say “HTML 4.01 Strict should be typed semantically and strictly, and here are a few scenarios you should avoid”. It leaves a lot of gray area, and gray area is what lead HTML to such misuse in the past.