Summary of JS compatibility issues in IE and FF

Internet Explorer is replaced by IE, and mozzila FF is replaced by ff.

1. Document. Form. Item Problems

Existing problems:
ExistingCodeThere are many statements such as document. formname. Item ("itemname"), which cannot be run in ff.

Solution:
Use document. formname. elements ["elementname"]

2. Collection class Object Problems

Existing problems:
In the existing Code, many collection class objects are used (), which is acceptable to IE and cannot be ff.

Solution:
Use [] as the subscript operation. For example, change document. Forms ("formname") to document. Forms ["formname"].
For example, change document. getelementsbyname ("inputname") (1) to document. getelementsbyname ("inputname") [1]

3. Window. Event

Existing problems:
Windows. event cannot be run on ff.

Solution:
FF event can only be used in the event. This problem cannot be solved. This can be changed as follows:
Original code (can be 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 (run in IE and ff ):

 <  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 of the new Code is not modified, it is the same as the old code (that is, the gotosubmit call does not provide a parameter), it can only be run in IE, but no error occurs. Therefore, the TPL part of this solution is still compatible with the old code.

4. Question about the ID of an HTML object as the object name

Existing problems:
In ie, the ID of the HTML object can be directly used as the variable name of the subordinate object of the document. It cannot be in ff.

Solution:
Use getelementbyid ("idname") instead of idname as the object variable.

5. The problem of getting an object using the idname string

Existing problems:
In IE, Eval (idname) can be used to obtain the HTML object with ID as idname, which cannot be used in ff.

Solution:
Use getelementbyid (idname) instead of eval (idname ).

6. The variable name is the same as the ID of an HTML object.

Existing problems:
In ff, because the Object ID is not the name of the HTML object, you can use the same variable name as the HTML Object ID, which cannot be used in IE.

Solution:
When declaring variables, add VaR to avoid ambiguity, so that it can run normally in IE.
In addition, it is best not to take the same variable name as the HTML Object ID to reduce errors.

7. event. X and event. Y

Existing problems:
In ie, the event object has the X, Y attributes, and FF attributes.

Solution:
In ff, event. X is equivalent to event. pagex. But event. pagex IE does not.
Therefore, event. clientx is used instead of event. X. This variable is also available in IE.
Event. clientx is slightly different from event. pagex (when the page has a scroll bar), but most of the time it is equivalent.

If it is the same, it may be a little troublesome:
MX = event. X? Event. X: event. pagex;
Use MX instead of event. x

Others:
Event. layerx is available in both IE and ff. There is no difference in the specific significance of this feature.

8. About Frame

Existing problems:
In ie, the frame can be obtained using window. testframe, but not in ff.

Solution:
The main difference between FF and IE in frame usage is:
If the following attributes are written in the frame tag:

 
<Frame SRC="Xx.htm" ID="Frameid" Name="Framename" />
 

Then Ie can access the window object corresponding to this frame through ID or name.
FF can only access the window object corresponding to this frame through name.
For example, if the above frame label is written in the HTM in the top window, you can access
IE: window. Top. frameid or window. Top. framename to access this window object
FF: only window. Top. framename can access this window object.

In addition, you can use top.doc ument. getelementbyid ("frameid") to access the frame tag in ffand ie.
In addition, you can switch the frame content through the parameter top.doc ument. getelementbyid ("testframe"). src = 'xx.htm '.
You can also switch the frame content through window. Top. framename. Location = 'xx.htm '.
For details about frame and window, see 'window and framework' in BBS'Article
And the tests under the/test/JS/test_frame/directory
---- Adun 2004.12.09 Modification

9. In ff, attributes defined by myself must be obtained by getattribute ().

10. In FF
Without parentelement parement. Children, parentnode. childnodes has different meanings in IE and ff. FF uses Dom norms, and blank text nodes are inserted in childnodes.
You can avoid this problem by using node. getelementsbytagname.
When a node in HTML is missing, ie and FF have different interpretations of parentnode, for example

<Form>
<Table>
<Input/>
</Table>
</Form>
 

In ff, the value of input. parentnode is form, while that of input. parentnode in IE is empty.

The node in FF does not have the removenode method. You must use the following method: node. parentnode. removechild (node)

11. Const Problems

Existing problems:
You cannot use the const keyword in IE. For example, const constvar = 32; in IE, This Is A syntax error.

Solution:
Use VaR instead of Const.

12. Body object

FF's body exists before the body tag is fully read by the browser, While IE exists only after the body is fully read.

13. If URL encoding is written in JS, It will be written directly & do not write &For example, VAR url = 'xx. jsp? Objectname = XX & objectevent = XXX ';
FRM. Action = URL, so it is very likely that the URL will not be properly displayed, so that the parameter is not correctly transmitted to the server.
Generally, the server reports that the error parameter is not found.
Of course, if it is an exception in TPL, because TPL complies with the XML specification, the requirements are as follows &
Generally, FF cannot identify &

14. nodename and tagname Problems

Existing problems:
In ff, all nodes have a nodename value, but textnode does not have a tagname value. In IE, nodename usage seems to be
There is a problem (the test is not performed, but my IE has been killed several times ).

Solution:
Use tagname, but check whether it is empty.

15. Element attributes

The input. Type attribute in IE is read-only, but can be modified in ff.

16. Document. getelementsbyname () and document. All [name] Problems

Existing problems:
In IE, neither getelementsbyname () nor document. All [name] can be used to obtain the DIV element (whether there are other elements that cannot be retrieved is unknown ).

17. DOM data island Problems

Existing problems:
In IE, <XML> labels have special meanings. They can contain xml dom and bind data with HTML components. in ff, <XML> is just an unknown tag. in addition, for IE, <XML> actually means that it is an ActiveX object, but it is hung under the html dom tree as a node, this will seriously affect the DOM tree traversal.

Solution:

The Data Binding Mechanism of IE can be simulated using JS, but it is too troublesome. We recommend that you do not use the data binding mechanism or find a library to implement this simulation. we will only discuss how to implement Dom compatibility. in ff, both known HTML tags and other tags that comply with XML specifications are processed using a uniform DOM tree. Therefore, FF can actually use DOM data islands, however, unlike IE, <XML> is a DOM document in IE, while FF is only a DOM node. this difference is usually not enough. however, there is a small detail. To be compatible with HTML syntax, FF cannot identify the abbreviated empty tag.

For example: <XML ID="XX"> <Book> <Title>Xxxx</Title> <content/> <Index/> </Book> </XML>,
 

Here, <content/> and <index/> are abbreviated, which will make FF unrecognizable and should be written:

<Content> </Content> <Index> </Index>
 

However, I suspect that if XHTML is used, there may be no such problem. but I have not tried it. for the DOM structure problem that <XML> interferes with HTML in IE, my current method is to delete it from the HTML Dom after processing. I don't know if there is any better solution.