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!
SUBSCRIBE VIA RSS
Subscribe to our feed
Symfony Experts
If you have an urgent question for a symfony-related issue, this is the place to ask.
RECENT TUNES
- Coldplay - U.F.O.
- Coldplay - Major Minus
- Coldplay - Every Teardrop Is a Waterfall
- Coldplay - M.M.I.X.
- Coldplay - Us Against the World
- Coldplay - Charlie Brown
- Coldplay - Paradise
- Coldplay - Hurts Like Heaven
- Coldplay - Mylo Xyloto
- Wild Beasts - Reach A Bit Further
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?
By Andrew Noyes on Jul 27, 2009
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!
By Scott Meves on Jul 27, 2009
Ah, is there some long lost IE version that doesn’t support using ids in place of names?
By Andrew Noyes on Jul 27, 2009
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.
By Scott Meves on Jul 27, 2009
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.
By Andrew Noyes on Jul 27, 2009
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”.
By Scott Meves on Jul 27, 2009
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.
By Andrew Noyes on Jul 27, 2009