1. Document.form.item question
Existing issues:
There are many Document.formName.item ("itemname") statements in existing code that cannot be run under MF
Workaround:
Switch to document.formname.elements["ElementName"]
Other
See also 2
2. Collection Class object problem
Existing issues:
Many collection class objects in existing code use (), IE can accept, MF cannot.
Workaround:
Use [] as the subscript operation instead. For example: Document.forms ("FormName") changed to document.forms["FormName"].
Also as follows: Document.getelementsbyname ("InputName") (1) Changed to Document.getelementsbyname ("InputName") [1]
3. window.event
Existing issues:
Unable to run on MF using window.event
Workaround:
MF event can only be used at the scene of the incident, this problem can not be resolved. You can do this:
Original code (can run in IE):
<input type= "button" Name= "Somebutton" value= "Submit" onclick= "Javascript:gotosubmit ()"/>
...
<script language= "JavaScript" >
function Gotosubmit () {
...
alert (window.event); Use window.event
...
}
</script>
New code (can run in IE and MF):
<input type= "button" Name= "Somebutton" value= "Submit" onclick= "Javascript:gotosubmit" (event)/>
...
<script language= "JavaScript" >
function Gotosubmit (evt) {
EVT = evt? EVT: (window.event window.event:null);
...
alert (EVT); Use EVT
...
}
</script>
In addition, if the first line in the new code does not change, the same as the old code (that is, the gotosubmit call does not give the parameter), it still can only run in IE, but not error. Therefore, the TPL part of this scheme is still compatible with the old code.
4. The ID of an HTML object as an object name problem
Existing issues:
In IE, the ID of an HTML object can be used directly as the subordinate object variable name of document. Not in MF.
Workaround:
Use getElementById ("Idname") instead of Idname as an object variable.
5. Obtaining an object with a idname string
Existing issues:
In IE, you can use Eval (idname) to obtain an HTML object with an ID of idname, which cannot be in MF.
Workaround:
Replace eval (idname) with getElementById (Idname).
6. Variable name and an HTML object ID the same problem
Existing issues:
In MF, because the object ID is not the name of an HTML object, you can use the same variable name as the HTML object ID, which is not available in IE.
Workaround:
In the declaration of variables, all add Var, to avoid ambiguity, so that in IE can also be normal operation.
In addition, it is best not to take variable names that are the same as the HTML object IDs to reduce errors.
Other:
See question 4
7. Event.x and Event.y issues
Existing issues:
In IE, the event object has an X, y attribute, which is not in MF.
Workaround:
In MF, the equivalent of Event.x is Event.pagex. But Event.pagex ie did not.
Therefore, the use of Event.clientx instead of event.x. This variable is also available in IE.
There are subtle differences between Event.clientx and Event.pagex (when the entire page has a scroll bar), but most of the time it is equivalent.
If you want to be exactly the same, you can be a little more troublesome:
MX = Event.x? Event.x:event.pagex;
And then use MX instead of event.x.
Other:
Event.layerx in IE and MF, the specific meaning of the difference has not yet been tested.
8. About Frame
Existing issues:
In IE, you can use Window.testframe to get the FRAME,MF.
Workaround:
The main differences between MF and IE in the use of frame are:
If the following attributes are written in the frame label:
<frame src= "xx.htm" id= "Frameid" name= "FrameName"/>
Then IE can access the Window object for this frame by ID or name
MF can only access the window object of this frame through name
For example, if the frame tag is written in the HTM inside the top-level window, you can access the
Ie:window.top.frameId or Window.top.frameName to access this window object
MF: Only so window.top.frameName to access this window object
In addition, Window.top.document.getElementById ("Frameid") can be used in both MF and IE to access the frame label
And you can switch the contents of the frame by window.top.document.getElementById ("Testframe"). src = ' xx.htm '.
You can also switch the contents of a frame by window.top.frameName.location = ' xx.htm '
A description of frame and window can be found in the ' window and frame ' article of BBS
And the test below the/test/js/test_frame/directory.
----Adun 2004.12.09 Revision
9. In MF, the attribute defined by itself must be getattribute () to obtain
10. There is no parentelement Parement.children in MF with ParentNode Parentnode.childnodes
ChildNodes the meaning of the subscript is different in IE and MF, MF uses the DOM specification, ChildNodes inserts a blank text node.
It is generally possible to avoid this problem by Node.getelementsbytagname ().
When nodes in HTML are missing, IE and MF have different interpretations of parentnode, such as
<form>
<table>
<input/>
</table>
</form>
The value of Input.parentnode in MF is form, while the value of Input.parentnode in IE is an empty node
There is no Removenode method for nodes in MF, you must use the following method Node.parentNode.removeChild (node)
11.const Problem
Existing issues:
The Const keyword cannot be used in IE. such as const CONSTVAR = 32; This is a syntax error in IE.
Workaround:
Do not use const instead of Var.
A . Body Object
MF body in the body tag is not fully read by the browser before the existence, and IE must be completely read into the body after the existence of
URL encoding in JS if the write URL directly write & do not write & such as var url = ' xx.jsp?objectname=xx&objectevent=xxx ';
Frm.action = URL It is likely that the URL will not be displayed properly so that the parameter is not uploaded to the server correctly
General Server error parameter not found
Of course, if the exception is in the TPL, because the TPL conforms to the XML specification, the requirement & write as &
General MF cannot recognize the & in JS
NodeName and TagName issues
Existing issues:
In MF, all nodes have nodename values, but textnode do not have tagName values. In IE, the use of nodename is as good as
There is a problem (the situation is not tested, but my IE has been dead several times).
Workaround:
Use TagName, but you should detect if it is empty.
15. Element Attributes
IE under the Input.type property is read-only, but MF can be modified
problems with Document.getelementsbyname () and Document.all[name]
Existing issues:
In IE, Getelementsbyname (), Document.all[name] can not be used to obtain DIV elements (whether there are other elements that cannot be taken is unknown).
DOM data Island issues
Existing issues:
In IE, <xml> tags have special meaning, can contain XML DOM, and can implement data binding with HTML component. ,<xml> in MF is only an unknown mark. In addition, for IE, <xml> actually means that this is an ActiveX object, but it hangs in the HTML itself as a node under the DOM tree, which can have a serious impact on the traversal of the DOM tree.
Workaround:
The data binding mechanism of IE can be simulated with JS, but it is too troublesome to use data binding mechanism or to find a library to implement this kind of simulation. We only discuss how to implement DOM compatibility. In MF, both known HTML tags and other XML-compliant tags are handled using a unified DOM tree, so MF can actually use the DOM data island, but the small difference with IE is that <xml> is a DOM document in IE, And in MF It's just DOM node. This difference is usually inadequate. But there is a small detail that MF does not recognize the abbreviated NULL tag in order to be compatible with HTML's rather random syntax. such as: <xml id= "XX" ><book><title>xxxx</title><content/><index/></book>< /xml>, in which <content/> and <index/> are abbreviated, will make MF unrecognizable and should be written as: <content></content><index> </index> However, I suspect that if XHTML is used, there may not be such a problem. But I haven't tried yet. For IE <xml> interfere with the DOM structure of HTML, my current approach is to remove it from the HTML DOM when finished. I don't know if there is any better solution.
