SiteCrafting, Inc.
15 Nov
Don't call IFrames bad names!
Internet Explorer has a long history of trying to do their own thing. They meet most standards, but always implement their own. One of these non-standard features is how IE handles the NAME property. Here are two examples of how this breaks:
The first is a long know "feature" that usually is forgotten when troubleshooting. Here's what happens. Let's say you have the following code block. What would you expect document.getElementById('description') would return in IE?
The second issue is one that took two hours of solve yesterday. Our Rich Text Editor uses an iframe as a way to prevent memory leaks and encapsulate it's special code in a secure way. We created the following code on one site. What side effect does this code have?
As a helpful guide, here are some of the ID and NAME values you want to stay away from: (important ones are in bold)
The first is a long know "feature" that usually is forgotten when troubleshooting. Here's what happens. Let's say you have the following code block. What would you expect document.getElementById('description') would return in IE?
< html>If you said textarea, you'd be wrong. That's what all other browses return, but IE has decided that it with return the meta description tag instead. You may run into the me problem with anything with the ID of keywords.
< head>
< meta name="description" value="a demo" />
< body>
< form>
< textarea id="description" name="description">
< /form>
< /body>
< /html>
The second issue is one that took two hours of solve yesterday. Our Rich Text Editor uses an iframe as a way to prevent memory leaks and encapsulate it's special code in a secure way. We created the following code on one site. What side effect does this code have?
< html>Turns out, this changes document.body to the iframe. Is that strange or what? It will see that a iframe is named body, and will create a shortcut to it through the document object. What this breaks is any call to document.body.appendChild(), or document.body.innerHTML. It also makes the following possible.
< head>
< script src="rte.js">
< body>
< form>
< iframe name="body" src="rte.html"/>
< /form>
< /body>
< /html>
< iframe name="getElementById"/>IE has just mapped document.getElementById to your new iframe. Now, all JavaScript that requires the use of this function is completely broken. Doesn't that seem crazy?
As a helpful guide, here are some of the ID and NAME values you want to stay away from: (important ones are in bold)
META tag name conflicts: (bad ids)
- description
- keywords
- author
- generator
- revised
- copyright
- distribution
- progid
- rating
- resource-type
- revisit-after
- robots
- Any custom meta tag names...
document property conflicts: (bad iframe names)
- namespaces
- lastModified
- onstorage
- parentNode
- onstoragecommit
- nodeType
- fileCreatedDate
- onbeforeeditfocus
- bgColor
- oncontextmenu
- onrowexit
- embeds
- scripts
- onactivate
- mimeType
- alinkColor
- onmousemove
- compatible
- onselectstart
- oncontrolselect
- body
- protocol
- onkeypress
- onrowenter
- onmousedown
- vlinkColor
- URL
- onreadystatechange
- doctype
- onbeforedeactivate
- applets
- fileModifiedDate
- onmouseover
- dir
- media
- defaultCharset
- firstChild
- plugins
- onafterupdate
- ondragstart
- oncellchange
- cookie
- documentElement
- nextSibling
- nameProp
- referrer
- ondatasetcomplete
- onmousewheel
- onerrorupdate
- onselectionchange
- lastChild
- ondblclick
- onkeyup
- location
- forms
- title
- onrowsinserted
- previousSibling
- compatMode
- onmouseup
- onkeydown
- onrowsdelete
- documentMode
- onfocusout
- fgColor
- ondatasetchanged
- onmouseout
- parentWindow
- nodeName
- onpropertychange
- onstop
- onhelp
- linkColor
- onbeforeactivate
- images
- readyState
- frames
- all
- onbeforeupdate
- onclick
- childNodes
- onfocusin
- anchors
- selection
- fileUpdatedDate
- domain
- security
- fileSize
- ownerDocument
- ondataavailable
- styleSheets
- nodeValue
- attributes
- activeElement
- implementation
- links
- URLUnencoded
- ondeactivate
Browser Bugs, From the Workbench, Javascript
by Paul Sayre | 11/15/2010 12:03pm | Comments (1)
by Paul Sayre | 11/15/2010 12:03pm | Comments (1)
SiFysV Muchos Gracias for your article.Much thanks again. Keep writing.
Left by Adobe OEM Software | Mar 7