meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Reserved ID Values?

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”.

40 Responses»

    • #1
    • Comment
    • Mon 29 Aug 2005
    • 1803
    ted drake wrote in to say...

    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
    • Comment
    • Mon 29 Aug 2005
    • 1904
    Thierry Koblentz wrote in to say...

    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 http://wwww.domain.com/page.html
    Operation aborted.

    • #3
    • Comment
    • Mon 29 Aug 2005
    • 1938
    Lachlan Hunt wrote in to say...

    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
    • Comment
    • Mon 29 Aug 2005
    • 2052
    Bob Easton wrote in to say...

    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
    • Comment
    • Mon 29 Aug 2005
    • 2059
    Eric Meyer wrote in to say...

    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
    • Comment
    • Mon 29 Aug 2005
    • 2145
    Thierry Koblentz wrote in to say...

    I wanted to post an URI earlier, but Google didn’t return anything…
    Here it is:
    http://www.mail-archive.com/wsg%40webstandardsgroup.org/msg20053.html
    (possible problem with MSIE when using *top* as a named anchor).

    • #7
    • Comment
    • Mon 29 Aug 2005
    • 2327
    Thierry Koblentz wrote in to say...

    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
    • Comment
    • Mon 29 Aug 2005
    • 2346
    Kevin Hamilton wrote in to say...

    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
    • Comment
    • Tue 30 Aug 2005
    • 0258
    Matthias Zirngibl wrote in to say...

    Whats about id=”all” :)

    • #10
    • Comment
    • Tue 30 Aug 2005
    • 0449
    Lachlan Hunt wrote in to say...

    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(document.all.foo));
    2. javascript:void(alert(document.all.foo("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
    • Comment
    • Tue 30 Aug 2005
    • 0954
    Kevin Hamilton wrote in to say...

    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
    • Comment
    • Tue 30 Aug 2005
    • 1204
    Ben O'Neill wrote in to say...

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

    • #13
    • Comment
    • Tue 30 Aug 2005
    • 1419
    Michiel wrote in to say...

    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
    • Comment
    • Tue 30 Aug 2005
    • 1441
    luxuryluke wrote in to say...

    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
    • Comment
    • Tue 30 Aug 2005
    • 1522
    Bekka Borg wrote in to say...

    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
    • Tue 30 Aug 2005
    • 1633
    Received from Web4C » Blog Archive » IE Reserved ID?

    [...] 0;

    «

    • #17
    • Comment
    • Tue 30 Aug 2005
    • 1648
    Ken Kolano wrote in to say...

    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
    • Comment
    • Tue 30 Aug 2005
    • 1717
    Eric Meyer wrote in to say...

    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
    • Tue 30 Aug 2005
    • 2304
    Received from The Dailies » IE hates “tags”

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

    As reported by Eric Meyer [...]

    • #20
    • Pingback
    • Wed 31 Aug 2005
    • 0317
    Received from 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
    • Wed 31 Aug 2005
    • 0331
    Received from 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
    • Wed 31 Aug 2005
    • 0631
    Received from LANtastic :: Blog

    [...] l

    • #23
    • Comment
    • Wed 31 Aug 2005
    • 1300
    Ted Tscopp wrote in to say...

    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
    • Wed 31 Aug 2005
    • 1513
    Received from 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
    • Comment
    • Wed 31 Aug 2005
    • 1519
    Kaneda wrote in to say...

    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
    • Comment
    • Tue 6 Sep 2005
    • 1102
    Scott Severtson wrote in to say...

    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
    • Comment
    • Thu 8 Sep 2005
    • 1634
    Romain Dardour wrote in to say...

    Well i have great news :)

    it seems “content” is a reserved word too !

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

    #content{ height:100px; }

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

    #contents{height:100px;}

    DOES work !!
    hmm talk about great programming

    • #28
    • Comment
    • Thu 8 Sep 2005
    • 1635
    Romain Dardour wrote in to say...

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

    • #29
    • Comment
    • Sat 10 Sep 2005
    • 1630
    Kris wrote in to say...

    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
    • Comment
    • Wed 12 Oct 2005
    • 1611
    Andrew wrote in to say...

    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, photomatt.net’s metas include:

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

    • #31
    • Comment
    • Wed 26 Oct 2005
    • 1629
    Justin Watt wrote in to say...

    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
    • Thu 3 Nov 2005
    • 0732
    Received from 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
    • Comment
    • Fri 4 Nov 2005
    • 1522
    perv wrote in to say...

    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
    • Thu 11 May 2006
    • 1411
    Received from 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
    • Thu 22 Feb 2007
    • 0948
    Received from 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
    • Comment
    • Fri 14 Dec 2007
    • 1323
    Bernd Matzner wrote in to say...

    Hi,

    I just found another one:

    “box”

    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.

    Bernd

    • #37
    • Comment
    • Thu 7 Feb 2008
    • 1531
    Matthew Barnes wrote in to say...

    Here’s another one:

    id=”version”

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

    -Matthew

    • #38
    • Comment
    • Fri 19 Dec 2008
    • 1412
    Ben Rousch wrote in to say...

    And yet another one: id=”category”

    • #39
    • Comment
    • Mon 28 Feb 2011
    • 1113
    Ricardo Zea wrote in to say...

    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.

    Solution:

    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.

    Thanks.

    • #40
    • Comment
    • Sat 31 Mar 2012
    • 0250
    Clive Holloway wrote in to say...

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

    https://developers.facebook.com/bugs/210289425741983

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


August 2005
SMTWTFS
July September
 123456
78910111213
14151617181920
21222324252627
28293031  

Sidestep

Feeds

Extras