Reserved ID Values?

Published 18 years, 9 months past

As a followup to my entry about id="tags" causing problems in IE/Win, here are four five test pages for IE/Win:

These are based on Kevin Hamilton’s observation that it’s highly likely the problems are caused by the tags method in IE/Win’s document.all DOM interface.  As he says:

[I]f you have an element with an id=”tags”, then document.all.tags is now a reference to that element, and no longer a method of the document.all object.

Such states would completely shatter any IE DOM scripting that relied on the document.all methods, and at least in the case of tags causes problems like crashing on print (probably because of the aforementioned conflict between the ID value and the DOM method).  The other keywords of concern are chronicled in the test pages listed above.  I’d test IE/Win myself, except I don’t have a printer handy for IE/Win to use, and besides, bug-hunting is best conducted in large groups.

Basically, load up each test page in IE/Win and do anything you can think to do.  Try to print, view source, save a local copy, et cetera, et cetera—the more obscure and offbeat, the better.  Let us know via the comments any problems you run into with said pages (trying to print them is a good first step, since that’s what messed up on tags) and I’ll add notes to each page based on what’s found.

In the meantime, I’m personally going to avoid using any of those words as ID values, and heartily recommend the same to you.

Update: I’ve added a test (for length) to the above list, and have another that’s not on the list due to its unfinished nature.  It’s a test of id="all"; the problem is, I don’t really know how to test it, or if it’s likely to be a problem at all.  Suggestions are welcomed in the comments.  I added some JavaScript links to some of the test pages as a secondary test, but I’m not sure how much good they do, to be honest.  As with suggestions, your feedback is welcome.

For those in search of more background, or trying to find new ways to test possible conflicts, or whatever, feel free to look over Microsoft’s documentation of the “all Collection”.

