SiteCrafting Blah Blah Blog
Dec. 11, 2006 at 4:36pm
Names 1, IDs 0
I never enjoy finding quirks in something so seemingly simple when I'm coding but it certainly happens. The following is a tale of how I ran into trouble with a couple attributes that should be worlds apart.
While working on a pretty spiffy site with all sorts of clutter saving JavaScript hiding/showing I ran up against a problem. On some pages these features were working just fine while on others they wouldn't do a thing -- not even throw up an error. I searched for a while without finding the culprit but eventually had a "well, just try it" moment that fixed things right up.
The difference I found between pages was some anchor links. What was so special about these anchor links? See for yourself:
...
<a name="someSection"></a>
<table id="someSection">
...
IE6, your browser friend and mine, was trying to hide/show the anchor with the name "someSection" rather than the table with an ID of "someSection". Since the anchor's pretty much invisible to begin with you can see how hard this would be to troubleshoot.
A more common place you might run into this is when using forms. Since it's still common practice to give form elements names, this sort of hybrid old versus new DOM-compatibility fuzziness might pop up.
Have a look at a quick example I whipped up in a newer browser then in IE6. May this save you billable time in the future when running into this yourself.
Posted in Coding Techniques, Javascript by Kevin Freitas
Comments (1)
hahah great. it seems to be a good argument for naming/id'ing everything completely unique.
A guy walks into a doctor's office. He raises his arm and swings it at the elbow and says "doc, my arm hurts whenever i do this."
The doctor responds "then don't do that."
i see that as a good argument too... geez.
1 | Left by bryan | Dec. 14, 2006 at 8:58am