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:
- IE Keyword Testing (length)
- IE Keyword Testing (item)
- IE Keyword Testing (namedItem)
- IE Keyword Testing (tags)
- IE Keyword Testing (urns)
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”.
37 Responses»
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.
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.
Lachlan Hunt wrote in to say...
I tried print preview on them all, and only “tags” caused any problem. IE gave this error message:
All the others were able to print preview as usual. I then tried printing to PDF and, again, only only “tags” caused any problems.
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”.
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!
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).
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
safelyuse these words as long as the string is not in lowercase.Kevin Hamilton wrote in to say...
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.
Matthias Zirngibl wrote in to say...
Whats about id=”all” :)
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
foois the name of the function/id value, andbaris 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].
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.
Ben O'Neill wrote in to say...
I’ve tested the “tags” example on IE7 Beta 1 and it does NOT crash.
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.
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?
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.
Received from Web4C » Blog Archive » IE Reserved ID?
[…] 0;
« 防止跨站攻击 IE Reserved ID? ID 有保留的 HTML id 值？Jason 在编辑 ALA 的一篇文章时发现这个问题，Eric Meyer 作 […]
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” />
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?
Received from The Dailies » IE hates “tags”
[…] ags”
Filed under: XHTML/CSS — michael @ 11:04 pm
As reported by Eric Meyer […]
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 […]
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 […]
Received from LANtastic :: Blog
[…] l鋜en konnte warum der IE abst黵zte, der kann sich mal diesen Eintrag auf Eric Meyers Blog Reserved ID Values? durchlesen. Er beschreibt ein paar Schl黶selw鰎ter f黵 IDs, […]
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.
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=” […]
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.
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.
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
Romain Dardour wrote in to say...
sorry, you should read “the div’s id” instead of “the div’is”. can’t even type properly :)
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…
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.
Justin Watt wrote in to say...
Eric, I thought I’d add that the following three examples using
name="tags"also cause theid="tags"printing bug in IE.<a name="tags"/><a name="tags"></a><a name="tags">test</a>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  […]
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?
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 […]
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 […]
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
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