Comments (40)

  1. I took a slightly different route and edited the pages in word, using the ie option. I was able to print them in word, perhaps this won’t affect other MS products.

  2. I think we can add *top* to that list. A recent thread (8/19/05) on the WSG list discussed an issue where *top* was used as a fragment identifier. The OP was getting the following error message:
    Internet Explorer cannot open the internet site
    Operation aborted.

  3. I tried print preview on them all, and only “tags” caused any problem. IE gave this error message:

    There was an internal error, and Internet Explorer is unable to print this document.

    All the others were able to print preview as usual. I then tried printing to PDF and, again, only only “tags” caused any problems.

  4. My testing of IE 6 (SP2 on Win XP-pro) is similar to Lachlan’s. The only test case that crashed was id=”tags”.

  5. Did anyone test anything besides printing or print previewing?

    Thierry: more details (or a pointer to an archive of the thread) would be really helpful. Thanks!

  6. I wanted to post an URI earlier, but Google didn’t return anything…
    Here it is:
    (possible problem with MSIE when using *top* as a named anchor).

  7. Eric,
    I’ve used the same markup as yours, but replaced *tags* with *Tags* and didn’t get the error message. So I think one can safely use these words as long as the string is not in lowercase.

  8. Did anyone test anything besides printing or print previewing?

    Yeah, I did. I didn’t find anything.

    If you open up the shdoclc.dll file in a decent text editor, much of it is plaintext javascript. There are a couple occurrences of document.all.tags, but none of document.all.item or document.all.urns that I see.

    A search through the Windows\system32 directory finds document.all.item used in appwiz.cpl, but I doubt that would ever get loaded in relation to a user-designed webpage.

  9. Whats about id=”all” :)

  10. I tested IE7 Beta 1, it seems as though they’ve fixed the bug. I had no problems printing any of them.

    I then tested these bookmarklets in IE, on each of the 4 test pages and another page without the suspect ID’s used:

    1. javascript:void(alert(;
    2. javascript:void(alert("bar")));

    Where foo is the name of the function/id value, and bar is an appropriate argument for the function, with these results:

    1. On each of the test pages, the result alerted “[object]”. On the other page, it alerted “function() { [native code] }”.

    2. On each of the test pages, this resulted in a script error stating that the object does not support this method. On the other page, the function executed and returned an [object].

  11. One more property: document.all.length runs into the same namespace polluting if you have an element with id=”length”.

    But in my testing I wasn’t able to make that break the browser in any way.

  12. I’ve tested the “tags” example on IE7 Beta 1 and it does NOT crash.

  13. I had a problem a while ago that gave me a severe head ache. I had a form with a submit button id=”action”. Trying to script theForm.submit() won’t do anything, since the id overrules the action attribute. Same goes for id=”submit”. I think PPK said it before me.
    Again, this doesn’t really break the browser, just your script, and your brain.

  14. I think if we could just drop the “jump to top” anchor altogether, that should work.
    why not use the DOM to do this?

  15. Am I the only one having Firefox on a Mac crash when trying to print Joe Clark’s article. And don’t laugh, but it’s only when I try to print it portrait, both landscape options in Page Setup print it!

    I’ve got Firefox 1.0.6 running on a MacOS X.3.9

    Curious. Never seen this happen before.

  16. Pingback ::

    Web4C » Blog Archive » IE Reserved ID?

    […] 0;


  17. Yet annother fun one is that IE does not allow name and id attributes to share values. So…

    <input name=”formfield” id=”formfield” />

    …is OK everywhere I’ve seen, but not IE which needs…

    <input name=”formfield” id=”formfieldId” />

  18. Michiel: I’m not sure how to build a test case for that. Any suggestions?

    Ken: I haven’t seen any problems with ID and name sharing, and I’ve recently set up some forms wihch do just that. There weren’t any reports of problems in IE/Win. Do you have a specific test case handy?

  19. Pingback ::

    The Dailies » IE hates “tags”

    […] ags”
    Filed under: XHTML/CSS — michael @ 11:04 pm

    As reported by Eric Meyer […]

  20. Pingback ::

    Wonko The Sane » Stuff I been stubling upon.

    […] upon.

    Posted by fruitcake on August 31st 2005 to General
    Reserved ID Values? – Using some ID tags causes IE to barf when printing, could […]

  21. Pingback ::

    Dextrose » Printing website kills IE

    […] Even a simple CSS ID-tag can crash Microsoft Internet Explorer…. Update: More about Reserved ID-values posted on August 30, 2005 @ 0:22 […]

  22. Pingback ::

    LANtastic :: Blog

    […] l

  23. I’m testing this under IE 7 on Windows Vista and printing to the document saver works, Print Preview Works, and the javascript test returns an object in an alert box.

  24. Pingback ::

    Operation: Leaf Blower » IE Terror

    […] at the moment), and for any random visitors: Eric Meyer notes in his fantastic blog that IE crashes when trying to print if you’re HTML contains the attribute id=” […]

  25. Using IE6/Win, everything seems to work, except the id="tags" printing. On that page, I can’t print or print-preview, although the browser never crashes (WinXP/SP2), it just throws an error message. All of the other pages acted fine.

    I attempted to: print, view the print-preview, save page to desktop, view source, add/remove from bookmarks, even export to Excel, which seemed to work although I have little experience with that.

  26. Another can of worms is naming form elements. For example, *never* name an element “action” under IE, since it conflicts with the built-in Form.action property.

  27. Well i have great news :)

    it seems “content” is a reserved word too !

    I had a div with an id of “content”,

    #content{ height:100px; }

    in the stylesheet does NOT work, whereas renaming the div’is to “contents” (mind the S)
    and the stylesheet to


    DOES work !!
    hmm talk about great programming

  28. sorry, you should read “the div’s id” instead of “the div’is”. can’t even type properly :)

  29. Contrary to Romain’s note on id=”content”: I have a site with just such a situation, and it works fine in IE6/Win, IE5.2/Mac, Safari, FF/Win, FF/Mac, Opera8/Win…

  30. Related to Ken’s comment here are a few more that could be a very common mistake, since meta tags are still so widely used:

    getElementById('description') ->
    getElementById('description') ->

    Since IE likes to confuse name & id, it’ll grab your named elements first. So any meta name could potentially get in the way, and seeing as there are a ton of meta tags out there, it really leaves things open for errors in IE. For example,’s metas include:

    So now we’re starting to get a long list of potential buggy ids.

  31. Eric, I thought I’d add that the following three examples using name="tags" also cause the id="tags" printing bug in IE.

    <a name="tags"/>

    <a name="tags"></a>

    <a name="tags">test</a>

  32. Pingback ::

    Reserved ID Values in IE/Win - Shruti Gupta Blog - Articles on Website Development and more

    […] w other reserved ID values that causes some sort of problems in IE/Win. Here, is a list of reserved ID values (Please note that I have tested only ID value &#8 […]

  33. I just recently ran into this problem and came across this article. In my case an ID named “contain” was the culprit. Any idea what this would have been conflicting with?

  34. Pingback ::

    Ajaxian » Thomas Fuchs - Combining Advanced JavaScript/DOM techniques to Enhance Use Experience

    […] reserved ids and IE – don’t use “length”, “item”, “namedItem”, “tags”, “urns” as ids – see Eric Meyer’s entry on this watch our for trailing commas in javascript anon […]

  35. Pingback ::

    Printing error in IE at /dev/caffeine

    […] in stumbling around trying to find some clue as to what the problem is, I came across this … It seems that id=”tags” ends up conflicting with some builtin function in IE that’s […]

  36. Hi,

    I just found another one:


    Gave me a hard time in IE when I was doing some element offset calculations which were wrapped in a

    After renaming it, everything was fine again.


  37. Here’s another one:


    Man this gave me headaches. A list of these conflicts published by MS would be nice.


  38. And yet another one: id=”category”

  39. And another one: id=”container”.

    For some reason it’s giving a JS error when using jQuery Kwicks widget and the widget is inside the main container with the id I mentioned above.

    If I change the name just by one character, any character, the JS error goes away and everything works fine.

    Funny thing is that I have this id in all my pages working fine.

    This happened to me in IE6, IE7 and IE8.


    The only way to solve this problem was to change word ‘container’ in the script to something else, I did ‘container2’.

    This should not be the widget’s fault, it works perfectly in all other browsers by default. I had to change the script because I couldn’t change the id of the main container of all the pages of my site.


  40. You can add “bottom” to the list – possibly not global, but definitely an issue for Facebook apps:

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview