You might be wondering why you cannot post the values of some fields even it’s inside the form.
Having a form within a form in your html code/dom is a BIG issue when it comes to ie.
Some of the issues you will encouter are listed below:
1. You won’t be able to post the values of those fields and it’s not even on the $_POST coz basically those fields within nested form is not recognize.
2. When calling javascript those fields are undefined.
I read from another source that it has something to do with the DOM in ie. So in order to solve this issue fix your form. Remove the nested form in your html code.
First of all the Four Methods. The average W3C DOM script uses them all. The first two methods allow you to create element nodes and text nodes. Later you insert these newly created nodes into the document.
The second two methods are for finding elements in the page. You can either find a single one, identified by an id, or all tags of one type.
Make x into a nodeList of all P’s in the document, so x[1] is the second P etc.
var x = y.getElementsByTagName('P')
Gets all paragraphs that are descendants of node y.
The * argument, which ought to select all elements in the document, doesn’t work in IE 5.5.
Custom tags are not returned in Konqueror and iCab.
Node information
These four properties give basic information about all nodes. What they return depends on the node type. They are read-only, except for nodeValue.
There are three basic node types: element nodes (HTML tags), attribute nodes and text nodes. I test these properties for all these three types and added a fourth node type: the document node (the root of all other nodes).
My advice is not to use tagName at all. nodeName contains all functionalities of tagName, plus a few more. Therefore nodeName is always the better choice.
In IE (all versions) the tagName of a comment node is !
The DOM tree
Five properties and two arrays for walking through the DOM tree. Using these properties, you can reach nodes that are close to the current node in the document structure.
In general you shouldn’t use too many of these properties. As soon as you’re doing something like
x.parentNode.firstChild.nextSibling.children[2]
your code is too complicated. Complex relationships between nodes can suddenly and unexpectedly change when you alter the document structure, and altering the document structure is the point of the W3C DOM. In general you should use only one or two of these properties per action.
These methods are for manipulating text data. Note the difference between a text node and text data: the text node is a node and contains the data in its nodeValue. The methods below only work with this contained data.
Takes a substring of x, which must be a text node, starting at the fifth character and with a length of three characters. Thus it’s the same as the old substr() method of strings.
Attributes
A bloody mess. Try influencing attributes in this order:
Try getting or setting a specific property, like x.id or y.onclick.
If there is no specific property, use getAttribute() or setAttribute().
If even that doesn’t work, try any other method or property in the table below. Most have horrible browser incompatibility patterns, though.
Avoid attributes[]. It’s worse than anything else.
In my view any method or property concerning attribute nodes should also work on the style attribute, event handlers and custom attributes. If not I judge the method or property incomplete.
Safari, Opera, iCab and Konqueror take the second attribute that’s defined on node x (align in the test).
Firefox tries to do the same, but the order of attributes is off.
IE takes the second possible attribute of node x (dataFld in the test), whether it’s defined or not.
This array consists of all defined attributes in all browsers save IE, where it consists of all attributes that can possibly be defined on the node (84 all in all).
Do yourself a favour and don’t use the indexed attributes array.
IE 5.5 initially gives the value of the attribute; not the attribute object.
attributes[key]
An array with the attributes of a node, accessed by attribute name
Get the align attribute object of node x. If the node has no align attribute, it returns undefined (except in IE, where it returns an attribute object that has no value.)
After years in the wilderness attribute[key] is slowly approaching a workable situation. I used to advice you not to use it; but by now you can try it if you like.
IE doesn’t return the value of a style attribute.
IE 5.5 doesn’t return custom attributes, and initially gives the attribute value instead of an attribute object.
createAttribute() and setAttributeNode()
Create a new attribute node and append it to an element node.
In IE, accessing the style attribute gives an object, and accessing the onclick attribute gives an anonymous function wrapped around the actual content.
x = document.createDocumentFragment();
x.[fill with nodes];
document.[somewhere].appendChild(x);
Create a fragment, add a lot of nodes to it, and then insert it into the document. Note that the fragment itself is not inserted, only its child nodes.
You may not move a node from the existing document to the document fragment. (Cloning is allowed, however.)
Create a nodeList with all elements that have name="test". It should ignore elements with id="test"
On my test page the <p>, <input>, <img> and <ppk> tags have this name, while there’s also a paragraph with id="test". Ideally, all browsers should get the first four elements and ignore the fifth one.
IE ignores the <p> and <ppk> tags with name="test", but counts the <p> with id="test"
The same as document.getElementsByTagName('P')[0].
The item() method is meant for other programming languages where nodeLists like those returned by getElementsByTagName are not conveniently accessible as if they were arrays.
All child nodes of node x that are text nodes and have other text nodes as siblings, are merged. This is in fact the reverse of splitText: text nodes that were split, come together again.
This method used to crash Explorer 6. My last test doesn’t cause a crash, but I advise you to be careful.
After the normalize() test I show an alert. This causes iCab to crash. If the alert is removed, iCab survives the experience.
Split the text node x at the 6th character. x now contains the first part (char. 0-5), while a new node is created (and becomes x.nextSibling) which contains the second part (char. 6-end) of the orginial text.
Microsoft extensions
As usual Microsoft has extended the standard somewhat. Though sometimes its extensions are brilliant (innerHTML springs to mind), in the case of the DOM Core they aren’t.
Note the difference between W3C and Microsoft methods. The W3C methods are owned by the parent element of the node you want to adjust, the Microsoft methods by the node itself.
IE does something when this line is executed, but I’m not sure exactly what is happening, nor whether it’s supposed to be happening. Try to find out for yourself by studying the singularly vague MSDN reference.
Remove node x from the document. If you use the argument true its children are also removed; if you use false they aren’t. Note that all text nodes count as children, too.
